OS Windows на службе отечественного ВМФ. Плюсы и минусы…

Harsky> кому нужна двоичная совместимость на уровне системы команд?
Harsky> API/ABI решают все и две самые распространенные системы на x86 не могут тут похвастаться чем-то выдающимся.

Вах! Канэшна никаму нэ нужна! Особенно в середине 90-х. И потому все почему-то не кинулись на Альфу, которая, в отличие от СПАРКов, уж в самом деле была побыстрее Интела в 90-х.

ЗЫ а вы вообще себе представляете ограничения на машинный код х86 и всяких RISCов? Ну, по зависимостям по данным там, по выравниванию кода/данных и т.д.?

adv1971> P.S. Я вообще то там работаю, так что когда I8086 сделали, знаю и знал ранее и без вас.

Я вижу.

adv1971> Но расписывать, что Интел всю свою историю был круче яиц и выше гор, я не собираюсь, ибо это неправда.
adv1971> Причина успеха Интел в другом, в ставке на массовость и удешевление и в изначальном замысле IBM на открытость архитектуры.

Причина успеха Интела в том, что с точки зрения применённых архитектурных решений она была именно что впереди планеты всей. И в 1996-ом году (выход Pentium Pro) тоже. Все IBMы, DECы и Sun'ы (не говоря уже о непосредственных конкурентах) нервно курили в сторонке. И обеспечение совместимости (причём нативной, а не эмуляции) с заданным набором инструкций было основным фактором, мешавшим сделать ещё больший скачёк в производительности.

Harsky>> кому нужна двоичная совместимость на уровне системы команд?
надо наверное было отдельно указать что когда исходники потеряны, а разработчики поумирали от старости, то возможны некоторые затруднения?

Harsky>> API/ABI решают все и две самые распространенные системы на x86 не могут тут похвастаться чем-то выдающимся.
Kernel3> Вах! Канэшна никаму нэ нужна! Особенно в середине 90-х. И потому все почему-то не кинулись на Альфу, которая, в отличие от СПАРКов, уж в самом деле была побыстрее Интела в 90-х.
те кому была нужна числодробилка как раз кинулись. у нас в конторе была парочка двухголовых. ядро на них быстро собиралось
но большинству нужно было подешевле, а не побыстрее, так что не надо народ путать. ничего подешевле x86 не было, нет и скорее всего уже не будет.
про трудности перехода с одну систему команд на другую мне сказки рассказывать не надо. я (как пользователь и как админ) пережил пяток таких переходов. при правильном подходе их вообще можно не заметить

Kernel3> ЗЫ а вы вообще себе представляете ограничения на исходный код х86 и всяких RISCов? Ну, по зависимостям по данным там, по выравниванию кода/данных и т.д.?
не знаю что такое "исходный код", но если это то, о чем я подумал, то в общих чертах представляю. но еще лучше знаю что об это должен знать разработчик компилятора, а прикладнику это нафиг не нужно. вы же не собираетесь систему управления кораблем писать на асме?

Harsky> те кому была нужна числодробилка как раз кинулись. у нас в конторе была парочка двухголовых. ядро на них быстро собиралось

"Кинуться" можно по-разному. Например, назовите хотя бы две (лучше три) ОС для данной платформы

Harsky> но большинству нужно было подешевле, а не побыстрее, так что не надо народ путать. ничего подешевле x86 не было, нет и скорее всего уже не будет.
Harsky> про трудности перехода с одну систему команд на другую мне сказки рассказывать не надо. я (как пользователь и как админ) пережил пяток таких переходов. при правильном подходе их вообще можно не заметить

Ну-ну. Переведите "правильно" Windows 9x на другую платформу. Неважно какую.

Kernel3>> ЗЫ а вы вообще себе представляете ограничения на исходный код х86 и всяких RISCов? Ну, по зависимостям по данным там, по выравниванию кода/данных и т.д.?
Harsky> не знаю что такое "исходный код", но если это то, о чем я подумал, то в общих чертах представляю. но еще лучше знаю что об это должен знать разработчик компилятора,

