IBM System/360 — революционное семейство мейнфреймов, анонсированное 7 апреля 1964 года. Для IBM это был крайне рискованный проект из серии «ставим на кон всю компанию»: он обошёлся более чем в 5 млрд долларов. 

Но в итоге System/360 стал огромным успехом и на десятилетия задал направление развития компьютерной индустрии. Архитектура S/360 оказалась настолько удачной, что почти 60 лет спустя её всё ещё поддерживают современные мейнфреймы IBM. Я разрабатываю симулятор на уровне микрокода^{(примеч.1)} для IBM System/360 Model 50 (ссылка на симулятор); в этой статье я даю контекст, который поможет разобраться в Model 50 и самом симуляторе.

Радикальное решение, лежавшее в основе System/360, заключалось в том, чтобы использовать единую архитектуру для всей линейки компьютеров.^{(примеч.3)} Само название символизировало «360 градусов, охватывающие весь круг возможных применений». Сейчас общая архитектура кажется очевидной идеей, например на примере x86, но до System/360 IBM, как и другие производители компьютеров, выпускала несколько машин с полностью несовместимыми архитектурами.

Внутри разные модели System/360 были реализованы совершенно по-разному, чтобы покрыть широкий диапазон цен и производительности: самая быстрая модель была более чем в 1000 раз мощнее самой медленной. Младшие модели использовали простое аппаратное обеспечение и 8-битный тракт данных, а старшие — широкие тракты данных, быстрые полупроводниковые регистры, внеочередное исполнение команд и кэши.^{(примеч.2)} Несмотря на эти внутренние различия, для программиста все модели выглядели одинаково.

Архитектура System/360

Можно было бы ожидать, что компьютерная архитектура 1960-х будет простой, но System/360^{(примеч.4)} устроена удивительно сложно — отчасти потому, что она объединила шесть семейств компьютеров в одну архитектуру. Это 32-битная архитектура с поддержкой множества типов данных. Помимо 32-битных целых и полуслов, она поддерживает десятичную арифметику для чисел длиной до 31 цифры. Арифметика с плавающей точкой поддерживает короткие 32-битные, длинные 64-битные и расширенные 128-битные значения. Процессор также поддерживает символьные строки длиной до 256 байт.

Набор команд System/360 включает около 100 разных команд и несколько режимов адресации. Часть этих команд — простые арифметические, логические или управляющие операции. Другие устроены сложнее, например команда пересылки символов, которая копирует в памяти до 256 символов, или команды с плавающей точкой.

Одна из самых сложных команд — edit: она форматирует последовательность десятичных цифр для печати, например вставляет запятые, знак минуса или десятичную точку, удаляет ведущие нули либо заполняет ведущие пробелы символами. Число 1234567 можно «отредактировать» в строку $***12,345.67 для печати на чеке. Важно помнить: это одна машинная команда, а не библиотечная функция вроде printf.

Архитектура System/360 также включала ввод-вывод и задавала IBM-овскую «канальную» архитектуру. Канал — это программируемая подсистема ввода-вывода со своим собственным набором команд. В старших системах канал был независимым блоком, подключённым к компьютеру. Но в младших системах, таких как Model 50, один и тот же микрокодовый движок выполнял и программы CPU, и канальные программы.

Интересно то, что у System/360 большой и сложный набор команд. Одна машинная команда могла приводить к сотням обращений к памяти и шагов обработки. Плотный набор команд помогал программистам втискивать программы в крайне ограниченную память на магнитных сердечниках 1960-х. Но для разработчика компьютера сложный набор команд становился проблемой: ему приходилось реализовывать сложные схемы, выполняющие эти команды. Решением стал микрокод.

Микрокод

Одна из самых сложных задач при проектировании компьютера — создать управляющую логику, которая указывает каждой части процессора, как выполнять каждую команду. В 1951 году Морис Уилкс предложил идею микрокода: вместо того чтобы строить управляющие схемы из сложных логических вентилей, управляющую логику можно заменить кодом, то есть микрокодом, хранящимся в специальной памяти — управляющей памяти. Чтобы выполнить команду, компьютер внутри выполняет несколько более простых микрокоманд, заданных микрокодом. Микрокод превращает разработку управляющей логики процессора из задачи проектирования схем в задачу программирования.^{(примеч.5)}

