Разница громадная. Декодер в S/360 способен сразу определить длину текущей команды, а соответственно, с минимальной задержкой определить адрес следующей, из неё -- её длину и адрес следующей и т.д. -- и всё это с очень малыми затратами "железа". А в IA-32 затраты на то же самое будут кошмарными (собственно, они такие и есть). Попробуйте нарисовать схему декодера для S/360 и даже для 8086 -- сразу разницу увидите.
Мешают префиксы, мешают. Простой и быстрый декодер сделать попросту невозможно: нужно сразу анализировать много байтов, полученных из памяти (из кэша), а это дорого в плане железа. Ну а для суперскалярных процессоров -- ещё сложней. В этом плане мэйнфреймы -- почти прямая противоположность: хоть длина команды и переменная, устанавливается она элементарным анализом двух старших битов старшего байта, а соответственно, выбрав из памяти, скажем, 16 байт, можно "лёгким движением руки" разобрать их на команды.
Совершенно согласен. Можно вспомнить обратный Интелу и ИБМ пример. Когда в ДЕК лепили VAX, "идеологически" они сделали его систему команд расширенной версией PDPшной, но кодировку полностью делали с нуля, поэтому оригинальные PDPшные программы VAX мог исполнять только в специальном режиме совместимости или как там его. Соответственно, не пришлось уродовать кодировку ради этой самой двоичной совместимости, которая реально нафиг никому была не нужна. То же самое можно было бы сделать в 80386: вот вам 16-разрядные режимы (реальный, защищённый 16-разрядный и V86) для старого софта, а вот полностью новый, с новым кодированием команд -- для 32-разрядного. Ну а 64-разрядный от AMD в этом смысле выглядит, пожалуй, даже хуже: полной совместимости они не сохранили (в частности, выпилили поддержку V86 и некоторые команды), а система кодирования стала ещё уродливей.
z/Architecture в этом плане нечто среднее. Кодировка осталась простой, не смотря на все эти расширения, но вот её эффективность, естественно, стала значительно хуже. Как по мне, стоило бы делать полностью новую кодировку, сохранив лишь "идеологию" системы команд, ну а совместимость обеспечивать за счёт режима совместимости (использовать, скажем, биты управления разрядностью адреса в PSW: если 24- или 31-разрядный режим -- работать с кодировкой, как в ESA/390 и более ранних, если 64-разрядный -- в полностью новой кодировке).
Да, в первом издании Principles of Operation указано, что промежуточные результаты для одинарной точности 7 цифр (6 плюс защитная), а для двойной всегда 14 цифр без защитной цифры, а в издании 1968 г. защитная цифра применяется в обоих форматах.
Мне вот показалось, что в ЕС-1030 двойная точность -- без защитной цифры. Впрочем, в имеющейся литературе хватает неточностей, а временам и ошибок, а доки на проц нету, так что утверждать что-либо трудно. Вот с ЕС-1020 надеюсь когда-нибудь разобраться полностью: на неё нашлась в РГБ почти вся документация, включая все микропрограммы и все техописания, так что можно восстановить логику выполнения всех операций и понять эти вещи.
Про AL(R), SL(R) ничего не сказано, но они делаются тоже побайтно? А почему так для них всех?
Про AL(R) и SL(R) ни слова не сказано. Но аналогия CL(R) здесь не прокатит, поскольку последняя -- сравнение, а узел обработки байтов имеет схемы сравнения, выдающий сигналы = и > для сравниваемой пары байтов, однако вычитание он не делает. Так что AL(R) и SL(R) должны бы делаться на основном сумматоре. Но почему сравнение не на нём -- загадка-с. Скорей всего, из-за общей... альтернативной одарённости разработчиков: там весь процессор "альтернативный", глупость на глупости в железе (в отличие от ЕС-1020, где, в общем и целом, всё сделано разумно).
Вообще, что чуть менее чем всё выполнялось на микрокомандах, с современной точки зрения слегка так неожиданно. (Ну да, причины понятны, но надо привыкнуть...)
Опять-таки, во многом -- глупость разработчиков. В ЕС-1020, скажем, два наиболее частых случая установки кода условия реализованы аппаратно (в ЕС-1022 -- уже три), за работой блока обращения к памяти проц там тоже не следит: выдал приказ чтения/записи -- и всё, остальное железо сделает, ну и т.д. и т.п.
В общем, микропрограммное управление вовсе не требует каждый чих делать микропрограммно, задача конструктора как раз найти разумный баланс. В Ереване с этим явно не справились (и, кстати говоря, на 1045 тоже: она жутко переусложнена, там половину по-другому делать надо было бы; просто, в отличие от 1030, она была таки быстрой машиной, а пользователю-то всё равно, что у неё "под капотом").
Да, АКК -- это просто железка для соединения двух стандартных интерфейсов ввода-вывода. Соответственно, в отличие от модемов, удалённую связь не сделать, максимум -- метров 150 между машинами (суммарная длина двух кабелей). С другой стороны, скорость потенциально намного выше, так как ограничена скоростью самого АКК и каналов.
Логика управления, понятное дело, реализуется в ОС, а конкретного описания, что и как, у меня нет, есть только скудное описание технической базы, которое я, собственно, и привёл.
Кстати, интересно, является ли REXX самым старым из до сих пор живых скриптовых языков? (Так-то понятно, что Фортран живее всех живых -- но он не скриптовый).
Первая половина 1970-х, эта статья -- дополнение к моей серии статей про устройство процессора ЕС-1030. Но упоминание времени выпуска добавил, спасибо за замечание :)
Если достаточно полноценный эмулятор -- можно. В частности, полноценный MMU нужен (а RT-11 он не нужен, поэтому её запуск в данном случае не показателен).
На рассыпухе свои приколы бывают, которые в ПЛИС воспроизвести иногда затруднительно (во всяком случае, без "уговоров" средств синтеза делать то, что ты требуешь, а не то, что они считают правильным :) ).
Но вот, скажем, проц от СМ-1420 в лоб не перенесёшь: тайминги шины и т.п. вещи там сделаны на одновибраторах, т.е., по сути, на аналоговых схемах. Естественно, при реализации такого в ПЛИС придётся конкретно эти вещи переделать.
Ещё можно вспомнить про активное использование линий с открытым коллектором и с тремя состояниями на рассыпухе, что на ПЛИС в лоб сделать, опять-таки, не получится. Скажем, ту же двунаправленную шину данных любого микропроцессора внутри ПЛИС не сделаешь, придётся делать отдельно шину приёма, отдельно шину передачи -- и так для всех устройств, которые в исходном компьютере висели на одной двунаправленной шине.
Ну, копирование или создание аналогов буржуйской элементной базы заставило свою электронную промышленность поднять на качественно новый уровень, а вместе с ней и кучу смежных вещей. В частности, я встречал информацию, что ранние советские микросхемы были очень ненадёжны не из-за собственно микросхем (кристаллов кремния), а из-за неспособности обеспечить должную герметичность корпусов, проистекавшую из проблем с пластиком и т.п. вещами. Когда с этим, наконец, справились, надёжность сильно выросла. Но пластики сами по себе -- химическая промышленность, а не электронная. В общем, всё взаимосвязано.
Если про жизненный цикл, то можно вспомнить, например, что последние БЭСМ-6 и ЕС ЭВМ выводились из эксплуатации в конце 20-начале 21 века, т. е. спустя 10-20 лет после прекращения их выпуска, ну а нормальный срок службы подобных машин что у нас, что у них был по 10-15, а то и 20 лет. У вояк в качестве управляющих до сих пор используются разработки 1970-х, а то и 1960-х: там же не нужны котики в тырнетах, там надо, чтоб работало, и погоня за новейшим далеко не всегда оправдана (хотя, безусловно, есть вещи, где без новейших вещей никак -- просто далеко не все такие).
Ну и не забывайте, что, хотя жизненный цикл конкретного изделия может быть весьма коротким, такие вещи, как архитектура и технологии, намного более живучи. Та же Система 360 -- нагляднейший пример, ведь z/Architecture на прикладном уровне сохраняет с ней совместимость, и мэйнфрейм 2024 года выпуска способен выполнять программы, написанные в 1965-м. (Собственно, и выполняют, ибо в бизнесе полно задач, которые были решены на этих машинах тогда и продолжают решаться сейчас: зачем, скажем, переписывать с нуля какой-нибудь там банковский процессинг? Ради того, чтоб уйти с Кобола на уже не очень-то модную Жабу? Банкам же, как и воякам, надо, чтоб работало -- а переписывание без реальной нужды, скорей, что-нибудь сломает, а не улучшит.)
В общем, заимствование западных наработок толчок нам действительно дало и позволило сэкономить немало времени и сил. Проблема была в том, что вместо углубления, расширения и т.д. и т.п. своими силами (поглядывая на чужой опыт и сохраняя совместимость на уровне архитектур, где они были заимствованы, но разрабатывая самостоятельно) стали копировать всё больше и больше, причём уже не только архитектуры и зачастую уже без всякого смысла. Например, выпустили полностью свои микропроцессоры с системой команд PDP-11 (серия 1801, позже 1806 -- выпускается до сих пор, кстати), но зачем-то скопировали ещё и DECовский микропроцессор -- причём он был хуже наших...
Частично Вы отметили разницу между машинами для научно-технических расчётов и экономических, отмечу и я, только несколько полнее.
Научные расчёты, если говорить совсем уж утрировано, сводятся к тому, что в машину вводится три числа, потом машина полдня что-то с ними делает по формулам, которые простым смертным понять не дано, и в конце печатает результат -- другие три числа.
Экономические расчёты -- нечто противоположное. В машину вводится огромное количество данных (например, количество отработанных в месяце часов каждым работником предприятия, всякие надбавки, коэффициенты и прочая), затем машина выполняет очень простой расчёт (зарплату, в большинстве случаев, рассчитывать можно научить даже второклассника), а в конце печатает результат -- длиннющие "простыни" всяких табелей и ведомостей.
Как следствие, для "научной" машины важнейшим критерием является производительность на операциях над вещественными числами (числами с плавающей запятой). Для "экономической" машины эти операции не нужны вообще, зато очень полезны десятичные операции (ибо правила округления и т.п. вещи в экономике жёстко регламентированы и, естественно, под десятичную систему) и быстрый ввод-вывод, поскольку машине приходится не столько считать, сколько вводить и выводить данные.
Очевидно, что разный род задач требует для своего эффективного решения разного набора команд у процессора. Скажем, наша БЭСМ-6 (1967 год) -- самая мощная из советских "числодробилок" -- на научных расчётах была раза в два быстрей, чем самая мощная из ранних ЕС ЭВМ -- ЕС-1050 (надеюсь, руки дойдут и про неё написать), да и с американскими успешно могла соревноваться, если не считать суперкомпьютеров CDC, которые были в пике раз в 10 быстрей. Но на экономических расчётах её даже не пытались сравнивать с ЕС ЭВМ: система команд БЭСМ-6 исключительно неэффективна для любых задач, кроме научных (у неё даже операций над целыми числами как таковых нет, насколько помню), да и с последними тоже не всё так радужно.
IBM же делала Систему 360 как универсальную, 360 в её обозначении -- это рекламные "360 градусов", пригодность для любых задач (что не соответствовало действительности даже тогда, но было куда ближе к ней, чем у подавляющего большинства, если не у всех вообще, других компьютерных архитектур того времени).
Следствием разного характера задач в случае "экономики" является постоянная недогруженность процессора: он, по большей части, стоит и ждёт, пока будет введена очередная порция исходных данных или выведен результат предыдущих расчётов (что тогда, что сейчас процессор намного более быстр, чем периферия). Учитывая огромную стоимость "железа" в те годы, желательно процессор как-то суметь загрузить -- а значит, нужно параллельно выполнять несколько задач и, когда одна останавливается в ожидании завершения ввода-вывода, передавать управление другой, готовой к работе задаче.
Но, чтобы иметь возможность выполнять несколько задач, они должны быть загружены в память -- а значит, подавай большой объём памяти. У той же БЭСМ-6 адрес был 15-разрядным, а соответственно, предельный объём памяти -- 32 Кслова (слово там 48 бит, поэтому условно будем считать, что память у неё -- 96 Кбайт, хотя байтовой организации там не было, что тоже сильно мешало решению любых задач, кроме научных). Ну а у Системы 360 -- 24 бита, что позволяло иметь объём памяти до 16 Мбайт (абсолютно немыслимая величина в те годы, такой объём мощные машины "у них" получили лишь во второй половине 1970-х, когда у нас уже была грустная шутка про "мегабайт -- американское название килобайта").
Для того, чтобы управлять несколькими параллельно работающими задачами, нужна достаточно развитая операционная система, а также некоторые вспомогательные "железные" механизмы -- как минимум, защита памяти и таймер. У Системы 360 это было, у большинства других архитектур -- нет. Плюс, нужна лишняя память под нужды самой системы.
Следствием разного объёма данных является разный набор внешних устройств -- и по скорости, и по объёму. Вполне возможно, что именно это стало одной из причин нашего отставания в этой области (куда большего отставания, замечу, чем в области собственно процессоров): мы просто толком не занимались, скажем, магнитной записью (абы как сделали -- и ладно), поэтому не было ни дисководов (только магнитные барабаны малой ёмкости -- они намного проще по конструкции), ни хороших материалов для магнитных лент (из-за чего "у них" давно писали уже с плотностью 246 бит/мм, а у нас -- только 32, поскольку даже для 63 бит/мм наши магнитные ленты, по большей части, не годились).
Что касается ОС, её ещё надо написать -- а это огромный объём работы, ну а в одной IBM было больше программистов, чем во всём СССР. "Научные" задачи у нас нередко гоняли вообще без всякой ОС: просто вводили в память машины и запускали. Эффективное же решение "экономических" задач с подобным подходом невозможно.
Я бы сравнил решение о копировании архитектуры с копированием B-29 по приказу Сталина. По легенде, Туполев сказал: зачем копировать, мы сделаем лучше! Ну а Сталин ему ответил: "не надо лучше, сделайте такой же". Сделали, назвали Ту-4. Понятно, что самолёт изначально был устаревший (раз в 1944 он уже летал и бомбил японцев, значит, на момент начала копирования он уже был "старым", пускай и новейшим в строевых частях -- американские конструкторы уже разрабатывали следующие самолёты). Но его копирование потребовало создать нормальную авиационную промышленность и смежные производства вместо той полукустарщины, что была у нас: серийно выпускать столь сложный самолёт "на коленке" просто невозможно, поэтому пришлось подтягивать технологии и производство, повышать его культуру и т.д. и т.п. (а не подстраивать проект самолёта под имеющиеся возможности, как было бы в случае "сделаем лучше": единичный экземпляр точно сделали б лучше, а вот запустить серию...).
Разница громадная. Декодер в S/360 способен сразу определить длину текущей команды, а соответственно, с минимальной задержкой определить адрес следующей, из неё -- её длину и адрес следующей и т.д. -- и всё это с очень малыми затратами "железа". А в IA-32 затраты на то же самое будут кошмарными (собственно, они такие и есть). Попробуйте нарисовать схему декодера для S/360 и даже для 8086 -- сразу разницу увидите.
Эм.... А с ней что не так?
Мешают префиксы, мешают. Простой и быстрый декодер сделать попросту невозможно: нужно сразу анализировать много байтов, полученных из памяти (из кэша), а это дорого в плане железа. Ну а для суперскалярных процессоров -- ещё сложней. В этом плане мэйнфреймы -- почти прямая противоположность: хоть длина команды и переменная, устанавливается она элементарным анализом двух старших битов старшего байта, а соответственно, выбрав из памяти, скажем, 16 байт, можно "лёгким движением руки" разобрать их на команды.
Совершенно согласен. Можно вспомнить обратный Интелу и ИБМ пример. Когда в ДЕК лепили VAX, "идеологически" они сделали его систему команд расширенной версией PDPшной, но кодировку полностью делали с нуля, поэтому оригинальные PDPшные программы VAX мог исполнять только в специальном режиме совместимости или как там его. Соответственно, не пришлось уродовать кодировку ради этой самой двоичной совместимости, которая реально нафиг никому была не нужна. То же самое можно было бы сделать в 80386: вот вам 16-разрядные режимы (реальный, защищённый 16-разрядный и V86) для старого софта, а вот полностью новый, с новым кодированием команд -- для 32-разрядного. Ну а 64-разрядный от AMD в этом смысле выглядит, пожалуй, даже хуже: полной совместимости они не сохранили (в частности, выпилили поддержку V86 и некоторые команды), а система кодирования стала ещё уродливей.
z/Architecture в этом плане нечто среднее. Кодировка осталась простой, не смотря на все эти расширения, но вот её эффективность, естественно, стала значительно хуже. Как по мне, стоило бы делать полностью новую кодировку, сохранив лишь "идеологию" системы команд, ну а совместимость обеспечивать за счёт режима совместимости (использовать, скажем, биты управления разрядностью адреса в PSW: если 24- или 31-разрядный режим -- работать с кодировкой, как в ESA/390 и более ранних, если 64-разрядный -- в полностью новой кодировке).
Мне вот показалось, что в ЕС-1030 двойная точность -- без защитной цифры. Впрочем, в имеющейся литературе хватает неточностей, а временам и ошибок, а доки на проц нету, так что утверждать что-либо трудно. Вот с ЕС-1020 надеюсь когда-нибудь разобраться полностью: на неё нашлась в РГБ почти вся документация, включая все микропрограммы и все техописания, так что можно восстановить логику выполнения всех операций и понять эти вещи.
Про AL(R) и SL(R) ни слова не сказано. Но аналогия CL(R) здесь не прокатит, поскольку последняя -- сравнение, а узел обработки байтов имеет схемы сравнения, выдающий сигналы = и > для сравниваемой пары байтов, однако вычитание он не делает. Так что AL(R) и SL(R) должны бы делаться на основном сумматоре. Но почему сравнение не на нём -- загадка-с. Скорей всего, из-за общей... альтернативной одарённости разработчиков: там весь процессор "альтернативный", глупость на глупости в железе (в отличие от ЕС-1020, где, в общем и целом, всё сделано разумно).
Опять-таки, во многом -- глупость разработчиков. В ЕС-1020, скажем, два наиболее частых случая установки кода условия реализованы аппаратно (в ЕС-1022 -- уже три), за работой блока обращения к памяти проц там тоже не следит: выдал приказ чтения/записи -- и всё, остальное железо сделает, ну и т.д. и т.п.
В общем, микропрограммное управление вовсе не требует каждый чих делать микропрограммно, задача конструктора как раз найти разумный баланс. В Ереване с этим явно не справились (и, кстати говоря, на 1045 тоже: она жутко переусложнена, там половину по-другому делать надо было бы; просто, в отличие от 1030, она была таки быстрой машиной, а пользователю-то всё равно, что у неё "под капотом").
Да, АКК -- это просто железка для соединения двух стандартных интерфейсов ввода-вывода. Соответственно, в отличие от модемов, удалённую связь не сделать, максимум -- метров 150 между машинами (суммарная длина двух кабелей). С другой стороны, скорость потенциально намного выше, так как ограничена скоростью самого АКК и каналов.
ЕСовские, насколько помню, являются точными аналогами IBMовских -- как и большая часть остальной периферии.
Логика управления, понятное дело, реализуется в ОС, а конкретного описания, что и как, у меня нет, есть только скудное описание технической базы, которое я, собственно, и привёл.
Кстати, интересно, является ли REXX самым старым из до сих пор живых скриптовых языков? (Так-то понятно, что Фортран живее всех живых -- но он не скриптовый).
Первая половина 1970-х, эта статья -- дополнение к моей серии статей про устройство процессора ЕС-1030. Но упоминание времени выпуска добавил, спасибо за замечание :)
Если достаточно полноценный эмулятор -- можно. В частности, полноценный MMU нужен (а RT-11 он не нужен, поэтому её запуск в данном случае не показателен).
Так они существуют. Есть программные, есть на ПЛИС...
Да, в извращениях толк знают не только месье... :)
В общем, подозреваю, на ПЛИС было бы проще разработать его с нуля -- также при сохранении потактовой совместимости и всё такое.
На рассыпухе свои приколы бывают, которые в ПЛИС воспроизвести иногда затруднительно (во всяком случае, без "уговоров" средств синтеза делать то, что ты требуешь, а не то, что они считают правильным :) ).
Но вот, скажем, проц от СМ-1420 в лоб не перенесёшь: тайминги шины и т.п. вещи там сделаны на одновибраторах, т.е., по сути, на аналоговых схемах. Естественно, при реализации такого в ПЛИС придётся конкретно эти вещи переделать.
Ещё можно вспомнить про активное использование линий с открытым коллектором и с тремя состояниями на рассыпухе, что на ПЛИС в лоб сделать, опять-таки, не получится. Скажем, ту же двунаправленную шину данных любого микропроцессора внутри ПЛИС не сделаешь, придётся делать отдельно шину приёма, отдельно шину передачи -- и так для всех устройств, которые в исходном компьютере висели на одной двунаправленной шине.
Ну, иногда интерес как раз в том, чтоб на рассыпухе сделать. Хотя трудоёмкость та ещё, конечно, при этом :)
Инициатива наказуема исполнением :)
Ну, копирование или создание аналогов буржуйской элементной базы заставило свою электронную промышленность поднять на качественно новый уровень, а вместе с ней и кучу смежных вещей. В частности, я встречал информацию, что ранние советские микросхемы были очень ненадёжны не из-за собственно микросхем (кристаллов кремния), а из-за неспособности обеспечить должную герметичность корпусов, проистекавшую из проблем с пластиком и т.п. вещами. Когда с этим, наконец, справились, надёжность сильно выросла. Но пластики сами по себе -- химическая промышленность, а не электронная. В общем, всё взаимосвязано.
Если про жизненный цикл, то можно вспомнить, например, что последние БЭСМ-6 и ЕС ЭВМ выводились из эксплуатации в конце 20-начале 21 века, т. е. спустя 10-20 лет после прекращения их выпуска, ну а нормальный срок службы подобных машин что у нас, что у них был по 10-15, а то и 20 лет. У вояк в качестве управляющих до сих пор используются разработки 1970-х, а то и 1960-х: там же не нужны котики в тырнетах, там надо, чтоб работало, и погоня за новейшим далеко не всегда оправдана (хотя, безусловно, есть вещи, где без новейших вещей никак -- просто далеко не все такие).
Ну и не забывайте, что, хотя жизненный цикл конкретного изделия может быть весьма коротким, такие вещи, как архитектура и технологии, намного более живучи. Та же Система 360 -- нагляднейший пример, ведь z/Architecture на прикладном уровне сохраняет с ней совместимость, и мэйнфрейм 2024 года выпуска способен выполнять программы, написанные в 1965-м. (Собственно, и выполняют, ибо в бизнесе полно задач, которые были решены на этих машинах тогда и продолжают решаться сейчас: зачем, скажем, переписывать с нуля какой-нибудь там банковский процессинг? Ради того, чтоб уйти с Кобола на уже не очень-то модную Жабу? Банкам же, как и воякам, надо, чтоб работало -- а переписывание без реальной нужды, скорей, что-нибудь сломает, а не улучшит.)
В общем, заимствование западных наработок толчок нам действительно дало и позволило сэкономить немало времени и сил. Проблема была в том, что вместо углубления, расширения и т.д. и т.п. своими силами (поглядывая на чужой опыт и сохраняя совместимость на уровне архитектур, где они были заимствованы, но разрабатывая самостоятельно) стали копировать всё больше и больше, причём уже не только архитектуры и зачастую уже без всякого смысла. Например, выпустили полностью свои микропроцессоры с системой команд PDP-11 (серия 1801, позже 1806 -- выпускается до сих пор, кстати), но зачем-то скопировали ещё и DECовский микропроцессор -- причём он был хуже наших...
Ну, это краткое введение в тему, а не подробное объяснение, которое потянуло бы на полноценную статью. Но общее представление, надеюсь, даёт :)
Частично Вы отметили разницу между машинами для научно-технических расчётов и экономических, отмечу и я, только несколько полнее.
Научные расчёты, если говорить совсем уж утрировано, сводятся к тому, что в машину вводится три числа, потом машина полдня что-то с ними делает по формулам, которые простым смертным понять не дано, и в конце печатает результат -- другие три числа.
Экономические расчёты -- нечто противоположное. В машину вводится огромное количество данных (например, количество отработанных в месяце часов каждым работником предприятия, всякие надбавки, коэффициенты и прочая), затем машина выполняет очень простой расчёт (зарплату, в большинстве случаев, рассчитывать можно научить даже второклассника), а в конце печатает результат -- длиннющие "простыни" всяких табелей и ведомостей.
Как следствие, для "научной" машины важнейшим критерием является производительность на операциях над вещественными числами (числами с плавающей запятой). Для "экономической" машины эти операции не нужны вообще, зато очень полезны десятичные операции (ибо правила округления и т.п. вещи в экономике жёстко регламентированы и, естественно, под десятичную систему) и быстрый ввод-вывод, поскольку машине приходится не столько считать, сколько вводить и выводить данные.
Очевидно, что разный род задач требует для своего эффективного решения разного набора команд у процессора. Скажем, наша БЭСМ-6 (1967 год) -- самая мощная из советских "числодробилок" -- на научных расчётах была раза в два быстрей, чем самая мощная из ранних ЕС ЭВМ -- ЕС-1050 (надеюсь, руки дойдут и про неё написать), да и с американскими успешно могла соревноваться, если не считать суперкомпьютеров CDC, которые были в пике раз в 10 быстрей. Но на экономических расчётах её даже не пытались сравнивать с ЕС ЭВМ: система команд БЭСМ-6 исключительно неэффективна для любых задач, кроме научных (у неё даже операций над целыми числами как таковых нет, насколько помню), да и с последними тоже не всё так радужно.
IBM же делала Систему 360 как универсальную, 360 в её обозначении -- это рекламные "360 градусов", пригодность для любых задач (что не соответствовало действительности даже тогда, но было куда ближе к ней, чем у подавляющего большинства, если не у всех вообще, других компьютерных архитектур того времени).
Следствием разного характера задач в случае "экономики" является постоянная недогруженность процессора: он, по большей части, стоит и ждёт, пока будет введена очередная порция исходных данных или выведен результат предыдущих расчётов (что тогда, что сейчас процессор намного более быстр, чем периферия). Учитывая огромную стоимость "железа" в те годы, желательно процессор как-то суметь загрузить -- а значит, нужно параллельно выполнять несколько задач и, когда одна останавливается в ожидании завершения ввода-вывода, передавать управление другой, готовой к работе задаче.
Но, чтобы иметь возможность выполнять несколько задач, они должны быть загружены в память -- а значит, подавай большой объём памяти. У той же БЭСМ-6 адрес был 15-разрядным, а соответственно, предельный объём памяти -- 32 Кслова (слово там 48 бит, поэтому условно будем считать, что память у неё -- 96 Кбайт, хотя байтовой организации там не было, что тоже сильно мешало решению любых задач, кроме научных). Ну а у Системы 360 -- 24 бита, что позволяло иметь объём памяти до 16 Мбайт (абсолютно немыслимая величина в те годы, такой объём мощные машины "у них" получили лишь во второй половине 1970-х, когда у нас уже была грустная шутка про "мегабайт -- американское название килобайта").
Для того, чтобы управлять несколькими параллельно работающими задачами, нужна достаточно развитая операционная система, а также некоторые вспомогательные "железные" механизмы -- как минимум, защита памяти и таймер. У Системы 360 это было, у большинства других архитектур -- нет. Плюс, нужна лишняя память под нужды самой системы.
Следствием разного объёма данных является разный набор внешних устройств -- и по скорости, и по объёму. Вполне возможно, что именно это стало одной из причин нашего отставания в этой области (куда большего отставания, замечу, чем в области собственно процессоров): мы просто толком не занимались, скажем, магнитной записью (абы как сделали -- и ладно), поэтому не было ни дисководов (только магнитные барабаны малой ёмкости -- они намного проще по конструкции), ни хороших материалов для магнитных лент (из-за чего "у них" давно писали уже с плотностью 246 бит/мм, а у нас -- только 32, поскольку даже для 63 бит/мм наши магнитные ленты, по большей части, не годились).
Что касается ОС, её ещё надо написать -- а это огромный объём работы, ну а в одной IBM было больше программистов, чем во всём СССР. "Научные" задачи у нас нередко гоняли вообще без всякой ОС: просто вводили в память машины и запускали. Эффективное же решение "экономических" задач с подобным подходом невозможно.
Я бы сравнил решение о копировании архитектуры с копированием B-29 по приказу Сталина. По легенде, Туполев сказал: зачем копировать, мы сделаем лучше! Ну а Сталин ему ответил: "не надо лучше, сделайте такой же". Сделали, назвали Ту-4. Понятно, что самолёт изначально был устаревший (раз в 1944 он уже летал и бомбил японцев, значит, на момент начала копирования он уже был "старым", пускай и новейшим в строевых частях -- американские конструкторы уже разрабатывали следующие самолёты). Но его копирование потребовало создать нормальную авиационную промышленность и смежные производства вместо той полукустарщины, что была у нас: серийно выпускать столь сложный самолёт "на коленке" просто невозможно, поэтому пришлось подтягивать технологии и производство, повышать его культуру и т.д. и т.п. (а не подстраивать проект самолёта под имеющиеся возможности, как было бы в случае "сделаем лучше": единичный экземпляр точно сделали б лучше, а вот запустить серию...).