Именно. И наличие/отсутствие развитых средств разработки для данной платформы тоже является немаловажным фактором для её (не)выбора, так ведь?

Harsky> а прикладнику это нафиг не нужно. вы же не собираетесь систему управления кораблем писать на асме?

Эт смотря какой корабль

Harsky>> те кому была нужна числодробилка как раз кинулись. у нас в конторе была парочка двухголовых. ядро на них быстро собиралось
Kernel3> "Кинуться" можно по-разному. Например, назовите хотя бы две (лучше три) ОС для данной платформы
True64, GNU/Linux, Windows NT, VMS, BSD
три из вышеперечисленных имели официальную поддержку

Harsky>> но большинству нужно было подешевле, а не побыстрее, так что не надо народ путать. ничего подешевле x86 не было, нет и скорее всего уже не будет.
Harsky>> про трудности перехода с одну систему команд на другую мне сказки рассказывать не надо. я (как пользователь и как админ) пережил пяток таких переходов. при правильном подходе их вообще можно не заметить
Kernel3> Ну-ну. Переведите "правильно" Windows 9x на другую платформу. Неважно какую.
как у вас с логикой, нормально? тогда пройдитесь по всему списку операционок у докажите что у них есть сложности с портированием на другие архитектуры. пока что вы привели пример непортабельности одной конкретной ОС

Kernel3> Kernel3>> ЗЫ а вы вообще себе представляете ограничения на исходный код х86 и всяких RISCов? Ну, по зависимостям по данным там, по выравниванию кода/данных и т.д.?
Harsky>> не знаю что такое "исходный код", но если это то, о чем я подумал, то в общих чертах представляю. но еще лучше знаю что об это должен знать разработчик компилятора,
Kernel3> Именно. И наличие/отсутствие развитых средств разработки для данной платформы тоже является немаловажным фактором для её (не)выбора, так ведь?
вам недостаточно gcc и qcc?

Harsky>> а прикладнику это нафиг не нужно. вы же не собираетесь систему управления кораблем писать на асме?
Kernel3> Эт смотря какой корабль
да любой, и не только корабль. нет сейчас жесткой необходимости использовать в разработке прикладного ПО ассемблер

Kernel3>> Ну-ну. Переведите "правильно" Windows 9x на другую платформу. Неважно какую.
Harsky> как у вас с логикой, нормально? тогда пройдитесь по всему списку операционок у докажите что у них есть сложности с портированием на другие архитектуры. пока что вы привели пример непортабельности одной конкретной ОС

С логикой у меня замечательно. Я к тому, что в "самом общем" случае перенос ПО - это не просто сложная, а крантец какая сложная задача. Особенно, если переносимое ПО не задумывалось как мультиплатформенное/платформонезависимое. Это для вас новость? Собственно, little/big endian фишек уже достаточно, чтобы куча софтовых систем встала в интересное положение при попытке переноса.

Kernel3>> Именно. И наличие/отсутствие развитых средств разработки для данной платформы тоже является немаловажным фактором для её (не)выбора, так ведь?
Harsky> вам недостаточно gcc и qcc?

Смотря для какой задачи.

Harsky> да любой, и не только корабль. нет сейчас жесткой необходимости использовать в разработке прикладного ПО ассемблер

Сейчас - может быть. Но сейчас не середина 90-х.

ЗЫ ну и ещё разок, собственно, о "ненужности" бинарной совместимости: а Itanium, по-вашему, из-за чего умер? Из-за своей теплоотдачи?

adv1971>> Причина успеха Интел в другом, в ставке на массовость и удешевление и в изначальном замысле IBM на открытость архитектуры.
Kernel3> Причина успеха Интела в том, что с точки зрения применённых архитектурных решений она была именно что впереди планеты всей. И в 1996-ом году (выход Pentium Pro) тоже. Все IBMы, DECы и Sun'ы (не говоря уже о непосредственных конкурентах) нервно курили в сторонке.
это какие-такие решение применила intel, что остальные наплевали на предупреждения минздрава ссср?
кэш, конвейер, предсказание ветвлений, спекулятивное исполнение, векторные блоки, TLB, гипервизор, SMP... хоть что-нибудь из этого списка было впервые реализовано intel'ом? единственную революцию с vliw (для массового рынка, а не в единичном виде) - и то просрали. из-за MS в первую очередь. то что было естественной защитой от конкурентов отлично послужило охраной от шага влево/вправо.
сила x86 в двух вещах - открытость ibm pc и непортабельность dos/win. все. использовала бы в свое время ibm не dos, а linux (если бы он был конечно) и об архитектуре в своем настольном компе народ сейчас задумывался бы гораздо меньше