Микрокод сыграл ключевую роль в успехе System/360: он помог IBM выпустить линейку компьютеров с одной и той же архитектурой набора команд, но с очень разными реализациями. Он также позволял процессору поддерживать разные наборы команд; машины System/360 могли быть обратно совместимы со старыми машинами заказчиков,^{(примеч.6)} так что клиенты сохраняли уже имеющееся ПО. По этим причинам компьютеры System/360 использовали микрокод везде, где не было веской причины отказаться от него.^{(примеч.7)}

Ещё одно преимущество микрокода — он даёт простой способ исправлять ошибки проектирования и баги прямо на месте эксплуатации. Вместо того чтобы менять аппаратное обеспечение, сервисный инженер мог заменить микрокод на новую версию. На фото ниже показан медный лист с вытравленным микрокодом для Model 50.

Микрокод можно реализовать по-разному. Во многих компьютерах используется «вертикальный микрокод»: микрокоманда похожа на машинную команду, только менее сложную. В System/360, напротив, применялся «горизонтальный микрокод» — сложные широкие микрокоманды длиной до 100 бит, в зависимости от модели. Такие микрокоманды больше напоминали набор полей, каждое из которых управляло низкоуровневыми сигналами. Это повышало производительность, потому что несколькими частями процессора можно было управлять параллельно.

Аппаратное устройство Model 50

Model 50^{(примеч.8)} занимала примерно среднее место в линейке System/360 и представляла собой мощный мейнфрейм, подходивший для средней компании или университетского факультета. Обычно Model 50 арендовали примерно за 18–32 тысячи долларов в месяц, что соответствует 120–200 тысячам долларов в месяц в нынешних ценах.

Model 50 занимала три больших шкафа: каждый был 5 футов в длину, около 2 футов в ширину, 6 футов в высоту и весил почти тонну.^{(примеч.9)} Основной шкаф за консолью содержал CPU, схемы каналов ввода-вывода и хранилище микрокода. За ним находился шкаф питания с блоками питания компьютера. Слева, в заднем шкафу, размещалась основная память: один или два модуля памяти на магнитных сердечниках, каждый по 128 килобайт.  Кабели компьютера проходили под фальшполом к устройствам ввода-вывода: обычно это были ленточные накопители, устройство чтения перфокарт, принтеры, дисковые накопители, контроллеры ввода-вывода и так далее.

Процессоры System/360 были построены не на интегральных схемах, а на SLT-модулях — гибридных модулях, содержащих несколько транзисторов, диодов и резисторов. Типичный модуль реализовывал один логический вентиль, поэтому для сборки процессора требовалось множество печатных плат, полностью заполненных такими модулями.

Как и большинство компьютеров 1960-х, Model 50 использовала память на магнитных сердечниках: каждый бит хранился в крошечном ферритовом кольце. На фото ниже показана плоскость сердечников, хранящая 32 768 бит плюс ещё 512 бит для ввода-вывода. Стопка из 18 таких плоскостей образовывала 64-килобайтный модуль памяти с двумя битами чётности.^{(примеч.10)}

Внутренняя архитектура Model 50

Для программиста все процессоры System/360 выглядят одинаково, но внутри их схемы могут быть совершенно разными.

Важно помнить, что внутренняя архитектура Model 50 сильно отличается от архитектуры, которую видит программист.^{(примеч. 11)} В частности, внутренние регистры процессора программисту недоступны. Вместо этого он видит 16 регистров общего назначения и 4 регистра с плавающей точкой, но для самого процессора они являются частью 64-словного локального хранилища — небольшой быстрой памяти на магнитных сердечниках.

