Comments 9
Момент обновления значения интервального таймера ни в Системе 360, ни в Системе 370 не регламентирован, но большинство машин выполняет его в промежутке между завершением одной команды и началом выполнения следующей.
Он отчасти регламентируется: в архитектуре упоминается, что в процессе выполнения команды невозможно получить несогласованное значение таймера. Самый простой способ выполнить это требование - как раз выполнять обновление в промежутке между командами.
Ну, это обычное атомарное обращение к области памяти, выровненной должным образом (интервальный таймер -- слово и находится на границе слова), т.е. сие относится не к таймеру как к таковому, а к любому выровненному слову, участвующему в некоей операции. Но самый простой -- да, обновлять между командами.
Операции беззнакового сравнения CL, CLR выполняются не на основном сумматоре, а побайтно в узле обработки байтов.
Хм. Про AL(R), SL(R) ничего не сказано, но они делаются тоже побайтно? А почему так для них всех? Там только финальный вывод с кодами условий другой.
Кроме того, анализируется старший (не знаковый) разряд делимого. Если он значащий (отличается от знака делимого), сразу фиксируется переполнение.
Не сразу понял смысл этого трюка:) но таки да, при знаковых операндах это корректно.
Вообще, что чуть менее чем всё выполнялось на микрокомандах, с современной точки зрения слегка так неожиданно. (Ну да, причины понятны, но надо привыкнуть...)
В описании операций с плавающей точкой нет подробностей по округлению, какие алгоритмы использовались. Я читал (в слишком скудном описании), что IBM в 68-м отзывала на переделку 360ки, добавляя guard bit в случае двойной точности (то есть при одинарной он уже был?), значит, двухбитовая схема уже применялась? Но данных что-то маловато.
В описании операций с плавающей точкой нет подробностей по округлению, какие алгоритмы использовались.
Подробнее описание алгоритмов с плавающей точкой приводится в описании архитектуры (называется System/360 Principles of Operation, для System/370 тоже). По сути, от современной "плавучки" отличий два:
Порядок числа выражается в шестнадцатеричных цифрах, а не в двоичных. Т.е. сдвиги при выравнивании и нормализации выполняются по 4 бита.
Нет нечисел (NaN)
IBM в 68-м отзывала на переделку 360ки, добавляя guard bit в случае двойной точности (то есть при одинарной он уже был?), значит, двухбитовая схема уже применялась?
Guard digit, т.е. 4 бита. Да, в первом издании Principles of Operation указано, что промежуточные результаты для одинарной точности 7 цифр (6 плюс защитная), а для двойной всегда 14 цифр без защитной цифры, а в издании 1968 г. защитная цифра применяется в обоих форматах.
Principles of Operation
Про этот документ я хорошо в курсе, но данных там IMHO недостаточно, или я чего-то недопонимаю. В реализации для IEEE binary (можно смотреть легкопонятный и эффективный вариант, например, в berkeley-softfloat) там, где сдвиг вправо числа с меньшим порядком, используется так называемый jamming shift, который выполняет, по сути, округление до нечётного, в пределах дополнительных битов. В описании IBM ничего такого не сказано, и возникает вопрос на подумать.
Пусть у нас до сдвига второго слагаемого он заканчивается на 0x9123F сам по себе, и 0x9124F_0, если считать с той самой guard digit. Теперь за счёт разницы 2 между порядками надо сдвинуть вправо на 2 цифры. Что получится - 0x912_4 (где 4 это guard digit) или 0x912_5? Куда округлится за счёт этого F, вылетевшего за пределы даже guard digit?
Аналогичные процедуры для IEEE754, как уже сказал, округляют цифры до нечётного. Для HFP тут я бы ожидал корректировку вверх. Раз ничего не сказано, я бы предположил, что корректировки не происходит и реально выполняется как усечение к нулю, но есть таки сомнения. (Хм, перечитал версию для Z. Для BFP и DFP описано управление округлением. Для HFP ни слова и суть текста такая же как для 360... что, только усечение?)
И, далее, guard digit для чего именно используется? Я не вижу, чтобы описывалось округление на основании её значения (типа, >=0x8 - округляем вверх). Такое впечатление, что она нужна только для того, чтобы при вычитании, когда нормализованный порядок падает и значение надо сдвигать влево, она входила в сохраняемую часть.
По сути, от современной "плавучки" отличий два:
В том и дело, что для современной (подразумеваем IEEE754) сохранение данных для правильного округления, и дальше само округление, является критичным для корректности операций. Это и для BFP (IEEE754 binary), и для DFP (IEEE754 decimal - которую IBM зачем-то воплотила в железе).
а в издании 1968 г. защитная цифра применяется в обоих форматах.
Угу, сравнил версии 0 и 7 (декабрь 67; 68го у меня нет под рукой) - в декабре 67 уже сказано про "15 цифр, из которых одна guard". Спасибо, я не догадался посмотреть раньше. Всё равно с современной точки зрения это примитив... а вот исторически очень ценное свидетельство.
В описании IBM ничего такого не сказано, и возникает вопрос на подумать.
Потому и не сказано, что там банальный сдвиг безо всяких округлений:
the fraction with the smaller characteristic is rightshifted; its characteristic is increased by one for each hexadecimal digit of shift
Что получится - 0x912_4 (где 4 это guard digit) или 0x912_5? Куда округлится за счёт этого F, вылетевшего за пределы даже guard digit?
Первый вариант. Цифра F вылетела и пропала, и в промежуточном представлении останется четвёрка. Примеры приводятся в конце описания. Можно ещё заглянуть в описание System/370, там подробнее разжёвано.
И, далее, guard digit для чего именно используется?
Такое впечатление, что она нужна только для того, чтобы при вычитании, когда нормализованный порядок падает и значение надо сдвигать влево, она входила в сохраняемую часть.
Верно, так и есть. Вместо округления пытаемся сохранить на одну значащую цифру побольше.
В том и дело, что для современной (подразумеваем IEEE754) сохранение данных для правильного округления, и дальше само округление, является критичным для корректности операций.
Окей, буду знать теперь, что между ними есть ещё одно существенное различие.
сравнил версии 0 и 7 (декабрь 67; 68го у меня нет под рукой)
На самом деле есть. ;) На bitsavers в названии файла почему-то прописана версия 7 и дата Dec67, хотя если взглянуть на вторую страницу, там:
EIGHTH EDITION (September, 1968)
Да, в первом издании 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, она была таки быстрой машиной, а пользователю-то всё равно, что у неё "под капотом").
Процессор ЭВМ ЕС-1030. Особенности микропрограмм