Harsky> кэш, конвейер, предсказание ветвлений, спекулятивное исполнение, векторные блоки, TLB, гипервизор, SMP... хоть что-нибудь из этого списка было впервые реализовано intel'ом?

ЕМНИС, всё, кроме векторных блоков и гипервизора. А ещё первый ЦПУ с > 1 млн. транзисторов и > 1MFLOPS Но вы не передёргивайте. Вы возьмите конкретный Pentium Pro и сравните с одногодками. Хоть с Альфой, хоть с 620-ым PowerPC. А вообще, вот как-то так:

встроенный кэш - 80486, 1989-ый;
конвейер - формально 80286 (1982-ой), реально нечто похожее было в 8086 (1978);
предсказание ветвлений - тривиальный случай в Pentium (1993). Не самая первая, но первая массовая реализация;
спекулятивное выполнение - Pentium Pro (1996). Первая реализация, бо speculative execution != out of order execution;
"TLB" (на самом деле страничное преобразование) - 80386 (1986).

Harsky> единственную революцию с vliw (для массового рынка, а не в единичном виде) - и то просрали. из-за MS в первую очередь. то что было естественной защитой от конкурентов отлично послужило охраной от шага влево/вправо.

Во-во. Причём именно потому, что забили на бинарную совместимость
Upd: кстати, с VLIW - это тоже неправда. Впервые оно было реализовано на i860 (1989)

Harsky> сила x86 в двух вещах - открытость ibm pc и непортабельность dos/win. все. использовала бы в свое время ibm не dos, а linux (если бы он был конечно) и об архитектуре в своем настольном компе народ сейчас задумывался бы гораздо меньше

Гы-гы. А название Xenix ни о чём не говорит?

Kernel3> Я к тому, что в "самом общем" случае перенос ПО - это не просто сложная, а крантец какая сложная задача.
когда у разработчиков oracle поинтересовались о том, насколько сложно им пришлось при портировании 8-ки на linux, то они ответили - "мы запустили make"

Kernel3> Особенно, если переносимое ПО не задумывалось как мультиплатформенное/платформонезависимое. Это для вас новость?
для меня довольно свежо и не избито выглядит ваша мысль о том что серьезные вещи пишут без расчета на переносимость.

Kernel3> Собственно, little/big endian фишек уже достаточно, чтобы куча софтовых систем встала в интересное положение при попытке переноса.
htonl(), htons(), ntohl(), ntohs()
стандарты за тем и придуманы, чтоб можно было без изобретения велосипедов обойтись

Harsky>> да любой, и не только корабль. нет сейчас жесткой необходимости использовать в разработке прикладного ПО ассемблер
Kernel3> Сейчас - может быть. Но сейчас не середина 90-х.
в середине 90-х были прекрасные процессоры и память уже стоила за мегабайт копейки (по меркам стоимости разработчика)

Kernel3> ЗЫ ну и ещё разок, собственно, о "ненужности" бинарной совместимости: а Itanium, по-вашему, из-за чего умер? Из-за своей теплоотдачи?
из-за ОС. я выше упоминал

Harsky> когда у разработчиков oracle поинтересовались о том, насколько сложно им пришлось при портировании 8-ки на linux, то они ответили - "мы запустили make"

И чего? Я то же самое про все продукты своей предыдущей конторы сказать могу.

Kernel3>> Особенно, если переносимое ПО не задумывалось как мультиплатформенное/платформонезависимое. Это для вас новость?
Harsky> для меня довольно свежо и не избито выглядит ваша мысль о том что серьезные вещи пишут без расчета на переносимость.

