Ага, в обычной официальной документации вроде б не упоминается, но без проблем отыскивается в системной макробиблиотеке. Правда, её использование, в принципе, можно запретить беспарольным заданиям, но обычно с этим не заморачивались.
Если кратко -- делая что-то, надо включать мозги и смотреть, какие правила, рекомендации и т.п. полезны для данного случая, а какие -- вредны, а не следовать им, "потому что так правильно". Скажем, был у меня коллега, который прошивку одного промышленного прибора на микроконтроллере (какой-то из младших STM32) писал примерно как положено по чистому коду: с классами, виртуальными функциями и прочим -- в общем, как уместно было бы, скажем, в игровом движке, где заранее невозможно предсказать, какие расширения "каркаса" потребуются при создании множества продуктов на его основе разными людьми и, вероятно, на протяжении очень длительного времени. Но здесь-то -- не игровой движок, а прошивка промышленной железяки под вполне определённую задачу, которую один раз написал и, скорей всего, больше к ней возвращаться не будешь -- работает и работает, что-то измеряет, какие-то циферки показывает, что-то куда-то передаёт по вполне определённым интерфейсам...
Ну а что здесь удивительного? Процессор формировал канальные программы и запускал их, всё остальное делалось без его участия: контроллер дисков сам управлял накопителями, позиционируя головки и затем записывая разметку на дорожки. Естественно, время от времени процессор и канал конфликтовали при доступе к ОП, что слегка подтормаживало работу процессора, но не более того.
Да, было такое -- экономили место, но не в кодовых таблицах (пустого места в EBCDIC было предостаточно), а на барабанах принтеров, в первую очередь. Из-за этого сортировка в ОС ЕС была доработана: при запуске можно было указать, сортировать по-русски или по-английски.
Ну, для чего АСВТ нужна была, понятно. Непонятно, почему в её рамках разрабатывали машину верхнего уровня в виде той же самой ЕСки, вид сбоку -- вместо того, чтоб делать всё ИБМ-совместимое в рамках одного проекта, PDP-совместимое -- в другом, HP-совместимое -- в третьем (а два последних в итоге смешали в одну кучу). Ничто ведь не мешало использовать ЕСки вместе с машинами из АСВТ и СМками -- как, собственно, и бывало на практике; да и в качестве управляющих в строгом смысле слова они никогда не годились -- слишком большие, дорогие, сложные и недостаточно надёжные. Обработка экономической информации, всякая там статистика и т.д. -- да, это их область, но не прямое управление оборудованием или участие в техпроцессах.
Ну а централизация как позволяла эффективней использовать ресурсы, не распыляя их -- но на практике получилось, что у нас ни конкуренции нормальной не было, как у капиталистов, ни эффективного использования возможностей централизации.
80 символов в строке у Кобола -- это не ограничение бумажного бланка, это ограничение перфокарты. Но, честно говоря, удивлён таким использованием сего языка. Вот экономические задачи, решаемые в пакетном режиме, на нём было писать весьма приятно.
Во-первых, есть любители истории вычислительной техники -- в первую очередь расчёт на них. Во-вторых, в технологиях 50-летней давности тоже встречаются интересные решения, особенно с учётом того, что решать приходилось сложные задачи, а ресурсы были куда более ограниченными, чем сейчас (грубо говоря, чтоб заставить мигать лампочку, нужно было делать мультивибратор на двух транзисторах, а не ставить какую-нибудь Raspberry Pi с несколькими 64-битными ядрами и десятками миллионов транзисторов).
Вычислять квадратный корень может потребоваться и на процессоре, не имеющем не только его аппаратной реализации, но и вообще какой-либо поддержки операций с плавающей запятой -- скажем, на любом микроконтроллере с ядром Cortex-M3 или вообще на Ардуине. И вот там подобная магия может дать многократный прирост (особенно если писать на ассемблере). В общем, если нечто становится не особо актуальным для ПК, может быть вполне себе актуальным для других платформ.
OS/360 -- не первая ОС для мэйнфреймов IBM; DOS/360 и ещё пара систем были разработаны раньше. Вот первой "большой" ОС, и не только для мэйнфреймов IBM, а вообще в истории, она, пожалуй, является. Не является она и "монолитным блоком программного кода", она состоит от огромного числа модулей, загружаемых по мере необходимости. Именно это дало возможность системе объёмом в несколько сотен килобайт работать на машинах с заметно меньшим объёмом памяти -- причём ещё до появления MMU, то есть без виртуальной памяти. У ядра была фиксированная часть, всегда находившаяся в основной памяти, и были модули, которые по мере необходимости загружались в транзитные области. Пользователи системы могли для неё писать свои модули, если возникала такая необходимость.
Не, z/Architecture -- это именно что продолжение Системы 360 -- через Систему 370, 370-XA, ESA/370 и ESA/390. Каждое новое поколение добавляло новые фишки, но полная программная совместимость прикладного кода сохранялась (вот совместимость на системном уровне была утрачена при переходе от 370 к 370-XA -- и IBM как раз поступила очень разумно, не потащив кучу старья и дальше, и предпочтя просто модифицировать код ОС -- ведь на прикладных программах изменения никак не сказались, как впрочем, и на 95% системного кода). Сейчас там, конечно, больше тыщи команд (против 144 изначально), но, в общем-то, они вполне в мозги лезут -- потому что вполне логичны, по большей части. Я, конечно, наизусть не скажу команды, скажем, векторной обработки, -- я для современных мэйнфреймов я и не писал, но их относительно немного, это не бесконечные MMX, SSE и прочие AVX, так что, если бы я их использовал постоянно, я б запомнил без проблем (ну а если б использовал изредка -- без проблем находил бы нужные команды в руководстве по архитектуре, оно не особо объёмное).
Что касается разброда и шатаний в рамках Системы 360 -- это я в курсе, естественно. Но, прямо скажем, это неудивительно: хотя сама архитектура была эпохальной, появилась-то она в переходный период (собственно, во многом его и определив), вот и страдали экспериментами. А вот какого лешего, например, чехи сделали ублюдочную ЕС-1021, этого и они сами, надо полагать, не поняли: вроде и Система 360, а на системном уровне совместимости нет, половины команд прикладного уровня тоже нет... И ведь это уже начало 1970-х было -- казалось бы, можно учесть чужой (IBMовский) опыт и не бегать по граблям...
Насчёт системы команд IA-32. Я в данном случае говорю не про вместимость черепной коробки, а про гадостность именно системы команд на базовом уровне. Например, "MOV EAX, константа" может кодироваться несколькими разными способами (а в 64-разрядной, кажется, только в RAX можно загрузить 64-разрядную константу, в остальные регистры -- фигвам); строковые операции обязательно используют ESI, EDI и ECX, использование в качестве базовых одних регистров влечёт к обращению через один сегментный регистр, а других -- через другой (и не всегда это можно подменить префиксами), длина команды не может быть определена простыми средствами и т.д. и т.п.; для деления в 8086 использовались строго определённые регистры и регистровые пары -- не помню, исправили это в 80386 или уже позже... И вся эта дурь тянется для совместимости и дальше. Причём, замечу, если некоторые косяки системы команд Системы 360 простительны -- она формировалась в первой половине 1960-х, в условиях ещё полнейшего архитектурного хаоса, то идиотизм архитекторов Интел просто поражает: они собрали практически все возможные глупые решения, но делали это уже в середине 1970-х! Более того, переходя, уже в 1980-х, на 32-разрядную систему команд, они поступили не как DEC, у которой VAX-11 "идеологически" подобен PDP-11, но на уровне кодирования команд и прочего не имеет никакой совместимости для обеспечения эффективности реализации, -- они решили тянуть прямую совместимость с откровенно уродской системой команд 8086 (сравните её, скажем, с 68000 и Z8000 -- все три этих микропроцессора являются современниками), а не оставить её чисто для 16-разрядного режима, в 32-разрядном переключаясь на новую, эффективно закодированную систему команд (VAX-11 могла выполнять прикладные программы PDP-11 именно таким путём).
Восьмеричная система, кстати, никак не напрягает, это вопрос привычки; для PDP-11 она была естественней: восемь регистров, восемь режимов адресации... Я легко прыгал с одной на другую в зависимости от того, приходилось ли иметь дело с СМкой или ЕСкой.
Насчёт терминалов. А Вы гляньте, когда появился VT100 и на чём он был сделан. IBM делала технику много раньше, на другом технологическом уровне, и для того времени всё было очень даже круто (хотя временами переусложнено -- тут соглашусь). Редактировать там, кстати, можно было не строку, а весь экран. Ну а что до ЖабаСкрипта... Он появился, по историческим меркам, вчера -- а не в эпоху мамонтов :) Вот игры -- да, бяда-бяда, но в IBM сидели скучные дяди, ориентированные исключительно на бизнес-задачи :) (Кстати, в змейке на СМке для меня всё один раз закончилось надписью "кролики кончились" :) ).
Это понятно; я к тому, что, если б у машины что-то не в порядке было с напряжением питания подложек, то микросхемы должны были бы гореть оптом, а не по штуке в месяц. Думаю, это просто ранняя серия микросхем была, ещё недостаточно надёжная (возможно, потому "золотая", типа военная, машина попала на гражданское предприятие -- подозреваю, что вояки в те годы ещё предпочитали нормально работающую ферритовую память). Но ремонтировал не я, я де-факто системщиком был и просто ковырялся в железе ради собственного удовольствия, поэтому не знаю, выходили ли из строя повторно уже заменённые микросхемы, или же дохли только те, что были установлены на заводе (микросхемы из ЗИПа были относительно новые -- примерно 1985 года выпуска или даже несколько позже; сама история имела место в конце 80-начале 90-х).
Для уровня технологий СССР -- да, но не для уровня технологий IBM, от которой мы отставали лет на 10. Поэтому если сравнивать 486, то с современной ему продукцией именно IBM.
Позвольте не согласиться :) В именно мэйнфреймовых процах, ведущих свою генеалогию от Системы 360, почти всё стройно, чётко и понятно до сих пор, хотя их расширяли многократно -- начиная с той же системы команд и её кодирования. Попробуйте, например, определить длину кода команды для IA-32: она может составлять от 1 до 15 байтов включительно, и для определения необходимо проанализировать несколько начальных байтов, причём нельзя заранее сказать, сколько именно. А вот что в Системе 360, что в z/Architecture длина кода команды однозначно определяется двумя старшими битами первого байта кода команды (1, 2 или 3 полуслова). То же касается положения полей номеров регистров и смещений в коде команды: имеется всего несколько вариантов; соответственно, схема выборки и декодирования команд и вычисления адресов операндов очень проста и не занимает, грубо говоря, половину процессора. Упрощается и жизнь программиста: в общем и целом, регистры имеют действительно общее назначение -- а в 8086 у них у всех назначение было разное, что с появлением IA-32 лишь было ослаблено, но не изжито полностью (и, естественно, тянется до сих пор для совместимости). Ужасна и системная архитектура с сегментами, дескрипторами и прочим -- недаром в реальных ОС почти все эти возможности не используются (и были выпилены AMD при разработке 64-разрядного расширения архитектуры). Полный идиотизм -- возможность считывания системной информации (адресов таблиц дескрипторов, кажется -- не помню подробности) из пользовательского кода, потому что соответствующие команды являются непривилегированными (из-за этого до появления специальной поддержки была невозможна реализация виртуальных машин -- а на Системе 370 для неё было достаточно обычной поддержки виртуальной памяти). Вот что PowerPC -- монстр, тут я согласен, но это совершенно другая архитектура.
Кстати говоря, 3270 не просто так появились. Стояла задача к одной относительно слабой машине подключать десятки, а то и сотни пользователей -- и эти терминалы успешно данную задачу решали, поскольку многие функции выполняли автономно, а не как, скажем, в PDP-11, она же СМ ЭВМ, где на каждое нажатие клавиши на терминале дёргался процессор машины -- что, естественно, сильно ограничивало возможности совместной работы. Скажем, когда кто-то на СМ-4 запускал компиляцию сколько-нибудь сложной программы, текстовые редакторы других пользователей начинали подтормаживать -- а для 3270 (он же ЕС-7927) тормоза возникали лишь в ситуациях, когда реально был нужен ответ машины, а не при простом редактировании текста, выполняемым чисто автономно. По сути, та же самая концепция реализуется современными веб-браузерами: пока ты на своём компе заполняешь формочку, удалённый сервер не дёргается, запрос ему отправляется лишь при нажатии тобой некоей кнопки.
И, между прочим, система команд PDP-11 и VAX-11 приятней, чем Системы 360, про интеловских ублюдков вообще молчу :) Но на системном уровне архитектура мэйнфреймов в общем и целом и мощнее, и стройнее.
И, кстати, про виртуализацию: на мэйнфреймах для неё не требовалось никакой специальной поддержки -- если она была, некоторые вещи ускорялись, но не более того. Ну а на IA-32 aka x86 без специальной поддержки она вообще невозможна в силу кривизны архитектуры. Вообще, архитектурно Интел за всю жизнь ничего вменяемого не сделал, похоже -- сплошь извраты и бег по граблям (которые потом мужественно преодолевались на уровне микроархитектуры).
Ну, понятно, что 486-й делал советские мэйнфреймы -- но это машины совсем разных эпох. Он точно так же уделает IBMовский мэйнфрейм конца 1970-х -- чему ЕС-1066 примерно соответствовала и по производительности, и по технологичности. Но я говорю про архитектуру, а не про конкретные реализации. Никакая суперсовременная персоналка даже близко не подойдёт по производительности к современному мэйнфрейму z/Architecture -- а они ж являются прямым продолжением Системы 360 и сохраняют совместимость снизу-вверх на уровне прикладного кода. Что же машин на базе GPU, то, думается, сравнение не совсем корректно: их "аналоги" на рассыпухе -- скорей, Cray и прочие суперкомпьютеры начала 80-х. Всё ж там упор на матричные вычисления и прочий SIMD; если задача не допускает распараллеливания, любой GPU сольёт по производительности даже отнюдь не блестящему по характеристикам обычному процу аналогичного технологического уровня.
Ага, в обычной официальной документации вроде б не упоминается, но без проблем отыскивается в системной макробиблиотеке. Правда, её использование, в принципе, можно запретить беспарольным заданиям, но обычно с этим не заморачивались.
Вот это -- запросто :) И, кстати, не везде микропрограммная. Например, у ЕС-1050 чисто схемное управление что процессором, что каналами.
Если кратко -- делая что-то, надо включать мозги и смотреть, какие правила, рекомендации и т.п. полезны для данного случая, а какие -- вредны, а не следовать им, "потому что так правильно". Скажем, был у меня коллега, который прошивку одного промышленного прибора на микроконтроллере (какой-то из младших STM32) писал примерно как положено по чистому коду: с классами, виртуальными функциями и прочим -- в общем, как уместно было бы, скажем, в игровом движке, где заранее невозможно предсказать, какие расширения "каркаса" потребуются при создании множества продуктов на его основе разными людьми и, вероятно, на протяжении очень длительного времени. Но здесь-то -- не игровой движок, а прошивка промышленной железяки под вполне определённую задачу, которую один раз написал и, скорей всего, больше к ней возвращаться не будешь -- работает и работает, что-то измеряет, какие-то циферки показывает, что-то куда-то передаёт по вполне определённым интерфейсам...
Ну а что здесь удивительного? Процессор формировал канальные программы и запускал их, всё остальное делалось без его участия: контроллер дисков сам управлял накопителями, позиционируя головки и затем записывая разметку на дорожки. Естественно, время от времени процессор и канал конфликтовали при доступе к ОП, что слегка подтормаживало работу процессора, но не более того.
Угу. Но диапазон значений байтов, которые можно было передать машине, был ограничен, поэтому вряд ли бы удалось практически.
Бывали, да. Правда, я с ними не сталкивался и даже не видел, так что про практическое использование ничего не скажу.
Да, было такое -- экономили место, но не в кодовых таблицах (пустого места в EBCDIC было предостаточно), а на барабанах принтеров, в первую очередь. Из-за этого сортировка в ОС ЕС была доработана: при запуске можно было указать, сортировать по-русски или по-английски.
Ну, для чего АСВТ нужна была, понятно. Непонятно, почему в её рамках разрабатывали машину верхнего уровня в виде той же самой ЕСки, вид сбоку -- вместо того, чтоб делать всё ИБМ-совместимое в рамках одного проекта, PDP-совместимое -- в другом, HP-совместимое -- в третьем (а два последних в итоге смешали в одну кучу). Ничто ведь не мешало использовать ЕСки вместе с машинами из АСВТ и СМками -- как, собственно, и бывало на практике; да и в качестве управляющих в строгом смысле слова они никогда не годились -- слишком большие, дорогие, сложные и недостаточно надёжные. Обработка экономической информации, всякая там статистика и т.д. -- да, это их область, но не прямое управление оборудованием или участие в техпроцессах.
Ну а централизация как позволяла эффективней использовать ресурсы, не распыляя их -- но на практике получилось, что у нас ни конкуренции нормальной не было, как у капиталистов, ни эффективного использования возможностей централизации.
80 символов в строке у Кобола -- это не ограничение бумажного бланка, это ограничение перфокарты. Но, честно говоря, удивлён таким использованием сего языка. Вот экономические задачи, решаемые в пакетном режиме, на нём было писать весьма приятно.
Во-первых, есть любители истории вычислительной техники -- в первую очередь расчёт на них. Во-вторых, в технологиях 50-летней давности тоже встречаются интересные решения, особенно с учётом того, что решать приходилось сложные задачи, а ресурсы были куда более ограниченными, чем сейчас (грубо говоря, чтоб заставить мигать лампочку, нужно было делать мультивибратор на двух транзисторах, а не ставить какую-нибудь Raspberry Pi с несколькими 64-битными ядрами и десятками миллионов транзисторов).
Вычислять квадратный корень может потребоваться и на процессоре, не имеющем не только его аппаратной реализации, но и вообще какой-либо поддержки операций с плавающей запятой -- скажем, на любом микроконтроллере с ядром Cortex-M3 или вообще на Ардуине. И вот там подобная магия может дать многократный прирост (особенно если писать на ассемблере). В общем, если нечто становится не особо актуальным для ПК, может быть вполне себе актуальным для других платформ.
OS/360 -- не первая ОС для мэйнфреймов IBM; DOS/360 и ещё пара систем были разработаны раньше. Вот первой "большой" ОС, и не только для мэйнфреймов IBM, а вообще в истории, она, пожалуй, является. Не является она и "монолитным блоком программного кода", она состоит от огромного числа модулей, загружаемых по мере необходимости. Именно это дало возможность системе объёмом в несколько сотен килобайт работать на машинах с заметно меньшим объёмом памяти -- причём ещё до появления MMU, то есть без виртуальной памяти. У ядра была фиксированная часть, всегда находившаяся в основной памяти, и были модули, которые по мере необходимости загружались в транзитные области. Пользователи системы могли для неё писать свои модули, если возникала такая необходимость.
Ну, 176-я серия -- она КМОП, там с аналоговым режимом попроще будет, насколько знаю. Но вообще, народ остроумные конструкции временами делал, это да.
Не, z/Architecture -- это именно что продолжение Системы 360 -- через Систему 370, 370-XA, ESA/370 и ESA/390. Каждое новое поколение добавляло новые фишки, но полная программная совместимость прикладного кода сохранялась (вот совместимость на системном уровне была утрачена при переходе от 370 к 370-XA -- и IBM как раз поступила очень разумно, не потащив кучу старья и дальше, и предпочтя просто модифицировать код ОС -- ведь на прикладных программах изменения никак не сказались, как впрочем, и на 95% системного кода). Сейчас там, конечно, больше тыщи команд (против 144 изначально), но, в общем-то, они вполне в мозги лезут -- потому что вполне логичны, по большей части. Я, конечно, наизусть не скажу команды, скажем, векторной обработки, -- я для современных мэйнфреймов я и не писал, но их относительно немного, это не бесконечные MMX, SSE и прочие AVX, так что, если бы я их использовал постоянно, я б запомнил без проблем (ну а если б использовал изредка -- без проблем находил бы нужные команды в руководстве по архитектуре, оно не особо объёмное).
Что касается разброда и шатаний в рамках Системы 360 -- это я в курсе, естественно. Но, прямо скажем, это неудивительно: хотя сама архитектура была эпохальной, появилась-то она в переходный период (собственно, во многом его и определив), вот и страдали экспериментами. А вот какого лешего, например, чехи сделали ублюдочную ЕС-1021, этого и они сами, надо полагать, не поняли: вроде и Система 360, а на системном уровне совместимости нет, половины команд прикладного уровня тоже нет... И ведь это уже начало 1970-х было -- казалось бы, можно учесть чужой (IBMовский) опыт и не бегать по граблям...
Насчёт системы команд IA-32. Я в данном случае говорю не про вместимость черепной коробки, а про гадостность именно системы команд на базовом уровне. Например, "MOV EAX, константа" может кодироваться несколькими разными способами (а в 64-разрядной, кажется, только в RAX можно загрузить 64-разрядную константу, в остальные регистры -- фигвам); строковые операции обязательно используют ESI, EDI и ECX, использование в качестве базовых одних регистров влечёт к обращению через один сегментный регистр, а других -- через другой (и не всегда это можно подменить префиксами), длина команды не может быть определена простыми средствами и т.д. и т.п.; для деления в 8086 использовались строго определённые регистры и регистровые пары -- не помню, исправили это в 80386 или уже позже... И вся эта дурь тянется для совместимости и дальше. Причём, замечу, если некоторые косяки системы команд Системы 360 простительны -- она формировалась в первой половине 1960-х, в условиях ещё полнейшего архитектурного хаоса, то идиотизм архитекторов Интел просто поражает: они собрали практически все возможные глупые решения, но делали это уже в середине 1970-х! Более того, переходя, уже в 1980-х, на 32-разрядную систему команд, они поступили не как DEC, у которой VAX-11 "идеологически" подобен PDP-11, но на уровне кодирования команд и прочего не имеет никакой совместимости для обеспечения эффективности реализации, -- они решили тянуть прямую совместимость с откровенно уродской системой команд 8086 (сравните её, скажем, с 68000 и Z8000 -- все три этих микропроцессора являются современниками), а не оставить её чисто для 16-разрядного режима, в 32-разрядном переключаясь на новую, эффективно закодированную систему команд (VAX-11 могла выполнять прикладные программы PDP-11 именно таким путём).
Восьмеричная система, кстати, никак не напрягает, это вопрос привычки; для PDP-11 она была естественней: восемь регистров, восемь режимов адресации... Я легко прыгал с одной на другую в зависимости от того, приходилось ли иметь дело с СМкой или ЕСкой.
Насчёт терминалов. А Вы гляньте, когда появился VT100 и на чём он был сделан. IBM делала технику много раньше, на другом технологическом уровне, и для того времени всё было очень даже круто (хотя временами переусложнено -- тут соглашусь). Редактировать там, кстати, можно было не строку, а весь экран. Ну а что до ЖабаСкрипта... Он появился, по историческим меркам, вчера -- а не в эпоху мамонтов :) Вот игры -- да, бяда-бяда, но в IBM сидели скучные дяди, ориентированные исключительно на бизнес-задачи :) (Кстати, в змейке на СМке для меня всё один раз закончилось надписью "кролики кончились" :) ).
Это понятно; я к тому, что, если б у машины что-то не в порядке было с напряжением питания подложек, то микросхемы должны были бы гореть оптом, а не по штуке в месяц. Думаю, это просто ранняя серия микросхем была, ещё недостаточно надёжная (возможно, потому "золотая", типа военная, машина попала на гражданское предприятие -- подозреваю, что вояки в те годы ещё предпочитали нормально работающую ферритовую память). Но ремонтировал не я, я де-факто системщиком был и просто ковырялся в железе ради собственного удовольствия, поэтому не знаю, выходили ли из строя повторно уже заменённые микросхемы, или же дохли только те, что были установлены на заводе (микросхемы из ЗИПа были относительно новые -- примерно 1985 года выпуска или даже несколько позже; сама история имела место в конце 80-начале 90-х).
Для уровня технологий СССР -- да, но не для уровня технологий IBM, от которой мы отставали лет на 10. Поэтому если сравнивать 486, то с современной ему продукцией именно IBM.
Ну, тогда б они дохли пачками, а они отбрасывали копыта строго по одной. Так что вряд ли дело было в напряжении смещения.
Позвольте не согласиться :) В именно мэйнфреймовых процах, ведущих свою генеалогию от Системы 360, почти всё стройно, чётко и понятно до сих пор, хотя их расширяли многократно -- начиная с той же системы команд и её кодирования. Попробуйте, например, определить длину кода команды для IA-32: она может составлять от 1 до 15 байтов включительно, и для определения необходимо проанализировать несколько начальных байтов, причём нельзя заранее сказать, сколько именно. А вот что в Системе 360, что в z/Architecture длина кода команды однозначно определяется двумя старшими битами первого байта кода команды (1, 2 или 3 полуслова). То же касается положения полей номеров регистров и смещений в коде команды: имеется всего несколько вариантов; соответственно, схема выборки и декодирования команд и вычисления адресов операндов очень проста и не занимает, грубо говоря, половину процессора. Упрощается и жизнь программиста: в общем и целом, регистры имеют действительно общее назначение -- а в 8086 у них у всех назначение было разное, что с появлением IA-32 лишь было ослаблено, но не изжито полностью (и, естественно, тянется до сих пор для совместимости). Ужасна и системная архитектура с сегментами, дескрипторами и прочим -- недаром в реальных ОС почти все эти возможности не используются (и были выпилены AMD при разработке 64-разрядного расширения архитектуры). Полный идиотизм -- возможность считывания системной информации (адресов таблиц дескрипторов, кажется -- не помню подробности) из пользовательского кода, потому что соответствующие команды являются непривилегированными (из-за этого до появления специальной поддержки была невозможна реализация виртуальных машин -- а на Системе 370 для неё было достаточно обычной поддержки виртуальной памяти). Вот что PowerPC -- монстр, тут я согласен, но это совершенно другая архитектура.
Кстати говоря, 3270 не просто так появились. Стояла задача к одной относительно слабой машине подключать десятки, а то и сотни пользователей -- и эти терминалы успешно данную задачу решали, поскольку многие функции выполняли автономно, а не как, скажем, в PDP-11, она же СМ ЭВМ, где на каждое нажатие клавиши на терминале дёргался процессор машины -- что, естественно, сильно ограничивало возможности совместной работы. Скажем, когда кто-то на СМ-4 запускал компиляцию сколько-нибудь сложной программы, текстовые редакторы других пользователей начинали подтормаживать -- а для 3270 (он же ЕС-7927) тормоза возникали лишь в ситуациях, когда реально был нужен ответ машины, а не при простом редактировании текста, выполняемым чисто автономно. По сути, та же самая концепция реализуется современными веб-браузерами: пока ты на своём компе заполняешь формочку, удалённый сервер не дёргается, запрос ему отправляется лишь при нажатии тобой некоей кнопки.
И, между прочим, система команд PDP-11 и VAX-11 приятней, чем Системы 360, про интеловских ублюдков вообще молчу :) Но на системном уровне архитектура мэйнфреймов в общем и целом и мощнее, и стройнее.
И, кстати, про виртуализацию: на мэйнфреймах для неё не требовалось никакой специальной поддержки -- если она была, некоторые вещи ускорялись, но не более того. Ну а на IA-32 aka x86 без специальной поддержки она вообще невозможна в силу кривизны архитектуры. Вообще, архитектурно Интел за всю жизнь ничего вменяемого не сделал, похоже -- сплошь извраты и бег по граблям (которые потом мужественно преодолевались на уровне микроархитектуры).
Ну, понятно, что 486-й делал советские мэйнфреймы -- но это машины совсем разных эпох. Он точно так же уделает IBMовский мэйнфрейм конца 1970-х -- чему ЕС-1066 примерно соответствовала и по производительности, и по технологичности. Но я говорю про архитектуру, а не про конкретные реализации. Никакая суперсовременная персоналка даже близко не подойдёт по производительности к современному мэйнфрейму z/Architecture -- а они ж являются прямым продолжением Системы 360 и сохраняют совместимость снизу-вверх на уровне прикладного кода. Что же машин на базе GPU, то, думается, сравнение не совсем корректно: их "аналоги" на рассыпухе -- скорей, Cray и прочие суперкомпьютеры начала 80-х. Всё ж там упор на матричные вычисления и прочий SIMD; если задача не допускает распараллеливания, любой GPU сольёт по производительности даже отнюдь не блестящему по характеристикам обычному процу аналогичного технологического уровня.