На схеме ниже показан сложный поток данных внутри компьютера.^{(примеч. 12)} Чёрные прямоугольники — внутренние регистры; у процессора их неожиданно много, и используются они для самых разных задач. Внутренние компоненты соединены шинами. Большая часть внутреннего обмена идёт по 32-битным шинам, показанным чёрным цветом. 8-битная шина блока mover показана серым.

Сердце компьютера — 32-битный сумматор, который выполняет сложение. Для вычитания аргумент дополняется схемой True/Complement (TC). С сумматором связан блок сдвига, выполняющий битовые сдвиги; это особенно важно для умножения, деления и вычислений с плавающей точкой. Параллельно с сумматором работает блок “mover”, который оперирует байтами. Он может извлекать байт из 32-битного слова, а также работать с 4-битными частями байта. Mover также выполняет булевы операции: AND, OR, XOR. В отличие от большинства процессоров, Model 50 разделяет арифметические и логические операции, а не поручает их одному АЛУ.

Основная память компьютера на магнитных сердечниках находится слева. Чтобы обратиться к памяти, адрес помещается в регистр адреса памяти (SAR). Затем данные читаются или записываются через регистр данных памяти (SDR). Слева от основной памяти находится регистр адреса команды — в современных терминах счётчик команд, или PC. Сверху расположено локальное хранилище: 64 слова быстрой памяти на магнитных сердечниках, где находятся регистры, видимые программисту, а также часть внутреннего хранилища. Доступ к локальному хранилищу идёт через регистр адреса локального хранилища (LSAR).

Справа находятся каналы ввода-вывода: низкоскоростной мультиплексорный канал и высокоскоростной селекторный канал. Их можно представить как пути DMA, то есть прямого доступа к памяти, для ввода-вывода. Мультиплексорный канал обменивается данными по 8-битной шине через mover, а селекторный канал — по 32-битной шине. Хотя концептуально каналы отделены от процессора, они используют те же шины, схемы и микрокодовый движок, что и сам процессор. Это ограничивает производительность ввода-вывода по сравнению с более продвинутыми моделями System/360, где для каналов была выделена независимая схема.

Пример микрокода

Как видно, у процессора много регистров и функциональных блоков. Микрокод должен управлять этими компонентами, чтобы выполнять команды программы. Архитектура микрокода очень сложна: чтобы подробно её объяснить, нужно больше 100 страниц,^{(примеч. 15)} поэтому здесь я смогу лишь слегка затронуть тему. Каждая микрокоманда имеет длину 90 бит и выполняет несколько задач. В документации IBM представляла каждую микрокоманду в виде 11-строчного блока, показывая все действия, которые выполняются параллельно.

Ниже показан пример микрокоманды — часть микрокода, реализующего команду сложения. К этому моменту предыдущие микрокоманды уже выбрали и декодировали команду и поместили аргументы в регистры R и L. Эта микрокоманда выполняет собственно 32-битное сложение, но помимо сложения здесь происходит ещё много всего.

Начнём со строки R+L→R, выделенной красным. Она означает, что АЛУ берёт входные данные из регистров R и L, а результат помещает в регистр R. Другими словами, два аргумента складываются. Результат R сохраняется в нужный регистр, видимый программисту, в локальном хранилище, показано синим. Регистры процессора FN и J выбирают адрес в локальном хранилище. В это же время строка SETCRALG устанавливает регистр кода условия по знаку результата, то есть по его «алгебраическому» значению, показывая, положительный результат, отрицательный или нулевой.

Строка BC⩝C означает, что обнаруживается знаковое переполнение и используется как флаг переноса,^{(примеч. 14)} а CAR, выделенный жёлтым, показывает, что микрокод ветвится по этому значению переноса, то есть переполнения. Поэтому микрокод пойдёт по одному пути, если сложение прошло корректно, и по другому, ошибочному, если произошло переполнение. Микрокоманда может выдавать произвольное 4-битное значение, выделенное зелёным, которое затем можно использовать разными способами. В этом случае выдаётся двоичное значение 1000: оно попадает в регистр W, затем в регистр M и используется следующей микрокомандой. Как видно, за одну микрокоманду CPU выполняет много действий параллельно, что повышает производительность компьютера.