Ещё раз: когда? В 2000-х? Да, пожалуй. В 90-е, а тем, более, 80-е ситуация была совсем другой.

Kernel3>> Собственно, little/big endian фишек уже достаточно, чтобы куча софтовых систем встала в интересное положение при попытке переноса.
Harsky> htonl(), htons(), ntohl(), ntohs()
Harsky> стандарты за тем и придуманы, чтоб можно было без изобретения велосипедов обойтись

Для этого "всего лишь" надо, чтобы ПО имело представление о том, какие величины у него little, а какие - big edian.

Kernel3>> ЗЫ ну и ещё разок, собственно, о "ненужности" бинарной совместимости: а Itanium, по-вашему, из-за чего умер? Из-за своей теплоотдачи?
Harsky> из-за ОС. я выше упоминал

А отсутствие ОС никакого отношения к бинарной совместимости не имело? Просто, карта так легла, типа?

Kernel3> "TLB" (на самом деле страничное преобразование) - 80386 (1986).

Ай, вот на 386 был вовсе не не TLB, а сам-чёрт-ногу-сломит. Кошмар какой-то, завихрение мозга...

Kernel3>> "TLB" (на самом деле страничное преобразование) - 80386 (1986).
Серокой> Ай, вот на 386 был вовсе не не TLB, а сам-чёрт-ногу-сломит. Кошмар какой-то, завихрение мозга...

Чегой-то? Насчёт аппаратной реализации не знаю, а с программной ( ) он точно так же выглядел

Kernel3> Чегой-то? Насчёт аппаратной реализации не знаю, а с программной ( ) он точно так же выглядел

точно так же как что? Получать 20-битный адрес методом сдвига одного адреса на 4 с последующим суммированием со вторым - это что, нормальная TLB? )

Серокой> точно так же как что?

Как последующие Программно, ЕМНИС, там только операция сброса буфера доступна

Серокой> Получать 20-битный адрес методом сдвига одного адреса на 4 с последующим суммированием со вторым - это что, нормальная TLB? )

24 бита - это i386SX А "честный" 80386 (он же позднее i386DX) - таки 32-битный по шине адреса И шине данных тоже. Она там, ЕМНИС, мультиплексирована.

Kernel3> 24 бита - это i386SX А "честный" 80386 (он же позднее i386DX) - таки 32-битный по шине адреса И шине данных тоже. Она там, ЕМНИС, мультиплексирована.

Ну вот про эту систему - формирования адреса из сдивга и дескриптора - я и говорю, что взрыв мозга. ) Нормальная TLB по моему мнению - это ассоциативная память на столько-то записей, скажем, на 32 или 64. На вход приходит виртуальный адрес с идентификатором запущенной задачи, на выходе имеем физический адрес. Просто и понятно. )

Серокой> Ну вот про эту систему - формирования адреса из сдивга и дескриптора - я и говорю, что взрыв мозга. ) Нормальная TLB по моему мнению - это ассоциативная память на столько-то записей, скажем, на 32 или 64. На вход приходит виртуальный адрес с идентификатором запущенной задачи, на выходе имеем физический адрес. Просто и понятно. )

Аа. Дык, тогда на всех х86 она ненормальная Зато самая первая реализация! На первых Интеловских RISCах (i860/i960), кстати, вроде, то же самое (2 уровня табличек).

Harsky>> кэш, конвейер, предсказание ветвлений, спекулятивное исполнение, векторные блоки, TLB, гипервизор, SMP... хоть что-нибудь из этого списка было впервые реализовано intel'ом?
Kernel3> ЕМНИС, всё, кроме векторных блоков и гипервизора.
можно со ссылками, подтверждающими такие смелые заявления?

Kernel3> А ещё первый ЦПУ с > 1 млн. транзисторов и > 1MFLOPS
идеальный процессор вообще не имеет транзисторов, не занимает площади на кристале, не потребляет электричества, но при этом работает. так что > 1млн - это от безысходности...

