Здравствуйте, netch80, Вы писали:
V>>Если сегодня самые-самые простые RISC-микрики имеют конвейер длиной 4, как сам думаешь? )) N>А зачем вспоминать "самые-самые простые", когда по контексту они точно ни при чём?
Просто самые простейшие уже отвечают на вопрос (исполняют одну команду за несколько шагов).
Более навороченные и подавно.
N>Коды условий должны быть — как в SPARC, ARM, POWER — или нет, как в MIPS, Alpha, RISC-V? Собери обоснования и попробуй доказать, кто из них прав, а кто презренный самец большой мерзкой кошки.
Это смотря какой файл регистров.
Например, в PIC-ах есть операция наложения маски на любой регистр из файла 128 штук и последующего ветвления по нулю или не нулю (через пропуск команды).
Часть регистров — системные, например, флаги нуля предыдущей операции, флаг переноса и т.д.
Т.е. одной командой покрыли как ветвление по маске обычного регистра, как и системных (как флагов, так и IO на ногах).
Поэтому, сравнимые возможности есть, но их умудрились упаковать в продуманный набор инструкций.
Т.е., набор инструкций влияет на архитектуру чипа и наборот тоже верно — это взаимосвязанные вещи, разрабатываемые в комплексе.
N>ARM/32 имел хитрую схему векторных регистров, когда, например, D0 состоит из S0 и S1. ARM/64 похерил это. В MIPS-R раннем 64-битном (поздние не видел) 64-битный регистр это пара 32-битных (типа R2+R3),
ХЗ, в MIPS64 всё те же 32 регистра, просто уже 64 бит.
N>распределители в компиляторах сходят с ума в попытке укладки. Кто прав?
А что тут не так, в сравнении с другими архитектурами? ))
В целом, задумка MIPS была понятной — инструкции фиксированной длины в слово, что позволило упростить дешифратор, упорядочить внутреннюю синхронизацию, а потом в камне разогнать частоту проца вдвое выше пней.
N>ARM по умолчанию когда кладёт более короткое значение в регистр — расширяет его нулями.
В MIPS есть команда загрузки беззнакового байта — lbu.
N>RISC-V аналогично расширяет знаково, размножая старший бит, причём настаивает в ABI на таком расширении при передаче через границу функции даже для коротких беззнаковых. N>Оба почти что с пеной у рта доказывают свою правоту (RISC-V — в родной доке, ARM — в высказываниях сотрудников). N>Кто прав?
Зависит от возможности независимого оперирования частями регистра.
В эпоху битовыжимания это было важно.
Сейчас не особо актуально, т.к. исходник оперирует обычно тупо интами или size_t, хотя почти никогда этого не требуется, просто никто уже не жмётся на ширине переменных, берут с запасом.
Давно ты в исходниках видел short и byte, если речь не идёт о строке или бестиповых байт памяти? ))
То бишь, сейчас можно уже автоматом расширять, не боясь, что это создаст сложности там, где расширять не требуется, потому что таких мест в реальной программе исчезающе мало.
N>MIPS-R содержит пачку команд с trap-ом на знаковом переполнении. Реально даже родные компиляторы их не использовали, а уж тотально всё победившие gcc + clang — тем более. Поддерживать надо, использование — фиг. Лучше бы как в ARM сделали adds/subs/etc. в отдельный регистр.
Какой отдельный?
N>Они правы или опять ХЗ что?
MIPS позволяет указывать dst-регистр явно.
И по-другому в этом огромном (на момент разработки архитектуры) файле регистров было бы неразумно.
Зато исключаются бесконечные внутрирегистровые пересылки и прочие пары push/pop.
Я же говорил выше — система команд зависит от архитектуры и наоборот тоже верно.
Например, трехрегистровая кодировка позволила ввести команду условного move, когда перемещение м/у двумя регистрами выполняется, в зависимости от значения в третьем.
Тут простор для оптимизаций большой, разве что MIPS давно не основной мейнстрим, т.е. я бы не ожидал от gcc многого.
N>И почему нет аналогичных для беззнакового переполнения?
А в чём заключается вопрос?
По ARM-у я не очень, скорее никак — просто на уровне представлений об архитектуре проца, но в возможности ни разу глубоко не вникал, бо нелюбопытно — когда вникал всего один раз давно, то увидел, что эта архитектура не проектировалась для упора на вычисления, в отличие от того же MIPS, который изначально был неплох даже в качестве сигнального проца.
Поэтому, для меня ARM несколько скучен...
Хотя, я понимаю причины, почему он когда-то взлетел — из-за низкого энергопотребления.
Но сегодня ARM64 уже не торт, уже всё всерьёз, на уровне MIPS... но мейстрим уже был захвачен армами.
Хотя, китайцам пох, они развивают архитектуру MIPS аж бегом, просто не в мобильном сегменте.
N>Часть архитектур знает пустой регистр (крайне ценно для RISC), часть — нет (ARM/32 не имел). Нужен или нет? Методы построения всей системы после этого меняются чуть более чем полностью.
Дык, кодировка же! ))
Если нулевой регистр — то имеем абсолютную адресацию...
А команда та же, что и для относительной адресации по регистру+смещение.
N>Ладно, предположим, ты только про "кодировку", хотя это ничтожная часть всей задачи... В SPARC вызов функции по смещению от PC получает 30-битное смещение (да-да, 1/4 всего пространства кодов), после сдвига влево на 2 бита получаем полное 32-битное пространство. Это правильно или нет, по сравнению с более короткими в конкурентах? Обоснование — в студию.
Спарки можно рассматривать как продолжение MIPS-архитектуры в сторону увеличения эффективности (окна регистров).
Там слишком много похожего.
V>>Например, гарвардское семейство PIC имеет 12-битные инструкции, ветвление там происходит через трюк "условно пропустить следующую инструкцию", адрес инструкции — не в байтах, это адрес слова. Зато уложились в 12 бит.
V>>В ARM и AVR условный переход всегда относительный (относительно текущего счётчика команд), т.к. ширина адреса `уже, чем полное адресное пространство. V>>В то же время, каждая инструкция в ARM имеет 32 бита, поэтому младшие 2 бита адреса в команде не кодируются. V>>В этом месте очевидно, что безусловные jmp/call должны кодироваться не более 4-мя битами, отдавая остальные биты под адрес границы 32-битного слова.
N>Смотрю в AArch64. "B", "BL" — 6 фиксированных, 26 бит на смещение. Итого 28 бит (со знаком). А вот SPARC, наоборот, сделал ещё шире этот литерал. Не соглашаются они с тобой, оба, но по-разному
Значит, арму не хватило пространства кодов, что не смог выделить больше бит под адрес.
В целом, это более экономная, более жадная архитектура -пытается повысить не эффективность исполнения, а размер образа.
В MIPS/SPARC наоборот, при проектировании архитектур во главу угла ставилась эффективность.
Поэтому, армы предазначались для персоналок и встраиваемых решений, а MIPS/SPARC — для рабочих станций и серверов.
И когда сегодня говорят, что вот сервак на армах делают...
Это
Понятно, что из-за массовости камни эти дешевле при топовых процессах исполнения, но не лучше ли массово выпускать на том же процессе более пригодные для сервера архитектуры? ))
V>>>>По тем временам — типичная задача для подобных комплексов, бо на управляющей машине монитор периферии, графики в реальном времени и это всё. N>>>А какая доля таких комплексов от всех PC? V>>Ну, тогда еще во всех офисах PC не стояли, поэтому доля инструментального применения персоналок была весьма высокой. N>Ты хоть бы приблизительно цифру прикинул...
Где-то в разы меньше, чем в офисах, но разницы даже на порядок не видел.
Сегодня же любые терминалы (не только банковские/платёжные — даже банальный пульт автомойки, принимающий карточки), любые пульты управления станками, любое локальное серверное хранилище — это тоже персоналки по архитектуре, просто исполнение внешне другое.
Поэтому, можно поспорить и о сегодняшних раскладах. ))
Возможно, что "там" инструментальное исполнение было доступным "сразу", но у нас были только массово хлынувшие б/у персоналки, поэтому вся инструменталка одно время делалась на них.
V>>>>Для разных регистров получилась разная кодировка, плюс префиксы для новых команд, чтобы "остальные" регистры стали "как все" и т.д. N>>>Ты о каком этапе-то? Для x86-16, x86-32 она тут одинаковая, в 32 даже ровнее. V>>Разве ровнее? )) N>Я про то, что база и индекс адресации — любой из 8.
Но кодировки под разные регистры иногда разные, в отличие от ортогональных архитектур.
добавление трёхоперандного формата большинству существующих целочисленных инструкций;
добавление дополнительных условных инструкций для облегчения предсказания переходов;
а также новую 64-битную инструкцию безусловного перехода.
Это позволит кодировать многие операции более чем одним способом — как в новом формате, так и в традиционном.
То бишь, можно будет постепенно отказаться от "франкенштейна" в традиционной кодировке.
А потом однажды перекодировать команды, убрав уже ненужные префиксы, что сократит размер образа. ))
N>"Догнать и перегнать ARM". А когда от TSO начнут отходить?
Ну, ARM поступили правильно в ARM64 — в новую жизнь без старых долгов.
А вот AMD64 поднасрала, конечно...
N>Но если бы на этом этапе проектировали с нуля, то мне кажется, что подход с полностью переменной схемой (в стиле CBOR и отдельными элементами в le128) декодировался бы не дороже.
Речь идёт о том, чтобы сделать сам дешифратор проще.
Причём, в ортогональной схеме он получается проще в разы.
А это важно как для будущего увеличения кол-ва ядер, так и для будущего увеличения степени параллельности гипертрединга (до 16 аппаратных потоков на ядро было бы неплохо — и это самый начальный минимум).
(Самый первый гипертрединг в спарках был, вроде, сразу 4 потока — ИМХО, потому что дешифратор в разы дешевле, чем в x86/x64 архитектуре)
Здравствуйте, vdimas, Вы писали:
V>>>Если сегодня самые-самые простые RISC-микрики имеют конвейер длиной 4, как сам думаешь? )) N>>А зачем вспоминать "самые-самые простые", когда по контексту они точно ни при чём? V>Просто самые простейшие уже отвечают на вопрос (исполняют одну команду за несколько шагов). V>Более навороченные и подавно.
Только делают это они совершенно по-разному.
N>>Коды условий должны быть — как в SPARC, ARM, POWER — или нет, как в MIPS, Alpha, RISC-V? Собери обоснования и попробуй доказать, кто из них прав, а кто презренный самец большой мерзкой кошки. V>Это смотря какой файл регистров. V>Например, в PIC-ах есть операция наложения маски на любой регистр из файла 128 штук и последующего ветвления по нулю или не нулю (через пропуск команды).
Вот ещё один вариант. Так кто прав?
N>>распределители в компиляторах сходят с ума в попытке укладки. Кто прав? V>А что тут не так, в сравнении с другими архитектурами? ))
Там где в зависимости от размера регистра он оказывается совпадающим или с одним, или сразу несколькими? Наверно, всё не так, если от этого пытаются отказываться.
N>>ARM по умолчанию когда кладёт более короткое значение в регистр — расширяет его нулями. V>В MIPS есть команда загрузки беззнакового байта — lbu.
Ну и в RISC-V есть. И что? Ты всё уходишь от вопроса, кто больше прав
N>>RISC-V аналогично расширяет знаково, размножая старший бит, причём настаивает в ABI на таком расширении при передаче через границу функции даже для коротких беззнаковых. N>>Оба почти что с пеной у рта доказывают свою правоту (RISC-V — в родной доке, ARM — в высказываниях сотрудников). N>>Кто прав? V>Зависит от возможности независимого оперирования частями регистра.
Нет, именно в этом не зависит. Если бы я называл третий вариант — загрузка короткого содержимого без замены остальной части (как на x86 загрузка в AX не меняет верхние части ни EAX ни RAX) — твоя реплика была бы в тему.
V>Давно ты в исходниках видел short и byte, если речь не идёт о строке или бестиповых байт памяти? ))
"Сплошь и рядом"
Несколько телекомовских проектов разной направленности. И во всех одинаковые конструкции типа
После компиляции ++ch превращается в инкремент с маскированием.
Вот почему-то в этой среде принято так писать.
V>То бишь, сейчас можно уже автоматом расширять, не боясь, что это создаст сложности там, где расширять не требуется, потому что таких мест в реальной программе исчезающе мало.
Да. Вообще-то всегда было мало мест, где нужно (варианты с раздельной жизнью AH и AL не в счёт, у них именно что раздельный доступ). Но почему-то в определённых линиях развития было принято сохранять старшие части.
Но ты опять не о том.
N>>MIPS-R содержит пачку команд с trap-ом на знаковом переполнении. Реально даже родные компиляторы их не использовали, а уж тотально всё победившие gcc + clang — тем более. Поддерживать надо, использование — фиг. Лучше бы как в ARM сделали adds/subs/etc. в отдельный регистр. V>Какой отдельный?
Ну сделали же отдельные lo и hi в MIPS вне основного набора регистров? Могли любой из них применить, hi вот как раз даже по названию в тему.
N>>Они правы или опять ХЗ что? V>MIPS позволяет указывать dst-регистр явно. V>И по-другому в этом огромном (на момент разработки архитектуры) файле регистров было бы неразумно. V>Зато исключаются бесконечные внутрирегистровые пересылки и прочие пары push/pop.
При вызовах функций — не исключаются.
V>Я же говорил выше — система команд зависит от архитектуры и наоборот тоже верно. V>Например, трехрегистровая кодировка позволила ввести команду условного move, когда перемещение м/у двумя регистрами выполняется, в зависимости от значения в третьем.
Это? > Move Conditional on Not Zero — MOVN > Description: if (rt ≠ 0) then rd ← rs
Это уже нарушение. Потому что если разделены приёмник и оба источника, то тебе в кодировке надо 4 регистра. А если у тебя совпадает первый источник с приёмником, это значит, что команда из двухадресного стиля (а не трёхадресного), только добавлен регистр условия.
При честном кодировании: if (rt ≠ 0) then rd ← rs1 else rd ← rs2 — она была бы четырёхадресной.
А так ничем не отличается от CMOV в x86 кроме метода передачи флага условия.
Плохой, негодный пример.
V>Тут простор для оптимизаций большой, разве что MIPS давно не основной мейнстрим, т.е. я бы не ожидал от gcc многого.
Не знаю, с платформой что-то не то или с gcc, но в моих тестах на MIPS64 код был в полтора раза толще минимум, чем на x86-64 или AArch64.
N>>И почему нет аналогичных для беззнакового переполнения? V>А в чём заключается вопрос?
В причинах несимметричности отношения к двум разным базовым арифметикам.
V>Поэтому, для меня ARM несколько скучен...
А мне нравятся решения в нём. Сделано даже сильно ближе к цели RISC — в одну простую команду запихнуть по максимуму функциональности на разные методы использования и малой ценой.
Посмотри, например, на группу csel/csinv/csinc/csneg. Вместе с пустым регистром по сути одна базовая команда имеет около десятка типичных применений.
N>>Часть архитектур знает пустой регистр (крайне ценно для RISC), часть — нет (ARM/32 не имел). Нужен или нет? Методы построения всей системы после этого меняются чуть более чем полностью.
V>Дык, кодировка же! ))
Чего приборы?
V>Если нулевой регистр — то имеем абсолютную адресацию...
Это ещё одна польза, но я не про неё, а про источник арифметики (и вокруг).
N>>Ладно, предположим, ты только про "кодировку", хотя это ничтожная часть всей задачи... В SPARC вызов функции по смещению от PC получает 30-битное смещение (да-да, 1/4 всего пространства кодов), после сдвига влево на 2 бита получаем полное 32-битное пространство. Это правильно или нет, по сравнению с более короткими в конкурентах? Обоснование — в студию.
V>Спарки можно рассматривать как продолжение MIPS-архитектуры в сторону увеличения эффективности (окна регистров). V>Там слишком много похожего.
Ты съехал
V>Значит, арму не хватило пространства кодов, что не смог выделить больше бит под адрес. V>В целом, это более экономная, более жадная архитектура -пытается повысить не эффективность исполнения, а размер образа. V>В MIPS/SPARC наоборот, при проектировании архитектур во главу угла ставилась эффективность.
Осталось понять, что ты называешь эффективностью, а то у меня впечатление практически противоположное.
V>>>>>По тем временам — типичная задача для подобных комплексов, бо на управляющей машине монитор периферии, графики в реальном времени и это всё. N>>>>А какая доля таких комплексов от всех PC? V>>>Ну, тогда еще во всех офисах PC не стояли, поэтому доля инструментального применения персоналок была весьма высокой. N>>Ты хоть бы приблизительно цифру прикинул... V>Где-то в разы меньше, чем в офисах, но разницы даже на порядок не видел.
OK.
V>Сегодня же любые терминалы (не только банковские/платёжные — даже банальный пульт автомойки, принимающий карточки), любые пульты управления станками, любое локальное серверное хранилище — это тоже персоналки по архитектуре, просто исполнение внешне другое. V>Поэтому, можно поспорить и о сегодняшних раскладах. ))
V>Возможно, что "там" инструментальное исполнение было доступным "сразу", но у нас были только массово хлынувшие б/у персоналки, поэтому вся инструменталка одно время делалась на них.
Не в этом дело, а в цене рабочей силы. "Там" было выгоднее сразу комплектовать с завода в промышленном исполнении. У нас же качественный стоечный корпус за 400$ был неподъёмной добавкой, когда зарплата в 50$ была фантастикой.
V>>>>>Для разных регистров получилась разная кодировка, плюс префиксы для новых команд, чтобы "остальные" регистры стали "как все" и т.д. N>>>>Ты о каком этапе-то? Для x86-16, x86-32 она тут одинаковая, в 32 даже ровнее. V>>>Разве ровнее? )) N>>Я про то, что база и индекс адресации — любой из 8. V>Но кодировки под разные регистры иногда разные, в отличие от ортогональных архитектур.
Нет, сказано же, что страничная адресация не выключается. (В оригинальном pdf на intel.com.)
V>Не-не-не )) V>
V>добавление трёхоперандного формата большинству существующих целочисленных инструкций;
V>добавление дополнительных условных инструкций для облегчения предсказания переходов;
V>а также новую 64-битную инструкцию безусловного перехода.
V>Это позволит кодировать многие операции более чем одним способом — как в новом формате, так и в традиционном. V>То бишь, можно будет постепенно отказаться от "франкенштейна" в традиционной кодировке.
Серьёзно? Кто будет отказываться, когда традиционные короче?
Добавится ещё один каскад сложного выбора в компиляторах "делать отдельный регистр-приёмник и удлинять код, или использовать старое и код короче" (и это вдобавок к "а если выберем RAX, ещё байт сэкономим").
Это уже проходили на SystemZ, где к базовому набору двухадресных команд добавили всякие ARK с отдельным приёмником. Да, их компилятор иногда кодирует
V>А потом однажды перекодировать команды, убрав уже ненужные префиксы, что сократит размер образа. ))
То есть бинарно несовместимое изменение? Не смеши. Будут тянуть до последнего, после чего ARM их победит.
N>>"Догнать и перегнать ARM". А когда от TSO начнут отходить? V>Ну, ARM поступили правильно в ARM64 — в новую жизнь без старых долгов. V>А вот AMD64 поднасрала, конечно...
AMD на момент её разработки была нищей конторой без перспектив. Они поставили всё на новую разработку и выиграли. К ним претензий сильно меньше, чем к Intel, которая вбухала миллиарды на заведомо дохлый IA64.
N>>Но если бы на этом этапе проектировали с нуля, то мне кажется, что подход с полностью переменной схемой (в стиле CBOR и отдельными элементами в le128) декодировался бы не дороже. V>Речь идёт о том, чтобы сделать сам дешифратор проще.
Только сейчас дешифратор будет вынужден поддерживать 1) APX 2) старую универсальную кодировку 3) короткие команды с неявно заданным аккумулятором.
Что там с картинкой про 15 конкурирующих стандартов?
V>Причём, в ортогональной схеме он получается проще в разы. V>А это важно как для будущего увеличения кол-ва ядер, так и для будущего увеличения степени параллельности гипертрединга (до 16 аппаратных потоков на ядро было бы неплохо — и это самый начальный минимум).
/me представил себе "если хотите более 2 аппаратных тредов на ядро, кодируйте все команды в APX". Зачем ты мои ботинки рассмешил?
V>(Самый первый гипертрединг в спарках был, вроде, сразу 4 потока — ИМХО, потому что дешифратор в разы дешевле, чем в x86/x64 архитектуре)
Ага, только найди блоки АЛУ на всех и отработай конкуренцию между ними. Дороговато будет.
Здравствуйте, netch80, Вы писали:
V>>Сразу нельзя было подумать, что серверная часть по мере развития мировой инфраструктуры будет всё более важной? )) V>>Возьми они Unix-like систему за основу — были бы лучше готовы к серверному сценарию. N>А почему сразу Unix-like?
Параллельно во времени с успехом Windows на десктопе, на серьезных машинках и кластерах их были UNIX-like системы.
N>Unix победил через Linux не из-за выдающихся качеств проекта, а из-за лицензии. Кто мог это предугадать?
Зачем гадать, если серьёзная техника сидела безальтернативно на юнихах?
Гадать можно было только относительно того, какая из юниховых реализаций выиграет конкуренцию, а не о том, выиграет ли юних как таковой на серверной стороне.
Он выигрывал всегда и сразу.
И да, строго говоря, выиграл не Linux, выиграла GNU OS, под исполнение ПО которого этот Linux ориентировали изначально.
Т.е., Linux сегодня — это низлежащий уровень для прикладных разделов GNU, где GNU однажды отказалось от собственного низкого уровня.
И всё "это" уже можно было хотя бы немножечко предполагать, что открытое ПО имеет некоторое преимущество вдолгую в мировом масштабе. ))
Стоило бы задуматься — а почему открытое ПО выбрало UNIX-like низкий уровень?
V>>А что случилось с их "личной осью"? — они вынуждены были самостоятельно разработать ВООБЩЕ ВСЁ! V>>А это дорого! V>>И они хотели с этого компенсацию, разумеется. V>>В том числе, чтобы не работать в убыток.
Отож.
Вся индустрия отдавала им деньги, а теперь эти решения, в которые были вложеные деньги индустрии, похерены, считай.
Здравствуйте, vdimas, Вы писали:
V>Зачем гадать, если серьёзная техника сидела безальтернативно на юнихах?
"Серьёзная техника" сидела много на чём, смотря что считать серьёзностью. Самая серьёзная сидела на всяких ESA/390+VM/ESA. Вторым по уровню "серьёзности" считались VAX+VMS. Рядом маячила AS/400. По сравнению с этим любой юникс был для "серьёзных людей" игрушкой, как он собственно и начинался. Я ещё застал тех, кто так думал. Или посмотри классику — откуда там взялся пункт 8? А из того, что в эхе сидели люди (я ещё помню основного представителя), которые на все сравнения механизмов показывали, что у них это работает давно, надёжнее, управляемее и вообще лучше.
V>Гадать можно было только относительно того, какая из юниховых реализаций выиграет конкуренцию, а не о том, выиграет ли юних как таковой на серверной стороне. V>Он выигрывал всегда и сразу.
Нет, в том-то и дело. Фактически, до прихода полностью открытых версий вроде Linux и NetBSD (ещё до FreeBSD и OpenBSD) ни у кого уверенности не было.
Ну как ты можешь такое нести, сам же видел эти процессы...
V>И всё "это" уже можно было хотя бы немножечко предполагать, что открытое ПО имеет некоторое преимущество вдолгую в мировом масштабе. )) V>Стоило бы задуматься — а почему открытое ПО выбрало UNIX-like низкий уровень?
Потому что он был уже открыт к тому времени, хотя бы частично.
Софт писавшийся под открытую лицензию потому, что за государственные деньги США.
Даже после лицензионных конфликтов, 4.4BSD-Lite вышла вполне рабочей, и на скелет быстро нарастили мясо (а если бы ещё быстрее, то Linux бы не выстрелил, но он успел как раз в разгар конфликта). Потому что у неё было уже много открытого кода.
То есть ключевой момент — когда Беркли взял (купил) для своих научных работ именно систему от Bell, которую продали потому, что она не имела иной коммерческой ценности. А ещё потому, что как раз разломанная AT&T не могла понять ценность этой разработки.
Ничего не напоминает?
V>>>А что случилось с их "личной осью"? — они вынуждены были самостоятельно разработать ВООБЩЕ ВСЁ! V>>>А это дорого! V>>>И они хотели с этого компенсацию, разумеется. V>>>В том числе, чтобы не работать в убыток. V>Отож.
"Как приятно поговорить с умным человеком"
V>Вся индустрия отдавала им деньги, а теперь эти решения, в которые были вложеные деньги индустрии, похерены, считай. V>Это эпик-фейл мирового масштаба, как ни крути.
До фейла им ещё далеко. Десктоп держится частично на WinAPI, частично таки на наработках UX/UI.
А вот то, что они чуть ли не последние, кто продаёт именно ОС (пусть как базу), а не решения и сервис над ней (хотя и это тоже), интересно таки.
Здравствуйте, netch80, Вы писали:
V>>Зачем гадать, если серьёзная техника сидела безальтернативно на юнихах? N>"Серьёзная техника" сидела много на чём, смотря что считать серьёзностью. Самая серьёзная сидела на всяких ESA/390+VM/ESA.
Это недостаточно серьёзно ввиду отсутствия массовости...
Да какой "массовости", что я несу? ))
Было вообще ровно ноль распространнённости, бо IBM тогда уже перешла полностью на продажу машинного времени мейнфреймов, отказавшись от поставки и обслуживания техники.
N>Вторым по уровню "серьёзности" считались VAX+VMS.
Не, VMS активно устаревала в 80-х.
Не зря же System V вышел изначально только на DEC VAX — потому что требовалась замена VMS.
(System III до этого — аналогично, но не была еще достаточно совершенной ОС)
N>Рядом маячила AS/400.
Тю. IBM RS/6000 и наследники — уже юниховые IAX на примерно том же или более серьёзном железе.
И более массовые и долгоживущие все 90-е, нулевые и местами их полно до сих пор.
N>По сравнению с этим любой юникс был для "серьёзных людей" игрушкой, как он собственно и начинался. Я ещё застал тех, кто так думал.
Мало ли что как начиналось?
Первые версии OS/360 тоже были забавны, оглядываясь назад.
К концу 80-х годов UNIX-системы уже стали мейнстримом в серверах и рабочих станциях, сие медицинский факт.
А так же UNIX-системы стали стандартом де-факто как для суперкомпьютеров, так и для "просто серверов" в академической среде.
Собсно, когда я рассуждал о том, чтобы заменить ЕС ЭВМ новыми i486-ми, это можно было сделать только на UNIX-системе с терминалами.
Безальтернативно! ))
N>Или посмотри классику — откуда там взялся пункт 8? А из того, что в эхе сидели люди (я ещё помню основного представителя), которые на все сравнения механизмов показывали, что у них это работает давно, надёжнее, управляемее и вообще лучше.
При том что большинство юниховодов в середине 90-х ничего кроме Linux не видели? ))
Над теми первыми версиями линухов лично я громко ржал.
А в сетевой лаборатории запускали и тестировали в 1994-м в различных конфигурациях какой-то "взрослый" юникс, жаль не помню какой.
Все работало обалденно.
(по тем временам)
Многие вещи увидел впервые в жизни (а что, так можно было???)
V>>Гадать можно было только относительно того, какая из юниховых реализаций выиграет конкуренцию, а не о том, выиграет ли юних как таковой на серверной стороне. V>>Он выигрывал всегда и сразу. N>Нет, в том-то и дело. Фактически, до прихода полностью открытых версий вроде Linux и NetBSD (ещё до FreeBSD и OpenBSD) ни у кого уверенности не было.
Как это, если из более десятка популярных на тот момент серверных осей примено 80% были UNIX-like? ))
Простая ж арифметика!
Плюс для рабочих станций — почти 100%.
(WinNT еще не было)
Для суперкомпов — ровно 100%.
Лично мне (и не только мне) уже было очевидно, что UNIX-подобные системы неотвратимо завоёвывают серверные вычисления/службы, и вообще область более-менее приличных вычислений.
Ну вот мы ставили Novel NetWare сугубо как файловые сервера для дохлых компов, бо те оперировали с сетевым диском шустрее, чем с локальным винчестером тогда (IPX-сетка была шустрой, в сравнении с IP-сеткой).
Но это было сугубо для учебных классов, чтобы выжать максимум из техники прошлых поколений, на которых были выполнены рабочие места студентов.
Да и вообще, сохранение файлов на сервак сделало организацию учебного процесса удобней, типа как в ЕС ЭВМ — после логина студент видел на сетевом диске свои файлы, независимо с какой машинки залогинился.
N>Ну как ты можешь такое нести, сам же видел эти процессы...
Я был старше, видел и участвовал.
Мы изучали не только сами мейнфреймы, всегда ж давалась еще информация общего плана — сколько их примерно у нас, сколько на западе, каковы тенденции (а это было важно, ес-но).
Так вот, десятки тыщ штук на весь мир, а топовых — единиц тыщ или единицы сотен совсем топовых на весь мир.
Для сравнения, общее кол-во "независимых" суперкомьютеров (или просто мощных выч.кластеров) в различных ВУЗ-ах по всему миру уже становилось сравнимым или обгоняло кол-во "централизованных мейнфреймов" к середине 90-х, и в этих независимых суперкомпах или выч.кластерах везде безальтернативно были UNIX-like системы.
Собсно, критикуемые мною т.н. "суперкомпьютеры" с середины нулевых — это те же самые выч.кластеры из плат уровня мощных первоналок, бо все технологии были давно отлажены уже.
Поэтому я не понимаю, как можешь ты такое нести? ))
Ведь академические круги ВСЕГДА определяют будущее.
На чём студент вырос, то он и будет толкать.
А мейнфреймы воспринимались как г-но мамонта, конечно.
И плевать, что на этот счёт говорили старые пердуны. ))
Ты не обратил внимания, разве, что основную массу программеров составляют люди, обучавшиеся в ВУЗ-ах по IT-специальностям примерно с 88-89-го года и позже?
(или получавшие второе профильное IT-образование после этих дат)
Поступившие раньше присутствуют, конечно, но выборка их крайне мала — это бросается в глаза.
(зато которые есть — это обычно мощные люди, практически самородки)
Причём, это не потому что тем людям уже за полтинник — 10 лет назад была такая же ситуация — основная масса программеров из стран бывшего СССР была примерно от 40 с хвостиком и моложе.
Т.е., начиная с указанных лет поступления, айтишники идут массой, эдакой непрерывной гладкой кривой по годам, как грится.
Новая принятая тогда программа дала новый менталитет.
Более гибкий, ИМХО.
Нам разрешили отказаться от "направляющей роли компартии" (в т.ч. убрали предмет по истории компартии) и обязали смотреть за тенденциями самим.
Вот что важного произошло. ))
V>>И всё "это" уже можно было хотя бы немножечко предполагать, что открытое ПО имеет некоторое преимущество вдолгую в мировом масштабе. )) V>>Стоило бы задуматься — а почему открытое ПО выбрало UNIX-like низкий уровень? N>Потому что он был уже открыт к тому времени, хотя бы частично.
Исходники были открыты или ты прочто?
"Просто открыть исходники" мало, они бы погоды не сделали.
UNIX-системы имели отличные открытые спецификации, позволяющие их воспроизвести и безо-всяких исходников.
Это было решающим, ИМХО.
Эти системы изначально разрабатывались с расчётом на обширную совместимость прикладных программ в исходных кодах, отсюда столь подробные спецификации даже достаточно низких уровней.
Для сравнения, твои AS/400 выполняли пляски с бубном над бинарными образами, вместо исходников, поэтому почили в бозе, ес-но.
А юниховые исходники с тех или более ранних лет живут и здравствуют, составляя основу современного стандартного юниксового ПО на всевозможных UNIX-like системах на всевозможнейшем же железе.
N>Софт писавшийся под открытую лицензию потому, что за государственные деньги США. N>Даже после лицензионных конфликтов, 4.4BSD-Lite вышла вполне рабочей, и на скелет быстро нарастили мясо (а если бы ещё быстрее, то Linux бы не выстрелил, но он успел как раз в разгар конфликта). Потому что у неё было уже много открытого кода.
Linux никуда не торопился в первых версиях, это была просто игрушка для исследований.
А "выстрелил" он не поэтому, а потому что...
Да просто посмотри на исходники FreeBSD и на исходники тогдашних линухов...
Первое — это ужас, летящий на крыльях ночи. Авторов повесить, потом расстрелять.
Второе — современная (по тем временам) приятная конфетка, глаз радовался.
Linux выстрелил только из-за этого, конечно, что к нему сразу потянулись тысячи энтузиастов, которым захотелось поучаствовать в таком приятном проекте.
Жаль, сам автор донельзя неприятный человек, ну да ладно))
Зато он задал отличный дух исходникам, у товарища определённо неплохой вкус.
Этот стиль легко и приятно читается даже сегодня, спустя ~30 лет.
N>То есть ключевой момент — когда Беркли взял (купил) для своих научных работ именно систему от Bell, которую продали потому, что она не имела иной коммерческой ценности. А ещё потому, что как раз разломанная AT&T не могла понять ценность этой разработки. N>Ничего не напоминает?
Тут надо было упоминать года.
V>>Вся индустрия отдавала им деньги, а теперь эти решения, в которые были вложеные деньги индустрии, похерены, считай. V>>Это эпик-фейл мирового масштаба, как ни крути. N>До фейла им ещё далеко. Десктоп держится частично на WinAPI
От WinAPI в WinRT практически ничего не осталось, только слой совместимости.
(хотя студия, браузер и еще куча всего ОП работают на WinAPI, который попал в этот слой)
N>частично таки на наработках UX/UI.
Плюс непонятки с GUI.
В старых системах был общесистемный оконный USER+GDI, в новой версии общесистемный только XAML в песочнице WinRT...
Еще дотнетный WPF, который привязан к конкретному дотнету, и который рисует всё сам в канвасе DirectX, вынужден сам же обслуживать текстовые службы, трансляцию клавиатуры и выглядит в итоге идиотом-инопланетянином, делающим несколько хуже то, что в системе уже есть и сделано лучше.
Все перечисленные технологии удручают по нынешним меркам, это просто полный П... безвременье какое-то (я когда-то обожал упражняться в GUI разработкой новых контролов, сейчас в виндах эта тема токсична)
В общем, не зря на виндах всё больше ПО, выполненого на юниховом (изначально) QT, работающего сегодня поверх юнихового же (изначально) OpenGL. ))
N>А вот то, что они чуть ли не последние, кто продаёт именно ОС (пусть как базу), а не решения и сервис над ней (хотя и это тоже), интересно таки.
Дык, под ними было когда-то аж 97% всех десктопов.
Абсолютные когда-то монополисты...
Я ж говорю — вся индустрия отдавала им деньги...
Деньги должны были, согласно классике жанра, тратиться на разработку ПО следующих поколений...
И что мы имеем сейчас?
Здравствуйте, netch80, Вы писали:
N>Я это особо оценил когда анализировал оконную структуру офисных тулзей вроде Excel. Это в XWindow было window, а был widget, и widget-ов могло быть много внутри window штатным механизмом (начиная с Xaw). Стандартно MS такое не допускала... но внутри Excel использовалось в полный рост!
Внутри Excel почти никаких системных окон (кроме тулбарных и рабочих листов).
Все контролы являются ActiveX windowless контролами, поэтому оно так шустро работало, что не создавало тонны хендлов.
MS Access аналогично, поэтому тоже был шустрым на той дохлой технике.
Здравствуйте, netch80, Вы писали:
V>>Мейнфреймы и мини-ЭВМ. V>>Тогда уже вовсю UNIX-системы набирали обороты, и не только на архитектуре VAX. N>Ну уж точно не на "мейнфреймах", там оно появилось только с ~2000.
IBM IAX появился раньше...
Но речь не только о мейнфреймах...
Это было умирающее направление (универсальные сервера приложений), а массово пошли в конце 80-х и в 90-е т.н. суперкомпьютеры.
N>>>У Intel в 80-х огромная часть кода писалась на ассемблере, потому что компиляторы не тянули. V>>В юнихах на асме писалась только небольшая часть кода.
N>Ты о каком поколении говоришь-то? Unix V6, да, почти полностью уже на C — только с этой версии началось победное шествие. Но это уже лет через 5 после первых версий.
Вообще, странно это слышать, т.к. Си был разработан для реализации UNIX, и, собсно, POSIX — это и есть программный интерфейс UNIX-like систем.
N>Поищи код первой версии cat, например там реально два экрана простого ассемблера — причём это сохранялось ещё на PDP-11.
А почему ты думаешь, что эта утилита была разработана изначально под UNIX?
N>Но Unix никогда не был про чистую эффективность кода.
UNIX всегда был про совместимость на уровне исходников.
Это была новая парадигма, к которой пришли по результату трахания с зоопарком аппаратных архитектур и осей.
Т.е., проблематика уже была известна, решение уже было предложено и неплохо себя показывало...
Сами винды тоже разрабатывались на Си...
Но почему на Си не написали UNIX-like операционку — вопрос вопросов, однако.
Ладно BeOS на плюсах писали, тут всё понятно... ))
Здравствуйте, vdimas, Вы писали:
V>>>Зачем гадать, если серьёзная техника сидела безальтернативно на юнихах? N>>"Серьёзная техника" сидела много на чём, смотря что считать серьёзностью. Самая серьёзная сидела на всяких ESA/390+VM/ESA. V>Это недостаточно серьёзно ввиду отсутствия массовости... V>Да какой "массовости", что я несу? )) V>Было вообще ровно ноль распространнённости, бо IBM тогда уже перешла полностью на продажу машинного времени мейнфреймов, отказавшись от поставки и обслуживания техники.
Ты что курил?
У IBM всегда была модель поставки этих машин в аренду или лизинг с выкупом, обслуживали они сами, но кто хочет — мог и купить в полное владение. Ничего не менялось.
И массовость для "серьёзности" (что бы мы под этим ни понимали) не нужна.
N>>Вторым по уровню "серьёзности" считались VAX+VMS. V>Не, VMS активно устаревала в 80-х.
Это не мешало ей быть актуальной по 100500 параметрам ещё до середины 90-х, а ключевые решения, которые мы, если ты помнишь, начали обсуждать, должны были приниматься вообще в первой половине 80-х. Если не в 70-х. Первый Xenix это 1981.
V>Не зря же System V вышел изначально только на DEC VAX — потому что требовалась замена VMS. V>(System III до этого — аналогично, но не была еще достаточно совершенной ОС)
Для данного вопроса нет разницы.
N>>Рядом маячила AS/400. V>Тю. IBM RS/6000 и наследники — уже юниховые IAX на примерно том же или более серьёзном железе.
Ты вообще про AS/400 что-то слышал, раз такое пишешь? Там плевать какое железо, там VM+API.
V>К концу 80-х годов UNIX-системы уже стали мейнстримом в серверах и рабочих станциях, сие медицинский факт.
Разве что одним из.
V>А так же UNIX-системы стали стандартом де-факто как для суперкомпьютеров, так и для "просто серверов" в академической среде.
V>Собсно, когда я рассуждал о том, чтобы заменить ЕС ЭВМ новыми i486-ми, это можно было сделать только на UNIX-системе с терминалами. V>Безальтернативно! ))
Такс... хост на 486, а терминалы на 8086?
V>При том что большинство юниховодов в середине 90-х ничего кроме Linux не видели? ))
В твоём отделе — может быть.
В интернет-провайдере где я работал — начали с Xenix, шли через Interactive, SCO, BSD/OS, параллельно Linux (но не сразу), FreeBSD, NetBSD, OpenBSD. По состоянию на 2000 FreeBSD было больше, чем Linux — стабильнее по массе параметров, начиная с того, как в 99-м начал 12309 колотить по голове кувалдой
В конторах которые активно использовали юниксы и были нашими клиентами — были линуксы, но на них смотрели как на игрушку, больше всего было Solaris, некоторое количество HP-UX. AIX почти не было.
Время засилья Linux ещё не начиналось. Оно пришло где-то с 2000, заметно подавляюще — с 2005.
V>Над теми первыми версиями линухов лично я громко ржал.
Все ржали. Но хорошо смеётся тот, кто смеётся последним. Увы.
V>Как это, если из более десятка популярных на тот момент серверных осей примено 80% были UNIX-like? )) V>Простая ж арифметика!
Которая тут в принципе неприменима, потому что флаворы переливались один в другой, и можно было сказать, например, что "это SysV на 80%, с элементами BSD и OSF/1". Считать лучше по количеству установок или по суммарной ресурсной мощности, а они по сравнению с парком PC (включая файловые серверы) были мелкими.
V>Плюс для рабочих станций — почти 100%. V>(WinNT еще не было)
И снова — ты о каком времени говоришь? Если Linux массово, то это уже вторая половина 90-х, а тогда и NT была совершенно типовым зверем.
Прогресс был стремителен, не смешивай времена.
V>Лично мне (и не только мне) уже было очевидно, что UNIX-подобные системы неотвратимо завоёвывают серверные вычисления/службы, и вообще область более-менее приличных вычислений.
"Завоёвывают" — и мне было очевидно. А вот сколько уйдёт на это завоевание — никто себе не представлял.
N>>Ну как ты можешь такое нести, сам же видел эти процессы... V>Я был старше, видел и участвовал.
Старше кого? Я не следил, но мне кажется, что мы одногодки. Максимум плюс-минус год.
V>Мы изучали не только сами мейнфреймы, всегда ж давалась еще информация общего плана — сколько их примерно у нас, сколько на западе, каковы тенденции (а это было важно, ес-но). V>Так вот, десятки тыщ штук на весь мир, а топовых — единиц тыщ или единицы сотен совсем топовых на весь мир.
Зато 80-90% финансовых транзакций на них.
V>Для сравнения, общее кол-во "независимых" суперкомьютеров (или просто мощных выч.кластеров) в различных ВУЗ-ах по всему миру уже становилось сравнимым или обгоняло кол-во "централизованных мейнфреймов" к середине 90-х, и в этих независимых суперкомпах или выч.кластерах везде безальтернативно были UNIX-like системы.
Про "безальтернативно" — нет, винда тоже использовалась. Хотя лицензионные проблемы и тогда уже начали давить. Но именно на середину 90-х там обычно были вообще спец-ОС, никак не мэйнстрим.
V>Собсно, критикуемые мною т.н. "суперкомпьютеры" с середины нулевых — это те же самые выч.кластеры из плат уровня мощных первоналок, бо все технологии были давно отлажены уже.
V>Поэтому я не понимаю, как можешь ты такое нести? ))
V>Ведь академические круги ВСЕГДА определяют будущее. V>На чём студент вырос, то он и будет толкать.
Абсолютно верно.
Студенты 90-х уже росли на персоналках. На юниксе они могли сдавать что-то, но для себя они росли на DOS + Windows.
А в вузах? Гейтс винду всех видов в вузы бесплатно отдавал. За все эти бесчисленные юниксы хотели большие деньги. Linux, BSD было немного, их всерьёз не рассматривали.
Насколько это помогло продвижению винды сейчас — считай сам.
V>Ты не обратил внимания, разве, что основную массу программеров составляют люди, обучавшиеся в ВУЗ-ах по IT-специальностям примерно с 88-89-го года и позже? V>(или получавшие второе профильное IT-образование после этих дат)
Ты про какую местность говоришь? exUSSR?
Ну так это только о том говорит, что при СССР идти в это направление было невыгодно.
Я в 90-м поступал с подозрением, что мне придётся, как отцу, в каком-нибудь закрытом КБ (или на него, как он, через университет) рассчитывать полёты ракет.
Выпустился в совсем другом мире.
V>Т.е., начиная с указанных лет поступления, айтишники идут массой, эдакой непрерывной гладкой кривой по годам, как грится. V>Новая принятая тогда программа дала новый менталитет.
Не программа. Падение "железного занавеса". Даже писюки по цене автомобиля, как в начале 90-х, уже резко показали, что всё не так, как раньше.
Ничего программа бы не дала, если бы как прежде не было бы на чём реализовывать разнообразные устремления.
V>>>И всё "это" уже можно было хотя бы немножечко предполагать, что открытое ПО имеет некоторое преимущество вдолгую в мировом масштабе. )) V>>>Стоило бы задуматься — а почему открытое ПО выбрало UNIX-like низкий уровень? N>>Потому что он был уже открыт к тому времени, хотя бы частично. V>Исходники были открыты или ты прочто?
BSD/MIT/etc. license (даже исходная, 4-clause BSD или аналог). Посмотри под какой лицензией собственные доработки BSD выходили ещё в начале 80-х, когда они стали дорабатывать Bell Unix по-своему.
"Любые производные, любая коммерциализация, только копирайты сохраняйте и нас ни в чём не вините".
Столлман стал своё движение вести уже имея этот тип лицензии как пример и отталкиваясь от него.
V>"Просто открыть исходники" мало, они бы погоды не сделали.
Да.
V>UNIX-системы имели отличные открытые спецификации, позволяющие их воспроизвести и безо-всяких исходников. V>Это было решающим, ИМХО.
Нет.
Открытых спецификаций не было. POSIX был платным, не как сейчас, когда только зарегистрируйся на сайте (и то есть URL без этого). Торвальдс повторил POSIX.1 просто по вторичной документации (маны и примеры).
V>Эти системы изначально разрабатывались с расчётом на обширную совместимость прикладных программ в исходных кодах, отсюда столь подробные спецификации даже достаточно низких уровней.
Первая часть — да. Вторая — нет. Специфицированы была, по сути, libc и основные userland утилиты. Это всё. Тебе не давали никаких гарантий ни на сисколлы, ни на ядро.
V>Для сравнения, твои AS/400 выполняли пляски с бубном над бинарными образами, вместо исходников, поэтому почили в бозе, ес-но.
Не почили. Ты не в курсе аж вообще. У них бинарные образы вспомогательны, основа — виртуальная транслируемая или интерпретируемая VM, с AOT или JIT. Представь себе один большой JVM или .NET рантайм на всех пользователей с разделением доступа к объектам по привилегиям.
V>А юниховые исходники с тех или более ранних лет живут и здравствуют, составляя основу современного стандартного юниксового ПО на всевозможных UNIX-like системах на всевозможнейшем же железе.
Нет. Юниксовые по лицензионным причинам переписаны с нуля (часто и методом "чистой комнаты") минимум под два мира — GPL и BSD лицензий. Ты найдёшь исходники, унаследованные от древних систем, только в коммерческих флаворах (Solaris, AIX и прочие).
V>Linux никуда не торопился в первых версиях, это была просто игрушка для исследований.
V>А "выстрелил" он не поэтому, а потому что... V>Да просто посмотри на исходники FreeBSD и на исходники тогдашних линухов...
V>Первое — это ужас, летящий на крыльях ночи. Авторов повесить, потом расстрелять.
Не вижу ужасного. Ткни пальцем в конкретные места.
V>Второе — современная (по тем временам) приятная конфетка, глаз радовался.
Вот эти как раз до сих пор жутковаты.
V>Linux выстрелил только из-за этого, конечно, что к нему сразу потянулись тысячи энтузиастов, которым захотелось поучаствовать в таком приятном проекте. V>Жаль, сам автор донельзя неприятный человек, ну да ладно))
V>Зато он задал отличный дух исходникам, у товарища определённо неплохой вкус. V>Этот стиль легко и приятно читается даже сегодня, спустя ~30 лет.
У меня строго противоположные впечатления.
N>>То есть ключевой момент — когда Беркли взял (купил) для своих научных работ именно систему от Bell, которую продали потому, что она не имела иной коммерческой ценности. А ещё потому, что как раз разломанная AT&T не могла понять ценность этой разработки. N>>Ничего не напоминает? V>Тут надо было упоминать года.
Именно. А не как ты смешиваешь воедино факты с разницей в 10 лет.
Так что именно тебе _тут_ в годах не так?
V>>>Вся индустрия отдавала им деньги, а теперь эти решения, в которые были вложеные деньги индустрии, похерены, считай. V>>>Это эпик-фейл мирового масштаба, как ни крути. N>>До фейла им ещё далеко. Десктоп держится частично на WinAPI V>От WinAPI в WinRT практически ничего не осталось, только слой совместимости. V>(хотя студия, браузер и еще куча всего ОП работают на WinAPI, который попал в этот слой)
А при чём тут вообще WinRT? Он поверх WinAPI работает.
N>>частично таки на наработках UX/UI.
V>Плюс непонятки с GUI. V>В старых системах был общесистемный оконный USER+GDI, в новой версии общесистемный только XAML в песочнице WinRT...
Ты про десктоп говоришь или про где? Никто тебе не запрещает эти user+GDI использовать.
N>>А вот то, что они чуть ли не последние, кто продаёт именно ОС (пусть как базу), а не решения и сервис над ней (хотя и это тоже), интересно таки.
V>Дык, под ними было когда-то аж 97% всех десктопов. V>Абсолютные когда-то монополисты...
V>Я ж говорю — вся индустрия отдавала им деньги... V>Деньги должны были, согласно классике жанра, тратиться на разработку ПО следующих поколений... V>И что мы имеем сейчас?
То же самое. Десктоп — налево. Сервер — направо. Ну, почти всегда. Кто хочет переносимости — жаба, дотнет и прочая.
Разрабатывать "ПО следующих поколений" невозможно, пока нет точных требований. По моему опыту в той конторе, где больше всего работал, за год меняется 5-10% требований к каждому крупному компоненту. За 10 лет они могут измениться чуть менее чем полностью.
Что ты предлагаешь — вместо разработки аккумулировать деньги на спецсчетах?
Здравствуйте, vdimas, Вы писали:
V>>>Мейнфреймы и мини-ЭВМ. V>>>Тогда уже вовсю UNIX-системы набирали обороты, и не только на архитектуре VAX. N>>Ну уж точно не на "мейнфреймах", там оно появилось только с ~2000.
V>IBM IAX появился раньше...
AIX, ты хотел написать?
Ну да, тут есть такое, я не знал:
In 1988, IBM announced AIX/370, also developed by Locus Computing. AIX/370 was IBM's fourth attempt to offer Unix-like functionality for their mainframe line, specifically the System/370 (the prior versions were a TSS/370-based Unix system developed jointly with AT&T c.1980, a VM/370-based system named VM/IX developed jointly with Interactive Systems Corporation c.1984, and a VM/370-based version of TSS/370 named IX/370 which was upgraded to be compatible with UNIX System V). AIX/370 was released in 1990 with functional equivalence to System V Release 2 and 4.3BSD as well as IBM enhancements.
Я имел в виду как они с 1999 начали вбухивать деньги в Linux.
Но, как я понимаю, смысл в AIX на железе 370-390 был маловат. Основное всё-таки пытались делать на POWER (и на x86 чуть-чуть, для пробы)
V>Но речь не только о мейнфреймах... V>Это было умирающее направление (универсальные сервера приложений), а массово пошли в конце 80-х и в 90-е т.н. суперкомпьютеры.
Ты про то, для чего был нужен Unix?
Ну и где эта смерть для "универсальные сервера приложений"?
N>>>>У Intel в 80-х огромная часть кода писалась на ассемблере, потому что компиляторы не тянули. V>>>В юнихах на асме писалась только небольшая часть кода.
N>>Ты о каком поколении говоришь-то? Unix V7, да, почти полностью уже на C — только с этой версии началось победное шествие. Но это уже 1979, лет через 10 после старта.
Молодец, пирожок ждёт на полке. Оба названных тобой потомки Bell V7. А массовая переписка на C происходила в Bell V6, это период около 77-го года (как раз мы в середине детсада были, да?)
Версии до этого — ассемблерные. Переписка на C началась только в V6.
V>Вообще, странно это слышать, т.к. Си был разработан для реализации UNIX, и, собсно, POSIX — это и есть программный интерфейс UNIX-like систем.
Не с рождения, ой не с рождения.
N>>Поищи код первой версии cat, например там реально два экрана простого ассемблера — причём это сохранялось ещё на PDP-11. V>А почему ты думаешь, что эта утилита была разработана изначально под UNIX?
А под что? Multics?
N>>Но Unix никогда не был про чистую эффективность кода. V>UNIX всегда был про совместимость на уровне исходников. V>Это была новая парадигма, к которой пришли по результату трахания с зоопарком аппаратных архитектур и осей.
Согласен — с поправкой на то, что "всегда" это начиная с 4 лет предыдущего развития и последущие ~48.
V>Т.е., проблематика уже была известна, решение уже было предложено и неплохо себя показывало... V>Сами винды тоже разрабатывались на Си... V>Но почему на Си не написали UNIX-like операционку — вопрос вопросов, однако.
Потому что смотрели на VMS как образец.
Потому что уже видели много проблем Unix и хотели их обойти одним рывком.
Потому что хотели плавную совместимость с DOS.
Вполне себе причины.
Здравствуйте, netch80, Вы писали:
V>>Собсно, когда я рассуждал о том, чтобы заменить ЕС ЭВМ новыми i486-ми, это можно было сделать только на UNIX-системе с терминалами. V>>Безальтернативно! )) N>Такс... хост на 486, а терминалы на 8086?
На чём угодно, хоть на Корветах или имеющиеся терминалы от ЕС на RS232 с хабом, который для RS232 паяется на коленке.
Я ж тогда рассуждал о задачах числодробилок (пусть студенческого уровня, не выше курсовика, но тем не менее)
N>По состоянию на 2000 FreeBSD было больше, чем Linux — стабильнее по массе параметров
Возможно.
На тот год я всё еще считал Linux игрушечной системой.
А на работе тогда поддерживали в мультиплатформе еще и SunOS (тоже юниха).
N>В конторах которые активно использовали юниксы и были нашими клиентами — были линуксы, но на них смотрели как на игрушку, больше всего было Solaris, некоторое количество HP-UX. AIX почти не было.
Я тоже ни разу не видел AIX, серваки RS/6000 и выше были дорогими для реалий экс-СССР.
N>Про "безальтернативно" — нет, винда тоже использовалась. Хотя лицензионные проблемы и тогда уже начали давить. Но именно на середину 90-х там обычно были вообще спец-ОС, никак не мэйнстрим.
Академические уникальные сборки различных юнихов всегда.
Студни на этом делали дипломы, а аспиранты — кандидатские про паралелльные вычисления. ))
V>>Ведь академические круги ВСЕГДА определяют будущее. V>>На чём студент вырос, то он и будет толкать. N>Абсолютно верно. N>Студенты 90-х уже росли на персоналках. На юниксе они могли сдавать что-то, но для себя они росли на DOS + Windows.
Это если офисные приложухи.
Сетку у нас держали сначала NetWare, позже различные юниха.
С приходом глобального интернета (примерно с 98-го в нашей провинции) во всех без исключения конторах, в которых работал или в которых помогал настроить окружение — в кач-ве шлюза всегда юниховая машинка.
N>А в вузах? Гейтс винду всех видов в вузы бесплатно отдавал.
Еще раз — это на десктопе.
V>>Ты не обратил внимания, разве, что основную массу программеров составляют люди, обучавшиеся в ВУЗ-ах по IT-специальностям примерно с 88-89-го года и позже? V>>(или получавшие второе профильное IT-образование после этих дат) N>Ты про какую местность говоришь? exUSSR?
Да.
N>Открытых спецификаций не было. POSIX был платным
Это копейки, если речь о разработке новой системы.
Суть в том, что разработать платную альтернативу виндам, используя открытые winapi, было низзя.
(по крайней мере тогда, ХЗ как сегодня)
Т.е. плата за POSIX — это была копеечная плата за само обслуживание открытого для любых желающих стандарта, а не некая чудовищная в деньгах роялти за проприетарщину.
V>>Эти системы изначально разрабатывались с расчётом на обширную совместимость прикладных программ в исходных кодах, отсюда столь подробные спецификации даже достаточно низких уровней. N>Первая часть — да. Вторая — нет. Специфицированы была, по сути, libc и основные userland утилиты. Это всё. Тебе не давали никаких гарантий ни на сисколлы, ни на ядро.
(в линухах были сисколлы под макрой)
Главное, что на уровне исходников происходит совместимость.
Далее.
Само наличие семафоров уже диктует многозадачность, но не диктует её тип — вытесняющий или кооперативный, с переключением в момент опроса примитивов синхронизации.
В этом месте происходит абстрагирование от конкретной реализации.
V>>Для сравнения, твои AS/400 выполняли пляски с бубном над бинарными образами, вместо исходников, поэтому почили в бозе, ес-но. N>Не почили. Ты не в курсе аж вообще. У них бинарные образы вспомогательны, основа — виртуальная транслируемая или интерпретируемая VM, с AOT или JIT.
Я про это и говорил, что сделали упор на переносимость бинарных образов.
N>Представь себе один большой JVM или .NET рантайм на всех пользователей с разделением доступа к объектам по привилегиям.
Не, там техники навроде AOT, вроде, а не JIT-рантайм.
Хотя, могу ошибаться, я о тех системах только в IT-журналах читал, которые в обязаловку выписывал примерно до середины нулевых))
V>>Да просто посмотри на исходники FreeBSD и на исходники тогдашних линухов... V>>Первое — это ужас, летящий на крыльях ночи. Авторов повесить, потом расстрелять. N>Не вижу ужасного. Ткни пальцем в конкретные места.
Сам стиль кода, способ его организации.
Читабельность страдает.
V>>Второе — современная (по тем временам) приятная конфетка, глаз радовался. N>Вот эти как раз до сих пор жутковаты.
Читабельность не в разы лучше, что по тем временам нонсенс.
Потому что системные исходники по тем временам было принято писать __в_Ужасном_стиЛе__ (про typedef забыли?), с БЕСКОНЕЧНЫМИ_ПО_ДЛИНЕ_ИДЕНТИФИКАТОРАМИ_МАКР (push/pop для макр нет?), вычурным форматированием, непоследовательной разбивкой на гигантские модули и прочим таким бредом.
А код линухов читался как "просто код" ))
Модули вменяемого небольшого размера.
Мне исходники заходили сходу, напрягать моск не требовалось от слова совсем.
Кстате, исходники мелкомягкого CRT/CppRT тоже с какой-то версии стали более-менее читабельны. ))
V>>Зато он задал отличный дух исходникам, у товарища определённо неплохой вкус. V>>Этот стиль легко и приятно читается даже сегодня, спустя ~30 лет. N>У меня строго противоположные впечатления.
А системный код точно должен задавать "планку входа" для избранных? ))
Или это такой же код, как любой другой?
Там ничего военного не происходит, везде примитивщина, стоило оформить код по-людски.
N>А при чём тут вообще WinRT? Он поверх WinAPI работает.
Там всё запутанно.
Изначально на WinAPI частично (хотя и по большей части), теперь наоборот — WinAPI во многом маппится при линковке на "родные" реализации WinRT.
V>>Плюс непонятки с GUI. V>>В старых системах был общесистемный оконный USER+GDI, в новой версии общесистемный только XAML в песочнице WinRT... N>Ты про десктоп говоришь или про где? Никто тебе не запрещает эти user+GDI использовать.
При том, что десктоп работает поверх DirectX и к этому DirectX есть доступ?
Но нет системной оконной либы, кроме XAML-ориентированной? ))
Это ж, блин...
Нельзя разве было отделить мух от котлет — контролы отдельно, "движок" описания композиции (буде кто хочет именно XAML) — отдельно?
N>То же самое. Десктоп — налево. Сервер — направо. Ну, почти всегда. Кто хочет переносимости — жаба, дотнет и прочая.
Ну хоть дотнет "отдали народу".
И он только сейчас всерьёз выстреливает. ))
N>Разрабатывать "ПО следующих поколений" невозможно, пока нет точных требований. По моему опыту в той конторе, где больше всего работал, за год меняется 5-10% требований к каждому крупному компоненту. За 10 лет они могут измениться чуть менее чем полностью. N>Что ты предлагаешь — вместо разработки аккумулировать деньги на спецсчетах?
Я с самого начала говорил — что.
У них был успех в GUI-приложухах.
Если охота было свою ось — можно было поступить как яблочники, взять готовое ядро с окружением и присобачить к нему GUI и прочие сугубо прикладные навороты.
У яблочников было меньше ресурсов, они были вынуждены так сделать, и это их спасло.
Но это же сработало бы и при избытке ресурсов, только отдача могла быть больше. ))
Здравствуйте, netch80, Вы писали:
N>Но, как я понимаю, смысл в AIX на железе 370-390 был маловат. Основное всё-таки пытались делать на POWER (и на x86 чуть-чуть, для пробы)
Да, по тем временам у них вышли удачные серверные POWER-процы, даже была широкая шумиха в узких кругах.
И IBM вложился в свою UNIX-like операционку.
N>Я имел в виду как они с 1999 начали вбухивать деньги в Linux.
ИМХО, для поддержки линухами своего железа, как и HP в линуха вкладывались.
Т.е., IBM заранее увидела, что с этим Linux не всё так просто... "это ж-ж-ж не спроста" (С)
Де-факто интерес к линухам шёл с низу, от простых разработчиков, "винтиков".
Глаза горят (красненьким), энтузиазма полные штаны!
А это в массе такая масса... ))
V>>Но речь не только о мейнфреймах... V>>Это было умирающее направление (универсальные сервера приложений), а массово пошли в конце 80-х и в 90-е т.н. суперкомпьютеры. N>Ты про то, для чего был нужен Unix? N>Ну и где эта смерть для "универсальные сервера приложений"?
Выражалась в потере долей вычислений — ВУЗ-ы переставали обращаться к мейнфреймам.
Я ж говорил, что происходит в академке — за тем будущее.
А там на "больших машинах" и вообще в сетке происходили юниха.
И не только в академке.
Кластеры того же Оракла на биржах на чём работали, по-твоему?
(ты там говорил про бизнес-транзакции)
Да и сейчас на юнихах, просто на других — почти всегда RHEL, т.е. линуха стали "взрослыми". ))
N>Молодец, пирожок ждёт на полке. Оба названных тобой потомки Bell V7. А массовая переписка на C происходила в Bell V5-V6, это период 73-75 годов (как раз мы из ясель в детсады переходили, да?)
При чём тут 70-е года и момент начала разработки MS своей операционки?
Мы про это зацепились.
На тот момент, ИМХО, юниха были уже вполне mature.
N>Версии до этого — ассемблерные. V>>Вообще, странно это слышать, т.к. Си был разработан для реализации UNIX, и, собсно, POSIX — это и есть программный интерфейс UNIX-like систем. N>Не с рождения, ой не с рождения.
Возможно, но это было давно и не правда уже на середину 80-х.
N>>>Поищи код первой версии cat, например там реально два экрана простого ассемблера — причём это сохранялось ещё на PDP-11. V>>А почему ты думаешь, что эта утилита была разработана изначально под UNIX? N>А под что? Multics?
Аналоги этой утилиты были во всех операционках, на минуточку.
Достаточно было взять готовый код и чуть подпилить под низлежащее АПИ.
Я не думаю, что все юниха разрабатывались с чистого листа, да это просто было бы бессмысленным, ИМХО, имея на руках свои несколько работающих ОС и кучи готовых утилит в сырцах.
Даже взять Linux — ядро и некий системный слой с чистейшего листа.
Но утилиты, ЯП и вообще ср-ва разработки — уже от GNU в сырцах и от других юнихов (от фряхи много шло в сырцах когда-то).
V>>UNIX всегда был про совместимость на уровне исходников. V>>Это была новая парадигма, к которой пришли по результату трахания с зоопарком аппаратных архитектур и осей. N>Согласен — с поправкой на то, что "всегда" это начиная с 4 лет предыдущего развития и последущие ~48.
Не-не-не...
Даже если ядро первых линухов и часть системных утилит были писаны на асме вылизывания ради, программный интерфейс для целевых приложух всё-равно сишный.
По крайней мере, я не слышал другой информации о цели разработки этой ОС, кроме целей заложенной переносимости.
АПИ ОС до этого строилось по прерываниям и сисколам, было специфицировано "вербально" — в бумажной спецификации.
А тут дали АПИ на языке высокого уровня.
Это было внове и это теперь мировой стандарт де-факто.
(кроме BeOS, у которой C++ АПИ)
Я ж уже стебался, что WinAPI изначально описан в Си-сырцах, но почему-то это не UNIX-like. ))
N>Потому что уже видели много проблем Unix и хотели их обойти одним рывком.
Какие, например?
N>Потому что хотели плавную совместимость с DOS.
Совместимость с DОS в юнихах делается аж бегом...
Сам проц был разработан таким образом, чтобы поддерживать 16-битный режим из 32-битного.
