Процессор ЭВМ ЕС-1020. Блок регистров

Ну, система команд PDP-11, как по мне, -- лучшая среди 16-разрядных, а VAX-11 -- среди 32-разрядных, но, как говорится, есть нюансы.

Адресация у DECовских машин более гибкая и эффективная, что, естественно, способствует сокращению объёма программы и потенциально -- повышению производительности. В то же время базовая система команд Системы 360 более проста для реализации (пять чётких форматов команд, не имеющих значимых с точки зрения выборки-декодирования исключений, более простая адресация -- обычная сумма одного-двух регистров и смещения, без всяких модификаций регистров, косвенной адресации и т.п.), и её намного проще "положить на конвейер" -- уже первые старшие модели Системы 360, как и наша ЕС-1050, были конвейерными, и, понятно, по производительности рвали любую PDP-11 как тузик грелку. Сделать конвейерную PDPшку или VAX... можно, но значительно сложней (а соответственно, куда больше логики нужно -- и на тогдашнем технологическом уровне это было недостижимо из соображений стоимости и габаритов).

Кроме того, система команд у Системы 360 побогаче будет, а в дальнейшем она всё расширялась и продолжает расширяться -- при этом умудряются не сломать совместимость и поддерживать простоту кодирования (сейчас, например, какое-нибудь там шифрование выполняется одной командой -- и, естественно, обеспечивается намного более высокая производительность, чем у самого навороченного "обычного" процессора, где это надо делать программно). Наличие команд десятичной арифметики, например, резко упрощает жизнь разработчикам экономических приложений -- не надо никаких мер предосторожности, чтоб результаты получались такие же, как при ручных вычислениях (в двоичной возможны нюансы из-за округления; плюс диапазон представимых чисел -- госдолг США, как мы помним, стало возможным хранить лишь в 64-разрядном регистре, ну а в Системе 360 -- запросто, там двоично-десятичные числа лежат в памяти и могут иметь до 31 цифры плюс знак; в PDP-11, кстати, теоретически присутствовал "коммерческий набор команд" -- CIS, но, похоже, встречался крайне редко). Команда TRT (одна из "костыльных" в том плане, что один из операндов является неявным и лежит в строго определённом регистре -- полей для кодирования не хватало) резко упрощает написание программ разбора текста (на ней, грубо говоря, половина лексического анализатора любого ассемблера/компилятора держится). Есть пересылка сразу порции данных (до 256 байтов), а также логические операции над байтовыми полями переменной длины -- соответственно, обнулить память можно куда быстрей, чем чисто программно в цикле (во всяком случае, теоретически: зависит от особенностей реализации; скажем, продвинутая модель, увидев "исключающее или" с одним и тем же стартовым адресом, может просто обнулить эту память, причём, естественно, не побайтово, как предполагается концептуально, а на всю ширину физического доступа в конкретной модели).

Ещё один аспект -- ввод-вывод. У Системы 360 он логически отделён от процессора и свален на каналы, что потенциально, не выходя за рамки архитектуры. позволяет реализовать очень быстрый обмен. У PDPшки всё висит на единственной довольно медленной шине; интенсивный обмен с диском запросто затормозит работу процессора и т.д. (Понятно, что у младших, а отчасти и средних моделей Системы 360 та же проблема -- но она вытекает не из архитектуры, а из реализации; в старших моделях процессор и каналы работают подлинно параллельно и тормоза возникают лишь при одновременном обращении к одному и тому же, выражаясь более современными терминами, банку памяти, -- но там выручает кэш, который у старших моделей появился довольно быстро, хотя у самых первых ещё не было, вроде бы). Поэтому для управляющих применений (где надо постоянно опрашивать битики в регистрах устройств и т.п.) PDPшка или, скажем, современный ARM подходит куда лучше, но вот при обработке больших массивов информации -- наоборот. (Попутно замечу, что великолепнейшая виртуализация машины, реализованная ещё в начале 1970-х в VM/370, так и осталась непревзойдённой по сей день -- если не считать z/VM, конечно, но она -- наследница VM/370 и работает на z/Architecture, выросшей из Системы 360 и сохранившей с ней совместимость на прикладном уровне; во многом она достигнута именно благодаря унифицированному вводу-выводу: гипервизору ничего не нужно знать про работу внешних устройств, если с ними умеет работать гостевая ОС -- он просто преобразует канальные программы в плане физических адресов памяти да передаёт их каналам на выполнение; в той же PDPшке виртуализация... как минимум, проблематична, в IA-32 aka x86 и вовсе невозможна без специальный аппаратной поддержки из-за абсолютнейшей кривизны архитектуры -- Интел, кажется, смогла воплотить все мыслимые и немыслимые архитектурные ошибки...)