Kernel3> Но вы не передёргивайте. Вы возьмите конкретный Pentium Pro и сравните с одногодками. Хоть с Альфой, хоть с 620-ым PowerPC.
ну что же вы так подставляетесь-то
EV5 (1994) / PPro (1995)
разрядность: 64bit / 32 bit
частота: 266-500MHz / 150-200MHz
кеш: 16+96Kb+1Mb / 16Kb + 256Kb (после 512)
транзисторы: 9.7 млн / 5 млн

Kernel3> конвейер - формально 80286 (1982-ой), реально нечто похожее было в 8086 (1978);
Kernel3> предсказание ветвлений - тривиальный случай в Pentium (1993). Не самая первая, но первая массовая реализация;
Kernel3> спекулятивное выполнение - Pentium Pro (1996). Первая реализация, бо speculative execution != out of order execution;
Kernel3> "TLB" (на самом деле страничное преобразование) - 80386 (1986).
странно, я-то думал что большинство из вышеперечисленного (за исключением спекуляций) было придумано IBM для 360-серии или для концепта RISC-процессора

Kernel3> Upd: кстати, с VLIW - это тоже неправда. Впервые оно было реализовано на i860 (1989)
неправда, первым из мне известных был эльбрус, если уж пошла такая пьянка

Kernel3> Гы-гы. А название Xenix ни о чём не говорит?
говорит кое о чем, но на какие-то мысли не наводит

Harsky>>> кэш, конвейер, предсказание ветвлений, спекулятивное исполнение, векторные блоки, TLB, гипервизор, SMP... хоть что-нибудь из этого списка было впервые реализовано intel'ом?
Kernel3>> ЕМНИС, всё, кроме векторных блоков и гипервизора.
Harsky> можно со ссылками, подтверждающими такие смелые заявления?

А перечитать моё сообщение слабо?

Kernel3>> А ещё первый ЦПУ с > 1 млн. транзисторов и > 1MFLOPS
Harsky> идеальный процессор вообще не имеет транзисторов, не занимает площади на кристале, не потребляет электричества, но при этом работает. так что > 1млн - это от безысходности...

И сами же ниже сравниваете по числу транзисторов в том числе

Harsky> Но вы не передёргивайте. Вы возьмите конкретный Pentium Pro и сравните с одногодками. Хоть с Альфой, хоть с 620-ым PowerPC.
Harsky> ну что же вы так подставляетесь-то
Harsky> EV5 (1994) / PPro (1995)
Harsky> разрядность: 64bit / 32 bit
Harsky> частота: 266-500MHz / 150-200MHz
Harsky> кеш: 16+96Kb+1Mb / 16Kb + 256Kb (после 512)
Harsky> транзисторы: 9.7 млн / 5 млн

И? Вот есть мнение, что "разрядность" ЦПУ - это разрядность внешней шины данных на самом деле. Да и вообще, прикольно сравниваете. По числу исполнительных устройств и префетчеров/декодеров сравнить не хотите? А также способности аппаратно разрешать зависимости по данным. Ну и прочие там мелочи, вроде эффективности этого самого предсказания переходов.

Kernel3>> конвейер - формально 80286 (1982-ой), реально нечто похожее было в 8086 (1978);
Kernel3>> предсказание ветвлений - тривиальный случай в Pentium (1993). Не самая первая, но первая массовая реализация;
Kernel3>> спекулятивное выполнение - Pentium Pro (1996). Первая реализация, бо speculative execution != out of order execution;
Kernel3>> "TLB" (на самом деле страничное преобразование) - 80386 (1986).
Harsky> странно, я-то думал что большинство из вышеперечисленного (за исключением спекуляций) было придумано IBM для 360-серии или для концепта RISC-процессора

О, т.е. мы уже не о микропроцессорах? Прикольно Да ещё и "концепты" какие всплыли Вот, например, "концепт" будущего Итаниума у Интел был в 1989-ом. Это как: достижение или не очень?

Kernel3>> Upd: кстати, с VLIW - это тоже неправда. Впервые оно было реализовано на i860 (1989)
Harsky> неправда, первым из мне известных был эльбрус, если уж пошла такая пьянка