Все действия микрокоманды закодированы в 90-битном слове, состоящем из 28 полей.^{(примеч. 13)} Микрокоманда, которую мы только что разобрали, с микроадресом 0220, выделена в документации ниже. Одна микрокоманда устроена очень сложно, поэтому для её представления и нужен 11-строчный текстовый блок.

Документация процессора содержит сотни страниц микрокода;^{(примеч. 16)} ниже приведена одна страница кода умножения с плавающей точкой. Каждый прямоугольник — отдельная микрокоманда, а линии между ними показывают сложные управляющие переходы. Я не буду объяснять этот микрокод,^{(примеч. 17)} но хотел показать, насколько он сложен.

Консоль

Выше мы увидели, насколько сложна внутренняя архитектура Model 50. Многочисленные лампы и органы управления на консоли^{(примеч. 19)} позволяют заглянуть в это внутреннее состояние. У консоли было три основных применения. 

Первое — базовые задачи управления оператором: включить систему, загрузить её или выключить питание с помощью органов управления в нижней части консоли. Эти элементы были одинаковыми во всей линейке S/360 и обычно были единственными, которые требовались оператору. Три шестнадцатеричных переключателя в правом нижнем углу выбирали устройство ввода-вывода, на котором находилось загрузочное ПО. После загрузки системы оператор обычно вводил команды в систему, а не работал с консолью.

Вторая функция консоли — вмешательство оператора: отладочные задачи вроде просмотра и изменения памяти или регистров и установки точек останова. Для этого использовались лампы и тумблеры в нижней половине консоли. Оператор мог ввести 24-битный адрес с помощью ряда из 24 тумблеров, а 32-битное значение данных — с помощью расположенного выше ряда из 32 тумблеров. Лампы позволяли просматривать содержимое памяти. Другими переключателями оператор мог задать точку останова, пошагово выполнить программу и выполнить другие отладочные операции.

Третья функция консоли — обслуживание и ремонт системы, которые выполнял сервисный инженер IBM. Инженерные индикаторы занимали верхнюю половину консоли и давали подробный доступ к сложному внутреннему состоянию компьютера. Чтобы сэкономить место, в Model 50 справа располагались четыре роликовых переключателя, у каждого по 8 положений. Каждое положение выбирало отдельную функцию для ряда из 36 ламп: 32 бита плюс чётность. Надписи над лампами поворачивались вместе с переключателями и показывали значение каждой лампы.

Например, в одном положении отображался регистр L, а в другом — текущая микрокоманда. На фото ниже верхний роликовый переключатель и лампы показывают часть микрокода, который выполняется прямо сейчас: ROS — это постоянная память. Роликовый переключатель ниже показывает некоторые внутренние регистры и счётчики.

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

Симулятор

Симулятор доступен по адресу righto.com/360, а код — на Github. Я реализовал симулятор на JavaScript, чтобы он мог работать в браузере. Он запускает пример программы, выполняя микрокод Model 50 и симулируя каждую микрокоманду и аппаратное обеспечение. Каждая микрокоманда отображается графически вместе с текущей командой, регистрами, локальным хранилищем и памятью на магнитных сердечниках. Симулятор точно отображает лампы консоли на основе внутреннего состояния — на масштабируемой виртуальной консоли. Каждый ряд ламп может показывать 8 разных элементов; их можно переключать щелчком по роликовому переключателю. Также можно пошагово проходить микрокод, по одной микрокоманде за раз.

Симулятор всё ещё в разработке, так что не стоит ожидать, что он будет работать идеально. Я также пока не реализовал тумблеры, поэтому ввести программу с консоли ещё нельзя. Кроме того, мне нужно реализовать систему ввода-вывода: у неё собственные регистры и другой формат микрокода.