Добавьте к этому аппаратный контроль. У PDPшек контролировали разве что чётность оперативной памяти и памяти микропрограмм; у Системы 360 контроль намного более полный, причём во многих более поздних моделях имеются средства восстановления, зачастую позволяющие продолжить работу при случайных сбоях, а уж обнаруживать проблемы вообще в 100% случаев (в младших моделях, особенно ранних, -- в частности, в ЕС-1020, -- он не такой полный, поэтому некоторые сбои будут оставаться "незамеченными", но большинство вещей всё ж контролируется; в частности, АЛУ выполнено в двух экземплярах, и результаты его работы сравниваются -- вот и куда больший объём аппаратуры по сравнению с СМками, ведь тогдашнее АЛУ -- это половина процессора).

Система 360 изначально предполагала возможность построения многопроцессорных систем. Правда, в этой версии архитектуры это было проработано довольно плохо, но опыта-то не было. Когда набрались, многое переделали -- уже в Системе 370, и это сохраняется до сих пор (с некоторыми расширениями).

Насчёт костылей в системе команд Системы 360 не согласен :) Они там есть, конечно, но их, пожалуй, меньше, чем в PDP-11, и существенно меньше, чем у VAX, хотя система команд по функционалу богаче PDPшки. Например, команда XOR в PDPшке -- костыльная по сравнению с остальными, у неё один из операндов обязательно должен лежать в регистре; имеется совершенно дурацкая команда... ээээ... MARK, кажется (вроде б компилятором Фортрана используется, но уж не помню столь интимные подробности); нет логических сдвигов (только арифметические), ещё там что-то было... MMU на многих моделях не позволяет реализовать полноценную виртуальную память (с загрузкой/выгрузкой задач по частям -- поскольку не обеспечивает правильный "откат" при прерывании в процессе выполнения команды), а там, где позволяет (PDP-11/70, например), это делается программными плясками (ОС должна сама выполнить "откат", MMU просто сохраняет нужную для этого информацию в одном из своих регистров) -- ну а в мэйнфреймах, когда виртуальную память сделали (в Системе 370, причём не сразу -- но очень быстро), сразу сделали правильно (принципиально она ничем не отличается от современных архитектур -- те же самые таблицы переадресации в памяти).

Что же касается сравнения с VAXом, то с ним корректней уже будет сравнивать поздние варианты Системы 370, а не ранние Системы 360 -- ведь между ними 10, если не больше, лет разницы. "Общая" система команд у VAX приятней будет, в общем и целом; в отдельных вещах он лучше и в специальных случаях, а Система 370 -- в других (десятичную арифметику, кажется, никто лучше так и не сделал -- одна из причин доминирования мэйнфреймов в финансовом секторе). По вводу-выводу VAX сильно уступает -- как уступает и любая современная архитектура (попробуй подключить к ПК -- именно к ПК, не по локалке, -- тысячи дисков, и чтоб оно ещё и летало, -- ну а к мэйнфрейму z/Architecture -- запросто, если у тебя есть деньги на эти тысячи дисков :) ).

На поздней Системе 370 появился механизм двойного адресного пространства (впоследствии расширен до множества адресных пространств), что резко упрощает и ускоряет реализацию программ-серверов, обслуживающих программы-клиенты. Без этого механизма вызов подпрограммы в сервере надо производить через ядро ОС, с ним -- можно вызывать прямо, при этом привилегии у клиента и сервера разные, но всё контролируется и защищено. У VAX ничего подобного я не видел -- хотя с поздними вариантами не знаком. В IA-32 было "жалкое подобие левой руки" -- таблицы дескрипторов со шлюзами вызова позволяют, теоретически, добиться того же, но всё было спроектировано настолько криво, что этими возможностями никто не пользовался (и AMD выпилила их, делая 64-разрядный вариант архитектуры, -- что впоследствии скопировала Интел, провалившись со своей IA-64 aka Itanium). В общем, в плане системной архитектуры, на мой взгляд, Система 360 и её наследники -- лучшее, что было и есть. По системе команд -- VAX лучше, если не брать частности (которые в него вполне можно было бы добавить, конечно). По простоте реализации -- безусловное превосходство Системы 360 (ну, это неудивительно: в первой половине 1960-х развернуться было особо негде, железо ограничивало -- отсюда, кстати, ряд костылей и неудачных решений, и в первую очередь -- 24-разрядный адрес памяти; просто, похоже, никто не думал, что через 20 лет этого будет мало). По гибкости ввода-вывода -- превосходство VAX, но по пропускной способности -- Системы 360.

В общем, разные архитектуры друг друга не исключают, а дополняют. Ставить Систему 360 в качестве управляющей машины -- верх идиотизма, пытаться заменить один мэйнфрейм тыщей персоналок -- примерно то же самое. Надо исходить из задачи и выбирать адекватные средства.

Уродливость системы команд -- понятие, которое зависит от вкуса, привычек, опыта работы с ними. Если сравнивать, к примеру, с MIPS или ARM (ранними), так ЕС вполне достойно смотрится.

Только зачем нужны красивые системы команд, когда на ассемблере не пишут практически ничего? Даже операционные системы. Уже при написании IBM MVS широко использовался язык PL/S, а это середина 1970-х.