Какой именно "Эльбрус"?

Kernel3>> Гы-гы. А название Xenix ни о чём не говорит?
Harsky> говорит кое о чем, но на какие-то мысли не наводит

Ну, вот была такая система. Из тех, что тогда называли "Unix-подобными", а позже - "POSIX-совместимыми". Но не пошла она на х86. Точнее, пошла попозже и под другим названием. Заговор, не иначе

Harsky>> когда у разработчиков oracle поинтересовались о том, насколько сложно им пришлось при портировании 8-ки на linux, то они ответили - "мы запустили make"
Kernel3> И чего? Я то же самое про все продукты своей предыдущей конторы сказать могу.
что и требовалось доказать. нет проблем с переносом ПО. по крайней мере таких, которые не решаются набором команды make (при написании программы с учетом переездов)

Kernel3> Kernel3>> Особенно, если переносимое ПО не задумывалось как мультиплатформенное/платформонезависимое. Это для вас новость?
Harsky>> для меня довольно свежо и не избито выглядит ваша мысль о том что серьезные вещи пишут без расчета на переносимость.
Kernel3> Ещё раз: когда? В 2000-х? Да, пожалуй. В 90-е, а тем, более, 80-е ситуация была совсем другой.
тут вроде бы никто не был против отфанарного утверждения о том что 486 за глаза хватит на систему управления кораблем и попутно всеми светофорами парижа. в 80-х эта производительность была доступна, хоть и не в одном камне.

Harsky>> htonl(), htons(), ntohl(), ntohs()
Kernel3> Для этого "всего лишь" надо, чтобы ПО имело представление о том, какие величины у него little, а какие - big edian.
разве с этим какие-то проблемы?

Kernel3> Kernel3>> ЗЫ ну и ещё разок, собственно, о "ненужности" бинарной совместимости: а Itanium, по-вашему, из-за чего умер? Из-за своей теплоотдачи?
Harsky>> из-за ОС. я выше упоминал
Kernel3> А отсутствие ОС никакого отношения к бинарной совместимости не имело? Просто, карта так легла, типа?
еще раз: то что MS не портировал win (портировал, да больше вопросав, чем ответов) ничего не говорит о ненужности бинарной совместимости. это говорит чкорее о ненужности MS

Kernel3>> И чего? Я то же самое про все продукты своей предыдущей конторы сказать могу.
Harsky> что и требовалось доказать. нет проблем с переносом ПО. по крайней мере таких, которые не решаются набором команды make (при написании программы с учетом переездов)

А кто с этим спорит? Проблема в том, что не писали особо в 80-е (да и 90-е тоже) с "учётом переездов". Только и всего.

Kernel3>> Для этого "всего лишь" надо, чтобы ПО имело представление о том, какие величины у него little, а какие - big edian.
Harsky> разве с этим какие-то проблемы?

Опять 26 Да, с учётом вышесказанного, с этим проблемы. Были. Очень и очень серьёзные.

Harsky> еще раз: то что MS не портировал win (портировал, да больше вопросав, чем ответов) ничего не говорит о ненужности бинарной совместимости. это говорит чкорее о ненужности MS

А ничего, что в случае бинарной совместимости ничего особо портировать бы и не пришлось?

Harsky>> идеальный процессор вообще не имеет транзисторов, не занимает площади на кристале, не потребляет электричества, но при этом работает. так что > 1млн - это от безысходности...
Kernel3> И сами же ниже сравниваете по числу транзисторов в том числе
ну вы же хотели сравнений по этой породе попугаев

да ради бога, давайте посмотрим на на тесты производительности:
ppro 200 MHz, 366 SPECint92, SPECfp92 283
ev5 266 MHz, SPECint92 330, SPECfp92 500
это сравнивалась старшая модель PPro с младшей EV5 (раньше я для них же давал другие сравнения). еще какие-то вопросы по скорости работы?

Kernel3> И? Вот есть мнение, что "разрядность" ЦПУ - это разрядность внешней шины данных на самом деле.
это неверное мнение. разрядностей бывает много, но в первую очередь это относится к АЛУ