Чтобы собрать симулятор, я извлёк двоичный микрокод из листингов с помощью собственного OCR-инструмента. Я реализовал сотни микроопераций, и добиться их корректной работы было непросто. Хотя большинство микроопераций — это простые действия вроде передачи регистра на шину, некоторые микрокоманды намного сложнее, особенно в операциях с плавающей точкой.^{(примеч. 20)} Ещё одна трудность в том, что микрокоманда выполняет много задач параллельно, и было непросто определить точный порядок, в котором их нужно симулировать.

Моя конечная цель — вывести симулятор в физический мир. В частности, я планирую управлять лампами на панели управления Model 50 у CuriousMarc, чтобы панель работала точно как настоящая. Мы также планируем подключить его ленточные накопители IBM и устройство чтения перфокарт, чтобы собрать вместе все части мейнфрейма Model 50 — кроме самого процессора. Я собираюсь портировать симулятор на C, чтобы запустить его на микроконтроллере и управлять физической консолью. Возможна и реализация на FPGA: она дала бы максимальную скорость, но была бы сложнее в разработке.ё

Примечания и ссылки (осторожно, много текста)

1. Мой симулятор вряд ли будет особенно полезен, если вам не интересен именно микрокод Model 50. Если вы хотите запускать ПО на симулируемой System/360, скорее всего, вам нужна система Hercules. 

2. Кратко перечислю несколько разных реализаций, использовавшихся в компьютерах System/360.

• Младшая Model 30 использует 8-битную шину и АЛУ, поэтому 32-битные операции выполняются за четыре шага. В ней используется 60-битный микрокод.

• Model 40 тоже имеет 8-битную шину и АЛУ, но у неё есть 16-битные регистры и 16-битная шина к памяти, что повышает производительность. В ней используется 60-битный микрокод.

• Model 50, о которой идёт речь в этой статье, имеет 32-битные регистры, шину памяти и сумматор. У неё также есть 8-битный mover, который может работать параллельно с сумматором.

• Model 65 имеет 64-битную шину и несколько сумматоров — 60-битный и 8-битный, — которые позволяют параллельно обрабатывать дробную часть и экспоненту числа с плавающей точкой. У неё также есть 8-байтный буфер команд и внешние каналы. В ней используется 100-битный микрокод.

• Model 75 имеет 64-битный основной сумматор, 8-битный сумматор экспоненты, 8-битный десятичный сумматор и 24-битный сумматор адресации. Она перекрывает выборку и выполнение команд, используя 16 байт предварительной выборки команд и 8 байт предварительной выборки данных.

• Старшая Model 91 имеет продвинутую суперскалярную архитектуру с внеочередным исполнением, конвейеризацией команд и несколькими арифметическими исполнительными блоками. Более старшие модели поддерживают чередование памяти для ускорения доступа: от 2-канального в Model 65 до 16-канального в Model 195.

• Модели 44, 75, 91 и выше использовали жёсткую управляющую логику вместо микрокода, чтобы выжать больше производительности.

Как видно, в линейке System/360 было множество разных реализаций. В младших моделях аппаратное обеспечение сводили к минимуму, чтобы снизить стоимость, а в старших добавляли больше аппаратуры для роста производительности: более широкие тракты данных и несколько функциональных блоков давали параллелизм. 

3. Линейка System/360 не полностью достигла цели совместимой архитектуры. IBM разделила бизнес- и научный рынки на младших машинах, продвигая подмножества набора команд. Базовые команды входили в «стандартный» набор команд. Поверх него десятичные команды для бизнес-задач входили в «коммерческий» набор команд, а команды с плавающей точкой — в «научный». «Универсальный» набор команд включал всё это плюс защиту памяти, то есть изоляцию памяти между программами. Кроме того, ради снижения стоимости младшая Model 20 получилась несовместимой с архитектурой S/360, а Model 44 была частично несовместимой ради более высокой производительности в научных приложениях. 

4. IBM подробно описала архитектуру System/360 в документе IBM System/360 Principles of Operation. В нём описан не только набор команд, но и типы данных, модель ввода-вывода, модель прерываний и даже базовая структура панели управления системой. Чтобы узнать о System/360 больше, см. A Programmer's Introduction to the IBM System/360 Architecture, Instructions, and Assembler Language. Много примеров на ассемблере есть на rosettacode. 

