Ну так и наши Эльбрусы применялись в очень серьёзных задачах -- что не сделало их хорошими и перспективными машинами. Как и машины IBM далеко не всегда были шедеврами инженерной мысли (скорей, даже обычно не были -- недаром тот же Амдал, ушедший из IBM, делал машины той же архитектуры, но при этом более мощные и дешевле). В общем, архитектура -- одно, реализация -- другое, применение -- третье.
И те, и другие благополучно провалились, ибо были концептуально порочными (стековая архитектура, типизация данных на уровне процессора, организация памяти а-ля сегменты 80286 и т.д.). Правда, в 1960-х это было отнюдь не очевидно, но, как ни крути, а все эти машины полностью сошли со сцены, а потомки Системы 360, которую Дейкстра поливал грязью, живы и трудятся по сей день.
Размер АЛУ почти всегда соответствует разрядности процессора
На самом деле, это весьма часто не так; более того, исполнительных блоков разной разрядности может быть несколько -- причём без всякой ещё суперскалярности и даже конвейерности. Скажем, у IBM 360/30 АЛУ 8-битное, у 360/50 -- 32-битный двоичный сумматор и отдельный 8-разрядный блок для логических операций и десятичного сложения-вычитания, а у старших моделей обычно 64-разрядный основной сумматор, отдельный 8-разрядный сумматор и отдельный блок логических и десятичных операций -- хотя архитектурно это всё 32-разрядные машины. Та же история и у отечественных ЕС ЭВМ, которые черпали идеи у заокеанских образцов (иногда перерабатывая в лучшую сторону, а иногда ощутимо ухудшая).
Можно посмотреть на схему классического АЛУ SN74181 и схемы ускоренного переноса для него SN74179, появившихся на рубеже 60-70-х годов: те же самые сигналы генерации и распространения переноса. Вариации этого способа ускорения переноса встречались далеко не только в супер-ЭВМ; по большому счёту, почти каждая ЭВМ 60-х годов этим в этой или иной степени пользовалась, ибо иначе сложение будет выполняться уж очень медленно.
Реализация сдвига влево как сложения операнда с самим собой и входным переносом, упомянутая в примечании, -- тоже идея не новая. В частности, сама Интел использовала её для своего 2-битного секционированного АЛУ i3002, а это, если память не изменяет, 1973-й год.
Советский код который я видел до этого (и большинство после этого) был написан тяп-ляп.
Западный тоже очень разный был. Если посмотреть исходники OS/360, то это такой ужас... Собственно, Брукс-мл. в своём "Мифическом человекомесяце" пишет про невысокий средний уровень квалификации тех программистов, что её создавали -- но это, как и положено "у них", весьма политкорректная характеристика, реально же программисты, создававшие критические куски системы -- в частности, первичные обработчики прерываний, -- просто ужасающе плохи и как кодировщики, и как архитекторы. Вообще удивительно, что сия система не просто работала, а достаточно стабильно работала для всяких там банковских и т.п. применений. (А вот RSX-11M, написанная чуть ли не в одно рыло Дэвидом Катлером, демонстрирует куда более высокое качество и проектирования, и собственно кодирования).
P5 -- не архитектура, а микроархитектура. Ну а архитектура у Пентиумов та же самая, что и у 80386, 486, Пентиумов-2-3-4 и Коре, и официально она называется IA-32.
Причём микрокод, конвейер и суперскалярность друг другу не противоречат.
Сам злостный ностальгатор и фанат PDP-11, исключительно красивая штука
Как по мне, самая лучшая по совокупности факторов система команд маленькой 16-разрядной машины.
А вот 32-разрядный VAX-11 с той же идеологией я считаю неудачным решением. DEC его позиционировала как "супер-мини", но в результате получилось и не супер, и не мини: слишком дорогой и сложный по сравнению с PDP-11, но при этом имеющий низкую производительность без каких-либо шансов на её кардинальное увеличение. Основная причина -- сложное кодирование команд с длиной кода команды от 1 до 36 байт. Вот попробуй сделать даже не суперскалярный, а просто конвейерный процессор с такой кодировкой :)
В общем, "механический" перенос удачной для своей ниши идеи в другую нишу далеко не всегда гарантирует хороший результат: надо все условия учитывать.
Но вот группа MIPS/Хеннесси в Стенфорде в 1978-1980 показала, что большинство сложных инструкций редко используются,
Ага, и именно поэтому у современных RISC-процессоров бывают сотни, а то и тысячи команд -- вне всякого сомнения, все они очень широко используются :)
а если конвейеризовать простые, то можно достигнуть более высоких бенчмарк при сравнимом по сложности процессоре
А нет ли реальных исследований, который показывают, насколько быстро выполняется какое-нибудь шифрование AES и т.п. на "обычном" RISC-процессоре с помощью обычных команд и на, скажем, процессоре современного мэйнфрейма IBM, где такое шифрование -- это одна команда? (ну хорошо, две команды: шифрование идёт порциями, и после каждой процессор приостанавливает команду шифрования, давая возможность программе проанализировать, не следует ли ей отвлечься на что-то другое, поэтому для шифрования всех данных после команды шифрования нужен ещё условный переход на команду шифрования).
сишная конструкция p++ = q++ делается одной инструкцией процессора
А в ARMах она делается двумя командами процессора, например:
LDR R0,[R1],#4
STR R0,[R2],#4
В плане автоинкремента-автодекремента он даже гибче, чем PDP-11 (вот косвенного автоинкремента/автодекремента нет -- но они почти никогда и не нужны были, особенно косвенный автодекремент, который в VAX-11 выкинули вообще).
Когда копировал, а когда и очень существенно переделывал. Скажем, КР1810ВМ86М поддерживает не только все команды 8086, но ещё и команды 80186/286 вроде PUSHA/POPA, а также совместно с внешней микросхемой обладает способностью адресовать больше мегабайта памяти (своего рода недо-MMU).
В реальной реальности прошлого, учитывая очень небольшой объём доступной оперативной памяти (нередко порядка 30 Кбайт на всё про всё, а то и меньше), таблицы символов и т.д. и т.п. хранили во внешней памяти -- на дисках и/или лентах. Работало всё, конечно, очень медленно -- но работало.
Редко, но бывает, что нельзя сразу написать освобождающий код. В таком случае лично я сразу же пишу TODO в точке выделения про то, что надо слепить освобождение -- ну и время от времени проверяю, какие TODO у меня имеются. Помогает от склероза :)
Вообще, можно создать компилятор без динамического выделения памяти; так писали, например, компиляторы Фортрана на самом Фортране в 1960-70-е (у тогдашнего Фортрана динамической памяти нет в принципе, насчёт современных версий ничего не скажу). Но это, скажем так, весьма геморройно :)
В общем, как я и подумал, информация таки сохранялась, как и положено магнитному носителю -- просто сам носитель был, оказывается, один и использовался всеми кому не лень и для всего подряд. Т.е. невозможность долговременного хранения данных на нём -- не техническая, а, так сказать, организационная.
Кстати говоря, а М-20, М-220, БЭСМ-3 и БЭСМ-4 в плане программирования -- совсем-совсем разные машины? Или некая степень совместимости на уровне машинных команд и т.п. имеется? (Система 360 -- первый случай официального анонса будущей программной совместимости, но де-факто разные, но совместимые машины к тому времени уже иногда встречались, вот и интересно, не являются ли таковыми и указанные советские).
Хм... А с какой радости информация на магнитном барабане не сохранялась-то? Он же магнитный, как и диск с лентой, и предназначен же как раз для хранения информации... (ну, были извраты вроде использования барабана в качестве ОЗУ на "уралах", но и там информация никуда без питания не терялась -- просто это были не файлы, выражаясь современным языком, а содержимое ОЗУ машины).
Насчёт мировой новизны сказать ничего не могу: не знаю, как у них было на тот момент, но частота АЦП и сейчас выглядит весьма немаленькой, а уж в начале 1980-х... Похоже, Ваша диссертация была таки реально научной работой, а не как нередко бывает, увы.
Ну, когда Спектрумы стали массово появляться, тогда купить уже можно было, это да -- но это конец 80-х. Что в аспирантуре доступ был -- оно понятно. Хотя, честно говоря, про мировую новизну не очень-то верю (в отличие от новизны в глазах самого аспиранта) -- но мало ли, вдруг действительно что-то такое конкретно у Вас и было.
А откуда тогда браться интересующимся такой техникой? Очень многое ж в школьном или даже дошкольном возрасте формируется. Я, например, увлёкся электроникой в 6 лет (мама "радиокубики" купила), потом всякие разные радиоприёмники (этого хватало), быстро по книгам разобрался с релейной автоматикой (в ~10 лет удивил пришедших ремонтировать лифт мужиков, сообщив им, какая релюшка не работает -- у меня была пара книг по лифтам со схемами, в т.ч. той модели, что стояла в нашем доме, так что я на слух всю его работу знал, мы жили на последнем этаже и из прихожей все шелчки были отлично слышны). Компьютер увидел в 13 лет в школе (Агат), ну а первые цифровые микросхемы для меня украли на ВЦ одного вуза из ЗИПа тамошних ЭВМ, когда мне было 14 и я учился работать на СМ-4 (удалось договориться матери, она преподавателем в вузе была, хотя в совершенно другой области) -- до этого был знаком с этой темой исключительно по книгам. Позднее я и сам воровал их из ЗИПа по месту работы. Ну а покупать возможность появилась лишь перед распадом СССР, да и то не везде (в Москву приезжал -- покупал на тогда ещё Тушинском радиорынке). Вот и читай в таких условиях переводы американских книг типа Хоровица с Хиллом про то, что в вашу Мухосрановку-на-Аляске заказать тоже можно, но доставят за 3 недели, а не за 3 дня, как в Нью-Йорк :)
В общем, достаточно погано было в СССР с условиями для подобного творчества, к сожалению...
Небольшая поправка: доступны они были тем, кто с ними работал по долгу службы. Простому советскому гражданину купить их в простом магазине было невозможно от слова "вообще" -- там были лампы, кой-какие транзисторы, аналоговые микросхемы из числа используемых в бытовой технике -- но не "цифра".
Замечу, что на микроконтроллерах -- в частности, на упомянутом ядре Cortex-M4 -- обычно нет проблем с промахами мимо кэша за отсутствием самого кэша. Он имеется у наиболее мощных микроконтроллеров (например, обычно присутствует у Cortex-M7), но у более слабых его наличие -- редкость.
Ну а само наличие (или отсутствие) кэшей и их влияние на производительность учитывать точно стоит. В частности, именно из-за них неверно игнорировать размеры программ и данных по принципу "у современных ПК 100500 Гбайт ОЗУ, так что будем отводить под каждый bool не 1 бит, а 4 байта".
Ну так и наши Эльбрусы применялись в очень серьёзных задачах -- что не сделало их хорошими и перспективными машинами. Как и машины IBM далеко не всегда были шедеврами инженерной мысли (скорей, даже обычно не были -- недаром тот же Амдал, ушедший из IBM, делал машины той же архитектуры, но при этом более мощные и дешевле). В общем, архитектура -- одно, реализация -- другое, применение -- третье.
И те, и другие благополучно провалились, ибо были концептуально порочными (стековая архитектура, типизация данных на уровне процессора, организация памяти а-ля сегменты 80286 и т.д.). Правда, в 1960-х это было отнюдь не очевидно, но, как ни крути, а все эти машины полностью сошли со сцены, а потомки Системы 360, которую Дейкстра поливал грязью, живы и трудятся по сей день.
На самом деле, это весьма часто не так; более того, исполнительных блоков разной разрядности может быть несколько -- причём без всякой ещё суперскалярности и даже конвейерности. Скажем, у IBM 360/30 АЛУ 8-битное, у 360/50 -- 32-битный двоичный сумматор и отдельный 8-разрядный блок для логических операций и десятичного сложения-вычитания, а у старших моделей обычно 64-разрядный основной сумматор, отдельный 8-разрядный сумматор и отдельный блок логических и десятичных операций -- хотя архитектурно это всё 32-разрядные машины. Та же история и у отечественных ЕС ЭВМ, которые черпали идеи у заокеанских образцов (иногда перерабатывая в лучшую сторону, а иногда ощутимо ухудшая).
Можно посмотреть на схему классического АЛУ SN74181 и схемы ускоренного переноса для него SN74179, появившихся на рубеже 60-70-х годов: те же самые сигналы генерации и распространения переноса. Вариации этого способа ускорения переноса встречались далеко не только в супер-ЭВМ; по большому счёту, почти каждая ЭВМ 60-х годов этим в этой или иной степени пользовалась, ибо иначе сложение будет выполняться уж очень медленно.
Реализация сдвига влево как сложения операнда с самим собой и входным переносом, упомянутая в примечании, -- тоже идея не новая. В частности, сама Интел использовала её для своего 2-битного секционированного АЛУ i3002, а это, если память не изменяет, 1973-й год.
Западный тоже очень разный был. Если посмотреть исходники OS/360, то это такой ужас... Собственно, Брукс-мл. в своём "Мифическом человекомесяце" пишет про невысокий средний уровень квалификации тех программистов, что её создавали -- но это, как и положено "у них", весьма политкорректная характеристика, реально же программисты, создававшие критические куски системы -- в частности, первичные обработчики прерываний, -- просто ужасающе плохи и как кодировщики, и как архитекторы. Вообще удивительно, что сия система не просто работала, а достаточно стабильно работала для всяких там банковских и т.п. применений. (А вот RSX-11M, написанная чуть ли не в одно рыло Дэвидом Катлером, демонстрирует куда более высокое качество и проектирования, и собственно кодирования).
P5 -- не архитектура, а микроархитектура. Ну а архитектура у Пентиумов та же самая, что и у 80386, 486, Пентиумов-2-3-4 и Коре, и официально она называется IA-32.
Причём микрокод, конвейер и суперскалярность друг другу не противоречат.
Как по мне, самая лучшая по совокупности факторов система команд маленькой 16-разрядной машины.
А вот 32-разрядный VAX-11 с той же идеологией я считаю неудачным решением. DEC его позиционировала как "супер-мини", но в результате получилось и не супер, и не мини: слишком дорогой и сложный по сравнению с PDP-11, но при этом имеющий низкую производительность без каких-либо шансов на её кардинальное увеличение. Основная причина -- сложное кодирование команд с длиной кода команды от 1 до 36 байт. Вот попробуй сделать даже не суперскалярный, а просто конвейерный процессор с такой кодировкой :)
В общем, "механический" перенос удачной для своей ниши идеи в другую нишу далеко не всегда гарантирует хороший результат: надо все условия учитывать.
Ага, и именно поэтому у современных RISC-процессоров бывают сотни, а то и тысячи команд -- вне всякого сомнения, все они очень широко используются :)
А нет ли реальных исследований, который показывают, насколько быстро выполняется какое-нибудь шифрование AES и т.п. на "обычном" RISC-процессоре с помощью обычных команд и на, скажем, процессоре современного мэйнфрейма IBM, где такое шифрование -- это одна команда? (ну хорошо, две команды: шифрование идёт порциями, и после каждой процессор приостанавливает команду шифрования, давая возможность программе проанализировать, не следует ли ей отвлечься на что-то другое, поэтому для шифрования всех данных после команды шифрования нужен ещё условный переход на команду шифрования).
А в ARMах она делается двумя командами процессора, например:
В плане автоинкремента-автодекремента он даже гибче, чем PDP-11 (вот косвенного автоинкремента/автодекремента нет -- но они почти никогда и не нужны были, особенно косвенный автодекремент, который в VAX-11 выкинули вообще).
Когда копировал, а когда и очень существенно переделывал. Скажем, КР1810ВМ86М поддерживает не только все команды 8086, но ещё и команды 80186/286 вроде PUSHA/POPA, а также совместно с внешней микросхемой обладает способностью адресовать больше мегабайта памяти (своего рода недо-MMU).
В реальной реальности прошлого, учитывая очень небольшой объём доступной оперативной памяти (нередко порядка 30 Кбайт на всё про всё, а то и меньше), таблицы символов и т.д. и т.п. хранили во внешней памяти -- на дисках и/или лентах. Работало всё, конечно, очень медленно -- но работало.
Редко, но бывает, что нельзя сразу написать освобождающий код. В таком случае лично я сразу же пишу TODO в точке выделения про то, что надо слепить освобождение -- ну и время от времени проверяю, какие TODO у меня имеются. Помогает от склероза :)
Вообще, можно создать компилятор без динамического выделения памяти; так писали, например, компиляторы Фортрана на самом Фортране в 1960-70-е (у тогдашнего Фортрана динамической памяти нет в принципе, насчёт современных версий ничего не скажу). Но это, скажем так, весьма геморройно :)
В общем, как я и подумал, информация таки сохранялась, как и положено магнитному носителю -- просто сам носитель был, оказывается, один и использовался всеми кому не лень и для всего подряд. Т.е. невозможность долговременного хранения данных на нём -- не техническая, а, так сказать, организационная.
Кстати говоря, а М-20, М-220, БЭСМ-3 и БЭСМ-4 в плане программирования -- совсем-совсем разные машины? Или некая степень совместимости на уровне машинных команд и т.п. имеется? (Система 360 -- первый случай официального анонса будущей программной совместимости, но де-факто разные, но совместимые машины к тому времени уже иногда встречались, вот и интересно, не являются ли таковыми и указанные советские).
Хм... А с какой радости информация на магнитном барабане не сохранялась-то? Он же магнитный, как и диск с лентой, и предназначен же как раз для хранения информации... (ну, были извраты вроде использования барабана в качестве ОЗУ на "уралах", но и там информация никуда без питания не терялась -- просто это были не файлы, выражаясь современным языком, а содержимое ОЗУ машины).
Насчёт мировой новизны сказать ничего не могу: не знаю, как у них было на тот момент, но частота АЦП и сейчас выглядит весьма немаленькой, а уж в начале 1980-х... Похоже, Ваша диссертация была таки реально научной работой, а не как нередко бывает, увы.
Ну, когда Спектрумы стали массово появляться, тогда купить уже можно было, это да -- но это конец 80-х. Что в аспирантуре доступ был -- оно понятно. Хотя, честно говоря, про мировую новизну не очень-то верю (в отличие от новизны в глазах самого аспиранта) -- но мало ли, вдруг действительно что-то такое конкретно у Вас и было.
А откуда тогда браться интересующимся такой техникой? Очень многое ж в школьном или даже дошкольном возрасте формируется. Я, например, увлёкся электроникой в 6 лет (мама "радиокубики" купила), потом всякие разные радиоприёмники (этого хватало), быстро по книгам разобрался с релейной автоматикой (в ~10 лет удивил пришедших ремонтировать лифт мужиков, сообщив им, какая релюшка не работает -- у меня была пара книг по лифтам со схемами, в т.ч. той модели, что стояла в нашем доме, так что я на слух всю его работу знал, мы жили на последнем этаже и из прихожей все шелчки были отлично слышны). Компьютер увидел в 13 лет в школе (Агат), ну а первые цифровые микросхемы для меня украли на ВЦ одного вуза из ЗИПа тамошних ЭВМ, когда мне было 14 и я учился работать на СМ-4 (удалось договориться матери, она преподавателем в вузе была, хотя в совершенно другой области) -- до этого был знаком с этой темой исключительно по книгам. Позднее я и сам воровал их из ЗИПа по месту работы. Ну а покупать возможность появилась лишь перед распадом СССР, да и то не везде (в Москву приезжал -- покупал на тогда ещё Тушинском радиорынке). Вот и читай в таких условиях переводы американских книг типа Хоровица с Хиллом про то, что в вашу Мухосрановку-на-Аляске заказать тоже можно, но доставят за 3 недели, а не за 3 дня, как в Нью-Йорк :)
В общем, достаточно погано было в СССР с условиями для подобного творчества, к сожалению...
Небольшая поправка: доступны они были тем, кто с ними работал по долгу службы. Простому советскому гражданину купить их в простом магазине было невозможно от слова "вообще" -- там были лампы, кой-какие транзисторы, аналоговые микросхемы из числа используемых в бытовой технике -- но не "цифра".
Ну так TI и сейчас продолжает производство изрядной части своей серии SN74 (которая у нас стала 155-й) -- а она родом тоже из 1960-х.
Замечу, что на микроконтроллерах -- в частности, на упомянутом ядре Cortex-M4 -- обычно нет проблем с промахами мимо кэша за отсутствием самого кэша. Он имеется у наиболее мощных микроконтроллеров (например, обычно присутствует у Cortex-M7), но у более слабых его наличие -- редкость.
Ну а само наличие (или отсутствие) кэшей и их влияние на производительность учитывать точно стоит. В частности, именно из-за них неверно игнорировать размеры программ и данных по принципу "у современных ПК 100500 Гбайт ОЗУ, так что будем отводить под каждый bool не 1 бит, а 4 байта".