Commercial Instruction Set (CIS) на PDP-11 и я

[Hunta]

"Под руководством Дика Брауна (если я правильно помню) в разработке был PDP-11 с добавленной к 11/70 функциональностью CIS и обновлениями процессора - то, что тогда называлось 11/74. Некоторые изменения в микрокоде процессора для поддержки выполнения инструкций CIS и поддержки связи с четырьмя CIS процессорами. Изменения в корзине 11/70. Изменения в нескольких модулях процессора (немного и несложные).


К сожалению, документ, на который я ссылался, о различиях KB11-E, выглядит неполным. В нем перечислены основные сведения, но отсутствуют главы, в которых описывается корзина и список модулей. Было бы интересно иметь и их.


Я знаю, что видел списки того, какие модули были изменены/отличались для KB11-CM, и я думаю, что даже читал, что некоторые из них были распространёнными, потому что их можно было использовать в любом 11/70.


В какой-то момент обновление микрокода ЦП для ASRB также было встроено в ЦП 11/74, что сделало его совместимым с мультипроцессорностью.


Обратите внимание - то же верно и для и J-11.


У меня даже есть оргстекло обновлённой передней панели 11/74, который я «присвоил», когда 11/74 был отменен. Скан:


https://www.ak6dn.com/stuff/1174.jpg


В конечном итоге отдел маркетинга DEC отменил 11/74 с CIS. На протяжении многих лет приводилось много аргументы и оправданий относительно того, почему в точности это произошло, но моё общение с отделом маркетинга в то время говорит о том, что при тестировании производительности программ на Cobol PDP-11/74 с CIS значительно превзошёл по производительности VAX 11/780 (который только что был выпущен). Таким образом, у маркетинга возникла проблема с позиционированием, и решение состояло в том, чтобы отменить 11/74 в пользу продвижения семейства 11/780 для устранения этой проблемы. Бесспорно - мудрое решение в то время, как VAX должен был стать будущем DEC. По крайней мере, до Альфы ..."

[litwr]

Не факт. Потому что BCD - он почти готов к вводу/вывода (в случае ASCII), а двоичные - ещё надо перевести из строки в двоичное представление и обратно)
Пример https://zx-pk.ru/threads/32126-comme...=1#post1076627 это наглядно показывает - берём строку в ASCII, умножаем на строку в ASCII, получаем строку в ASCII, которую сразу печатаем. Никаких преобразования. Ну и в CIS, насколько я помню, были строковые команды перевода из ASCII в BCD и обратно

Кстати, теперь я могу попробовать CIS с Коболом под RSX, так как и для KDF доступно 4 (чуть не написал гига) мегабайта памяти – то есть без проблем загрузится RSX-Plus

Понятно, что на переводе в десятичные экономим, но расчеты с двоичными быстрее (на мейнфрейме IBM 4361-1 бинарное сложение раза в полтора быстрее десятичного) и вывод нужен гораздо реже чем сложение и другие арифметические операции. Кроме того, при выводе всё равно много тратится циклов на взаимодействие с системой и выигрыш от отсутствия преобразования из двоичных будет скорее незначителен на их фоне. Поэтому от поддержки BCD и отказались Intel и Motorola, a ARM и прочие RISC не имели её изначально. В самых массовых системах на основе 6502 Nintendo десятичный режим также аппаратно вырезался. DEC возможно показала правильное предвидение и не добавляла поддержки BCD в основной набор инструкций, хотя возможно они просто копировали подход мейнфреймов IBM. Но в итоге DEC отказалась от поддержки BCD наверное раньше всех. Интересно, была ли ещё поддержка CIS где-нибудь ещё на машинах более поздних чем 11/23+?
Интересно также, была ли реализована эмуляция CIS типа эмуляторов EIS?
Мне нравится кобол, так как он совершенно специальным образом может работать с числами, которые задаются не типами, а "картинками", где задается число знаков, позиция десятичной точки, позиция знака и т.п. Это какой-то PRINT USING из древнего бейсика, но формат числа поддерживается сквозь все вычисления! А сегодня в современных языках уже просто "из коробки" знак числа в его конце или разделение на тысячи не напечатаешь - даже современные бейсики уже не поддерживают PRINT USING. На коболе люди и сегодня зарабатывают. Сам бы хотел что-нибудь на коболе написать - очень необычный язык, когда-то в СССР немалые средства потратили на его полную русификацию для клонов мейнфреймов.

В конечном итоге отдел маркетинга DEC отменил 11/74 с CIS. На протяжении многих лет приводилось много аргументы и оправданий относительно того, почему в точности это произошло, но моё общение с отделом маркетинга в то время говорит о том, что при тестировании производительности программ на Cobol PDP-11/74 с CIS значительно превзошёл по производительности VAX 11/780 (который только что был выпущен). Таким образом, у маркетинга возникла проблема с позиционированием, и решение состояло в том, чтобы отменить 11/74 в пользу продвижения семейства 11/780 для устранения этой проблемы. Бесспорно - мудрое решение в то время, как VAX должен был стать будущем DEC. По крайней мере, до Альфы ..."

Какая-то логика лузеров. Когда в Интел протестировали своё будущее iAPX 432 и, как тогда казалось процессор из временного ряда полуконтроллеров 8086, 80286, и обнаружили, что 80286 значительно быстрее, они просто переключились на новое будущее, а iAPX 432, несмотря на огромные на него затраты, забыли. C Ваксами много всего странного связано.

[Hunta]

но расчеты с двоичными быстрее