5. Главная выгода микрокода для IBM была экономической. Как описано в Microprogram Control for System/360, стоимость процессора без микрокода примерно линейно растёт с размером набора команд. У микрокодовой системы, наоборот, стоимость примерно фиксированная, а дополнительные команды добавляют лишь небольшой оверхед. Поэтому по мере усложнения наборов команд, как в System/360, наступает точка, где микрокод становится эффективнее. Особенно это заметно в младших системах, где базовая стоимость ниже. Более низкая предельная стоимость также делает эмуляцию других систем более практичной. IBM System/360 была одним из первых коммерческих компьютеров, где микрокод использовался настолько широко. 

6. Разные машины System/360 поддерживали средства совместимости с более ранними компьютерами IBM, включая 1401, 1440, 1620, 7070, 7074, 7080, 709, 7090 и 7094. Как правило, меньшая машина System/360 могла заменить меньший компьютер IBM, например 1401, тогда как крупный мейнфрейм вроде 7090 требовал замены на более крупный компьютер System/360, например Model 65. 

7. Некоторые модели System/360 не использовали микрокод. Model 44 проектировалась как высокопроизводительный компьютер для научных приложений, поэтому в ней применялась жёсткая управляющая логика. Model 85 была частично микрокодовой, а Models 75 и 91 — полностью построены на жёсткой управляющей логике. 

8. В книге IBM's 360 and Early 370 Systems подробно рассказана история S/360. IBM приводит данные по каждой модели, включая даты, ширину потока данных, время цикла, объём памяти и размер микрокода. Ещё один список с подробностями по моделям находится здесь. В статье System/360 and Beyond тоже много информации. Список моделей 360 с краткими описаниями находится здесь. О Model 50 отдельно см. руководство Functional Characteristics, руководства Field Engineering, Wikipedia, фотографии здесь и здесь, а также видео CuriousMarc.

9. Подробные размеры компонентов System/360 см. в Physical Planning Manual. Чтобы увеличить объём памяти, к Model 50 можно было добавить ещё один шкаф весом 1500 фунтов, подняв объём с 256 до 512 килобайт. Также можно было добавить до четырёх устройств Large Capacity Storage (IBM 2361), каждое из которых давало ещё по два мегабайта.

10. Я подробно писал о системе памяти на магнитных сердечниках в Model 50 здесь. 

11. Цитата взята из System/360 Model 40 comprehensive introduction.

12. Model 50 Field Engineering Diagram Manual содержит подробную схему потоков данных ниже. Эта схема соответствует схеме, которую мы обсуждали ранее, но даёт гораздо больше деталей. В частности, она показывает точную разрядность разных трактов данных и регистров.

13. В таблице ниже показано, как микрокоманда кодируется в 90-битное слово.

Биты	Имя	Значение
0	P	Чётность
1–3	LU	Левый вход mover
4–5	MV	Правый вход mover
6–11	ZP	Адрес ROAR (Read Only storage Address Register)
12–15	ZF	Управление ветвлением ROAR
16–18	ZN	Поле управления адресом
19–23	TR	Управление сумматором
24		Не используется
25–27	WS	Управление адресом локального хранилища
28–30	SF	Функции локального хранилища
31	P	Чётность
32–34	IV	Проверка недопустимой цифры
35–39	AL	Стробирование защёлки сумматора
40–43	WM	Назначение mover
44–45	UP	Функция счётчика байтов
46	MD	Управление счётчиком MD
47	LB	Управление счётчиком байтов L
48	MB	Управление счётчиком байтов M
49–51	DG	Счётчик длины
52–53	UL	Функция mover для левой цифры
54–55	UR	Функция mover для правой цифры
56	P	Чётность
57–60	CE	Поле выдачи значения
61–63	LX	Левый вход сумматора
64	TC	Управление прямым/дополненным значением
65–67	RY	Правый вход сумматора
68–71	AD	Управление функцией сумматора
72–77	AB	Управление ветвлением A
78–82	BB	Управление ветвлением B
83		Не используется
84–89	SS	Управление установкой признаков