Kernel3> Да и вообще, прикольно сравниваете. По числу исполнительных устройств и префетчеров/декодеров сравнить не хотите?
зачем? чтобы убедиться в том что бинарная совместимость дается слишком дорогой ценой?

Kernel3> А также способности аппаратно разрешать зависимости по данным. Ну и прочие там мелочи, вроде эффективности этого самого предсказания переходов.
сравнивайте. я свою подшивку ComputerWorld лет 10-12 назад выкинул, так что делать сейчас сводные таблицы только для того чтобы убедиться в отсутствии революционной крутизны intel'a на фоне тогда еще неудушенных конкурентов не желаю. вы еще похвастайтесь 24 (или сколько их там?) ступенями конвейера PIV, постаравшись умолчать о причинах, по которым он таким длинным получился

кое в чем вы правы или - многие новшества у intel в кристалле (рассыпухой я уже упомянал) появились раньше, чем у других. я долго думал - как же так получилось, что ничем не примечательные процессоры изнутри оказались такими уникальными. или наоборот: такие революционные камешки, а в топах не числились. предлагаю вам ответить на него

Kernel3> Какой именно "Эльбрус"?
это неудачная шутка была, про эльбрус

Kernel3> Kernel3>> Гы-гы. А название Xenix ни о чём не говорит?
Harsky>> говорит кое о чем, но на какие-то мысли не наводит
Kernel3> Ну, вот была такая система. Из тех, что тогда называли "Unix-подобными", а позже - "POSIX-совместимыми". Но не пошла она на х86. Точнее, пошла попозже и под другим названием. Заговор, не иначе
все равно не понял, при чем тут unix, особенно этот конкретный на x86. развивайте мысль

Harsky> ну вы же хотели сравнений по этой породе попугаев
Harsky> да ради бога, давайте посмотрим на на тесты производительности:
Harsky> ppro 200 MHz, 366 SPECint92, SPECfp92 283
Harsky> ev5 266 MHz, SPECint92 330, SPECfp92 500
Harsky> это сравнивалась старшая модель PPro с младшей EV5 (раньше я для них же давал другие сравнения). еще какие-то вопросы по скорости работы?

А я о скорости работы разве говорил? Троллить изволите? Ну-ну.

Kernel3>> И? Вот есть мнение, что "разрядность" ЦПУ - это разрядность внешней шины данных на самом деле.
Harsky> это неверное мнение. разрядностей бывает много, но в первую очередь это относится к АЛУ

Это вы так думаете.

Harsky> кое в чем вы правы или - многие новшества у intel в кристалле (рассыпухой я уже упомянал) появились раньше, чем у других. я долго думал - как же так получилось, что ничем не примечательные процессоры изнутри оказались такими уникальными. или наоборот: такие революционные камешки, а в топах не числились. предлагаю вам ответить на него

Уже ответил. Учитесь читать (с)

Kernel3>> Какой именно "Эльбрус"?
Harsky> это неудачная шутка была, про эльбрус

Очень неудачная

Harsky> все равно не понял, при чем тут unix, особенно этот конкретный на x86. развивайте мысль

Вот сами и развивайте свою: "Вот был бы Линукс..." Ну, вот был Зеникс. И что дальше? Он вытеснил DOS/Win?
Или хотя бы OS/2? Нет? Так может, на то были свои причины?

Kernel3> А я о скорости работы разве говорил? Троллить изволите? Ну-ну.
есть немного, подменил ничего не значащее понятие "совершенство архитектуры" на ключевое "скорость работы"

Kernel3> Kernel3>> И? Вот есть мнение, что "разрядность" ЦПУ - это разрядность внешней шины данных на самом деле.
Harsky>> это неверное мнение. разрядностей бывает много, но в первую очередь это относится к АЛУ
Kernel3> Это вы так думаете.
Это вы так ошибаетесь:

Разрядностью микропроцессорной системы принято считать количество бит информации, которое ее ЦП может обработать с помощью одной команды. Разрядность микропроцессора определяется разрядностью его АЛУ, внутренних регистров данных и внешней шины данных. На сегодняшний день существуют 8-, 16-, 32- и 64-разрядные микропроцессоры. Для того, чтобы обрабатывать информацию с разрядностью большей, чем разрядность микропроцессора необходимо реализовывать специальные алгоритмы вычислений с повышенной разрядностью. Эти алгоритмы требуют дополнительного времени для своего выполнения. Поэтому повышение разрядности микропроцессора при заданной разрядности вычислений, напрямую связано с увеличением быстродействия системы

 

и еще:

Разрядностть МП обозначается m/n/k/ и включает:
m - разрядность внутренних регистров, определяет принадлежность к тому или иному классу процессоров;
n - разрядность шины данных, определяет скорость передачи информации;
k - разрядность шины адреса, определяет размер адресного пространства. Например, МП i8088 характеризуется значениями m/n/k=16/8/20;

 

Kernel3> Вот сами и развивайте свою: "Вот был бы Линукс..." Ну, вот был Зеникс. И что дальше? Он вытеснил DOS/Win?
Kernel3> Или хотя бы OS/2? Нет? Так может, на то были свои причины?

Xenix — Unix-подобная операционная система, лицензированная фирмой Microsoft у AT&T в конце 1970-х. Первые версии работали на процессорах Intel 80286, затем была введена поддержка Intel 80386

 

UPD: IBM PC началась немного раньше чем 286. OS/2 тоже опоздала.

Kernel3>>> И чего? Я то же самое про все продукты своей предыдущей конторы сказать могу.
Harsky>> что и требовалось доказать. нет проблем с переносом ПО. по крайней мере таких, которые не решаются набором команды make (при написании программы с учетом переездов)
Kernel3> А кто с этим спорит? Проблема в том, что не писали особо в 80-е (да и 90-е тоже) с "учётом переездов". Только и всего.
еще как писали. прямо сейчас я набираю этот пост из-под операционки, прабабка которой была написана с учетом переносимости лет 40 назад. с тех пор она и ее потомки успели поработать практически на всех железках, которые были мощнее калькулятора.
году в 96 наблюдал также photoshop на irix. oracle наблюдаю каждый день на, как минимум, трех платформах и т.д.
кажется все более-менее серьезные конторы отметились своими продуктами на разных платформах и не переломились попалам от усилий

Harsky>> еще раз: то что MS не портировал win (портировал, да больше вопросав, чем ответов) ничего не говорит о ненужности бинарной совместимости. это говорит чкорее о ненужности MS
Kernel3> А ничего, что в случае бинарной совместимости ничего особо портировать бы и не пришлось?
а ничего что рано или поздно об этом приходится думать чтобы продукт мог продолжать жить?
или об этом думаю сразу и не испытывают каких-то мегатрудностей при освоении новой платформы или начинают переносить когда жареный петух клюнет и тут уж как повезет. слишком немногие могут позволить себе забить на это

Kernel3>> А я о скорости работы разве говорил? Троллить изволите? Ну-ну.
Harsky> есть немного, подменил ничего не значащее понятие "совершенство архитектуры" на ключевое "скорость работы"

Ну, тогда замените на ещё более ключевое "время жизни платформы".

Kernel3>> Kernel3>> И? Вот есть мнение, что "разрядность" ЦПУ - это разрядность внешней шины данных на самом деле.
Harsky> Harsky>> это неверное мнение. разрядностей бывает много, но в первую очередь это относится к АЛУ
Kernel3>> Это вы так думаете.
Harsky> Это вы так ошибаетесь:

И? Откуда эта цитата? Почему я её должен считать истиной в последней инстанции? И, кстати, вот с этой точки зрения: "Разрядностью микропроцессорной системы принято считать количество бит информации, которое ее ЦП может обработать с помощью одной команды" Pentium был 64-разрядным. Иногда

Harsky> UPD: IBM PC началась немного раньше чем 286. OS/2 тоже опоздала.

А какое это имеет отношение к обсуждаемому вопросу? Вы всерьёз полагаете, что гипотетический "Линукс 80-х" мог бы работать на оригинальной IBM PC?