Ну и попробуйте умножить 123456789012345 на 234567890123456, с переводом из строковое в двоичное и обратно - и сравним скорость.

Какая-то логика лузеров.

Сказал человек, живущей через 40 лет после того принятия решения.

[Alex]

Раньше задачи были другие
Больше ввода-вывода, меньше расчётов. Процессоры считали медленнее. Была экономия.
А на счёт интела не правы... На x-86 есть символьная арифметика. Она по сравнению с прочими порезана, скорее обходная но:
AAA
AAD
AAM
AAS

[litwr]

Ну и попробуйте умножить 123456789012345 на 234567890123456, с переводом из строковое в двоичное и обратно - и сравним скорость.

Если работать в режиме калькулятора, то, конечно, BCD быстрее. Но если работаем в режиме компьютера, например, нужно сложить 1000 чисел и напечатать сумму, то BCD будет большим тормозом.

[yu.zxpk]

в "больших" СУБД, как то Oracle, для хранения финансовых данных и расчетов используется BCD (NUMERIC формат данных, MONEY), а не float-point. Нужно ли объяснять причину такого решения?

[Hunta]

Нужно ли объяснять причину такого решения?

Причина - в точности вычисления. Двоичные данные с плавающей точкой - приблизительны. Я уже приводил выше пример. В случае BCD будут точные данные.

BCD будет большим тормозом.

У вас опять тон абсолютного авторитета, а вы, уверен, никогда и не имели возможности поработать с CIS.

Ля ля ля ля ля ля ля. Про ваши предположения уже давно известно что они только ваши предположения.

[Vslav]

Причина - в точности вычисления. Двоичные данные с плавающей точкой - приблизительны. Я уже приводил выше пример. В случае BCD будут точные данные.

Маловероятно. Обычные целые в дополнительном коде обеспечат такую же точность плюс процентов на 20 займут меньше памяти, ну и арифметические операции будут быстрее. ИМХО, единственное преимущество BCD это быстрый вывод в десятичной форме очень длинных чисел.

[yu.zxpk]

Маловероятно. Обычные целые в дополнительном коде обеспечат такую же точность плюс процентов на 20 займут меньше памяти, ну и арифметические операции будут быстрее. ИМХО, единственное преимущество BCD это быстрый вывод в десятичной форме очень длинных чисел.

100% - проблема точности при работе с дробными, невозможности точно представить дроби с базой 10 в виде дробей с базой 2.

[Hunta]

Обычные целые в дополнительном коде обеспечат такую же точность

Во первых, я имел ввиду представление с плавающей точкой. Во вторых, речь идёт о временах, когда и 32 бита - это было много. 16 десятичных цифр - это сколько будет бит? А 31 десятичная цифра? А реализация умножения деления с числами с таким количеством бит?

единственное преимущество BCD это быстрый вывод в десятичной форме очень длинных чисел.

Как раз это - не основное, хотя и хорошее преимущество для финансовых операций, в которых вычислений не много

- - - Добавлено - - -

Классический пример про точность с плавающей точкой и точностью.

            int i = 0;
            double r = 0.0;
            while (r != 1.0)
            {
                Console.WriteLine(r);
                r = r + 0.1;
                i++;
                if (i > 100) return;
            }

0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
1,1
1,2
1,3
1,4
1,5
1,6
1,7
1,8
1,9
2
2,1
2,2
2,3
2,4
2,5
2,6
2,7
2,8
2,9
3
3,1
3,2
3,3
3,4
3,5
3,6
3,7
3,8
3,9
4
4,1
4,2
4,3
4,4
4,5
4,6
4,7
4,8
4,9
5
5,1
5,2
5,3
5,4
5,5
5,6
5,7
5,8
5,9
5,99999999999999
6,09999999999999
6,19999999999999
6,29999999999999
6,39999999999999
6,49999999999999
6,59999999999999
6,69999999999999
6,79999999999999
6,89999999999999
6,99999999999999
7,09999999999999
7,19999999999999
7,29999999999999
7,39999999999999
7,49999999999999
7,59999999999999
7,69999999999999
7,79999999999999
7,89999999999999
7,99999999999999
8,09999999999999
8,19999999999999
8,29999999999999
8,39999999999999
8,49999999999999
8,59999999999999
8,69999999999999
8,79999999999998
8,89999999999998
8,99999999999998
9,09999999999998
9,19999999999998
9,29999999999998
9,39999999999998
9,49999999999998
9,59999999999998
9,69999999999998
9,79999999999998
9,89999999999998
9,99999999999998
10,1
10,2
10,3
10,4
10,5
10,6
10,7
10,8
10,9
11
11,1
11,2
11,3
11,4
11,5
11,6
11,7
11,8
11,9
12
12,1
12,2
12,3
12,4
12,5
12,6
12,7
12,8
12,9
13
13,1
13,2
13,3
13,4
13,5
13,6
13,7
13,8
13,9
14
14,1
14,2
14,3
14,4
14,5
14,6
14,7
14,8
14,9
15
15,1
15,2
15,3
15,4
15,5
15,6
15,7
15,8
15,9
16
16,1
16,2
16,3
16,4
16,5
16,6
16,7
16,8
16,9
17
17,1
17,2
17,3
17,4
17,5
17,6
17,7
17,8
17,9
18
18,1
18,2
18,3
18,4
18,5
18,6
18,7
18,8
18,9
19
19,1
19,2
19,3
19,4
19,5
19,6
19,7
19,8
19,9
20