Для канальных команд формат микрокода немного отличается, поскольку некоторые поля должны управлять схемами канала. Однако большинство полей совпадает с микрокодом CPU. В таблице ниже показан формат микрокода для канала; выделенные элементы отличаются от микрокода CPU.

Биты	Имя	Значение
0	P	Чётность
1–3	LU	Левый вход mover
4–5	MV	Правый вход mover
6–11	ZP	Адрес ROAR
12–15	ZF	Управление ветвлением ROAR
16–18	ZN	Поле управления адресом
19–23	TR	Управление сумматором
24		Не используется
25	CS	Селектор адреса локального хранилища
26–27	SA	Адрес локального хранилища
28–30	SF	Функция локального хранилища
31	P	Чётность
32–34	CT	Тактовые сигналы к каналу
35–39	AL	Стробирование защёлки сумматора
40–42	WL	Назначение mover
43–46	HC	Установка признаков мультиплексорного канала
47–48	CG	Управляющие сигналы к каналу
49–51	MG	Управление вентилями мультиплексорного канала
52–53	UL	Функция mover для левой цифры
54–55	UR	Функция mover для правой цифры
56	P	Чётность
57–60	CE	Поле выдачи значения
61–63	LX	Левый вход сумматора
64	TC	Управление прямым/дополненным значением
65–67	RY	Правый вход сумматора
68–70	CL	Проверки защёлки сумматора селекторного канала
71		Не используется
72–77	AB	Управление ветвлением A
78–82	BB	Управление ветвлением B
83		Не используется
84–89	SS	Управление установкой признаков

14. При сложении знаковых чисел в дополнительном коде переполнение возникает, если перенос из старшего бита отличается от переноса из второго по старшинству бита. Я подробно объясняю это здесь. IBM нумерует биты в слове «задом наперёд»: бит 0 — самый старший. Поэтому переполнение возникает, если результат XOR между переносом из бита 0 и переносом из бита 1 ненулевой. IBM использует символ ⩝ для обозначения исключающего ИЛИ. Поэтому CARRY(0) ⩝ CARRY(1) указывает на переполнение, которое в микрокоде представлено как BC⩝C.

15. Описание того, как работает микрокод Model 50, см. в книге Microprogramming: Principles and Practices, S. Husson (1970), стр. 295–411. На Bitsavers есть много документов по Model 50, но не всё. Если у вас есть дополнительная документация, например IBM Automated Logic Diagrams, пожалуйста, напишите мне. 

16. Листинг микрокода Model 50 доступен на Bitsavers в трёх томах. Двоичные листинги микрокода трудно читать с помощью OCR, потому что страницы печатались на разных принтерах: где-то используются шрифты с засечками, где-то — без засечек. Я сделал собственную OCR-программу, рассчитанную на обработку двоичных данных, и с её помощью в основном смог прочитать листинги. Наличие чётности в микрокоде помогало ловить ошибки. 

17. Ладно, дам краткое объяснение той страницы микрокода: это часть реализации умножения с плавающей точкой. Реализация построена на компромиссах между скоростью, длиной кода и использованием временной памяти. Идея в том, чтобы умножить множимое на множитель примерно как при умножении столбиком на бумаге: берём по одной цифре, умножаем и прибавляем частичные суммы. Этот код обрабатывает по одной шестнадцатеричной цифре множителя за раз, с отдельным случаем для каждой цифры. Множимое умножается на цифру, результат прибавляется к текущей сумме, а затем выполняется нужный сдвиг.

Чтобы ускорить работу, некоторые кратные множимого вычисляются заранее. Но предварительно вычислять 16 кратных значений, по одному на каждое значение шестнадцатеричной цифры, потребовало бы слишком много временного, то есть локального, хранилища. Поэтому заранее вычисляются только кратные 1, 2 и 6, а для остальных цифр они комбинируются. Например, чтобы умножить на цифру 7, складываются кратные для 1 и 6. Чтобы умножить на цифру 4, прибавляется кратное для 6 и вычитается кратное для 2.

А что делать с умножением на цифры от 9 до 15? Хитрость в том, чтобы «занять» 16 из следующей старшей цифры. Например, чтобы умножить на цифру 11, нужно занять 16, вычесть кратное для 6 и прибавить кратное для 1. Затем для следующей цифры используется значение на единицу меньше, чтобы учесть заём. Так все 16 вариантов можно обработать, прибавляя или вычитая не более двух заранее вычисленных значений. С учётом займа код должен обработать 32 случая; приведённая страница реализует 22 из них. Такая реализация делает умножение быстрым, но микрокод получается сложным, с множеством путей выполнения. Кроме того, есть ещё немало кода для обработки экспоненты числа с плавающей точкой, нормализации значений, переполнения, потери значимости и так далее.

18. Разные модели System/360 использовали разные способы хранения микрокода.(примеч. 18) Важная особенность хранилища микрокода IBM состояла в том, что микрокод можно было заменить на месте эксплуатации. В младшей Model 25 микрокод хранился в 16-килобайтной области памяти на магнитных сердечниках под названием Control Storage. В Model 30 использовалась CCROS (Card Capacitor Read-only Store): микрокод хранился на специальных металлизированных перфокартах, которые считывались ёмкостным способом. Transformer Read-Only Storage (TROS, ниже) использовалась в System/360 Model 20 и Model 40.  

Model 50, а также 65 и 67, хранили микрокод в BCROS (Balanced Capacitor Read-Only Storage), используя платы из стеклотекстолита с медным покрытием размером 20″ × 8½″. Каждая листовая плоскость содержала 176 слов по 100 бит, а Model 50 использовала 16 листов для хранения 2816 слов. Из 100 бит в каждом слове использовались только 90. Данные в BCROS были вытравлены в медной разводке, показано ниже. Каждый бит представлен двумя квадратами: один соединён с верхним проводником, другой — с нижним, или наоборот, образуя сбалансированные конденсаторы. 

19. Возможности панели управления системой были тщательно определены в System/360 Principles of Operation, стр. 117–121, что обеспечивало единый операторский опыт во всей линейке S/360. При этом инженерная часть панели, предназначенная для сервисного обслуживания, не специфицировалась и сильно отличалась в разных моделях линейки. Схемы консолей S/360 есть на quadibloc.

20. Микрооперация, доставившая мне больше всего трудностей, — ED*FP: она вычисляет разность двух экспонент для чисел с плавающей точкой, но также вычисляет четыре флага с плавающей точкой, включая знак, в зависимости от типа операции. Эта операция не только сложная; я ещё и думаю, что в её описании есть опечатка. 

Ещё одна сложная микрооперация — MLJK: она выполняет несколько действий при декодировании команды:

• Передать защёлку сумматора в регистр L и регистр M. Передать биты защёлки 12–15 в регистр J. Передать биты защёлки 16–19 в счётчик MD. Сбросить признак повторной выборки.

• Если биты защёлки 12–15 все равны нулю, установить признак 0. Иначе сбросить признак 0.

• Если биты защёлки 16–19 все равны нулю, установить признак 1. Иначе сбросить признак 1.

• Если биты защёлки 16–17 все равны нулю, установить признак однослоговой команды. Иначе сбросить признак однослоговой команды.

• Если биты защёлки 0–1 равны 00, установить ILC в 01.

• Если биты защёлки 0–1 равны 01 или 10, установить ILC в 10.

• Если биты защёлки 0–1 равны 11, установить ILC в 11. 

Чтобы продолжить тему микрокода и посмотреть, как похожие идеи реализованы уже на уровне микропроцессоров, можно перейти к разборам Intel 8086 и 8087.

• Внутри Intel 8086: как микрокод управляет АЛУ

• Как работает движок микрокода процессора 8086

• Два бита на транзистор: ПЗУ микрокода повышенной плотности в FPU-сопроцессоре Intel 8087