Просмотр полной версии : Commercial Instruction Set (CIS) на PDP-11 и я
Приехал мне один интересный аддон для KDF11-B. И если его вставить куда надо, то можно увидеть:
RT-11SB V05.07
.R MSCPCK
.SHO CONF
RT-11SB V05.07
Booted from DU2:RT11SB
USR is set SWAP
EXIT is set SWAP
KMON is set NOIND
MODE is set NOSJ
TT is set NOQUIET
ERROR is set ERROR
SL is set OFF
EDIT is set KED
FORTRAN is set FORTRA
KMON nesting depth is 3
CLI is set DCL, CCL, UCL, NO UCF
PDP 11/23 PLUS Processor
256KB of memory
FP11 Hardware Floating Point Unit
Extended Instruction Set (EIS)
Commercial Instruction Set (CIS)
Memory Management Unit
Parity Memory
60 Hertz System Clock
FPU support
.TYP HX7:TEST.MAC
.TITLE TEST
.MCALL .EXIT, .PRINT
START:
MOV N1DSC, R0
MOV N1DSC+2, R1
MOV N2DSC, R2
MOV N2DSC+2, R3
MOV N3DSC, R4
MOV N3DSC+2, R5
ADDN ; !!!!!!!!!!
BIT #37, N3DSC
BEQ 100$
.PRINT #NUM3
BR 300$
100$:
.PRINT #ERR
300$:
.EXIT
N1DSC:
.WORD 50000+NUM1L, NUM1
N2DSC:
.WORD 50000+NUM2L, NUM2
N3DSC:
.WORD 50000+5., NUM3
NUM1: .ASCII /+12345/
NUM1L=.-NUM1
NUM2: .ASCII /+23456/
NUM2L=.-NUM2
NUM3:
.BLKB 32.
NUM3L=.-NUM3
.BYTE 0
ERR: .ASCIZ /Error/
.EVEN
.END START
.LOA HX7:
.EXE HX7:TEST
35801
Поскольку набор команд CIS окружён прямо таки мистическим ореолом и достаточно слабо освещён в документации и поскольку у меня есть, на ком и на чём его помучить, решил завести про него отдельную тему.
Процессора PDP-11, на которых он есть, думаю можно посчитать пальцами одной руки. Но с учётом того, что Vslav собирается вскрыть и набор F-11 (1811) - возможно удастся вычитать и микросхемы микрокода CIS и реализовать его в будущем FPGA варианте F-11. У меня (пока?) только одна микросборка, реализующая этот набор и я не готов её жертвовать для деструктивного считывания
Учитывая интересы сообщества любителей DEC - сомневаюсь, что кто то ещё, кроме меня, будет развлекаться с этим набором команд, но я могу предоставить удалённый доступ к стенду с процессором, где есть эти команды, так что если (вдруг) желающие найдутся - можно договориться - когда и насколько :)
Ещё информация.
"Сообщается, что коммерческий набор команд KEV11-C (документация по нему невозможно найти) является дополнительным чипом для набора микросхем LSI-11, который добавляет поддержку подмножества CIS, иногда известного как DIS (набор команд DIBOL).
Он также включает в себя EIS (но не FIS).
DIS не может использоваться с микросхемой с плавающей запятой KEV11-A не только из-за ограниченного количества сокетов uROM на платах ЦП LSI-11, но также потому, что DIS и базовый набор команд вместе используют все адресное пространство uROM.
DIS стал стандартом в некоторых коммерчески ориентированных системах LSI-11; процессоры KD11-P и KD11-Q (M7264-BB и M7264-YB соответственно) являются моделями ЦП с установленным KEV11-C.
Варианты чипа
KEV11-C использует два uROM: 3025D 23-004B5 и 3026D (возможно B?) 23-005B5. (Также может быть гибридная версия KEV11-C, то есть с одной несущей DIP, но номер детали неизвестен.)
Версия опции KEV11-C с двумя uROM, очевидно, занимает два гнезда uROM; поэтому он используется с 40-контактным гибридом (два чипа на одном носителе), который содержит два uROM базового набора команд. Гибрид - 23-001B6, 23-002B6 или 23-003B6 (для M7264 ECO 10, ECO 12 и ECO 16 соответственно)."
Поигрался малость с CIS. Не такие уж они сложные оказались, эти команды.
Попробую написать тесты на их скорострельность :)
- - - Добавлено - - -
Как выглядит KDF11-B с полным комплектом микросхем (http://www.KpXX.Ru/DEC/PDP-11/Hardware/KDF11-B/KDF11-B-Front.JPG)
- - - Добавлено - - -
Слегка причёсанный пример CIS
.TYP TEST.MAC
.TITLE TEST
.MCALL .EXIT, .PRINT
.MACRO SZ$NUM LABEL, VAL, ?L1, ?L2
LABEL:
.WORD 50000+L2-L1-1 ; 50000 - signed zoned numeric
.WORD L1+1
L1:
.ASCII \VAL\
L2:
.BYTE 0
.EVEN
.ENDM SZ$NUM
.MACRO SZ$PRINT LABEL
MOV LABEL+2, R0
DEC R0
.PRINT
.ENDM SZ$PRINT
START:
ADDNI
N1DSC, N2DSC, N3DSC
SZ$PRINT N1DSC
SZ$PRINT N2DSC
SZ$PRINT N3DSC
.EXIT
SZ$NUM N1DSC <+12345>
SZ$NUM N2DSC <+23456>
SZ$NUM N3DSC <+00000>
.EVEN
.END START
.EXE TEST
+12345
+23456
+35801
.
Zoned формат поддался быстро, packed формат чёт пока сопротивляется...
- - - Добавлено - - -
Хе хе :) Тупая ошибка, которые я плохо нахожу :) Точнее - долго могу искать, но всё остальное было правильным :)
Итак, как умножить 123456789012345 на 234567890123456 на PDP-11 одной (!) командой и, после ещё одной (!) команды, сразу вывести результат на монитор :D
.TYP TEST.MAC
.TITLE TEST
.MCALL .EXIT, .PRINT
.MACRO SZ$NUM LABEL, VAL, ?L1, ?L2
LABEL:
.WORD 50000+L2-L1-1 ; 50000 - signed zoned numeric
.WORD L1+1
L1:
.ASCII \VAL\
L2:
.BYTE 0
.EVEN
.ENDM SZ$NUM
.MACRO SZ$PRINT LABEL
MOV LABEL+2, R0
DEC R0
.PRINT
.ENDM SZ$PRINT
START:
ADDNI
N1DSC, N2DSC, N3DSC
SZ$PRINT N1DSC
SZ$PRINT N2DSC
SZ$PRINT N3DSC
CVTNPI ; numeric to packed
N4DSC, BUF1
CVTNPI ; numeric to packed
N5DSC, BUF2
MULPI ; multiply packed
BUF1, BUF2, BUF3
CVTPNI ; packed to numeric
BUF3, N6DSC
SZ$PRINT N4DSC
SZ$PRINT N5DSC
SZ$PRINT N6DSC
.EXIT
SZ$NUM N1DSC <+12345>
SZ$NUM N2DSC <+23456>
SZ$NUM N3DSC <+00000>
SZ$NUM N4DSC <+123456789012345>
SZ$NUM N5DSC <+234567890123456>
SZ$NUM N6DSC <+000000000000000000000000000000>
BUF1: .WORD 60000+31.
.WORD ADDR1
BUF2: .WORD 60000+31.
.WORD ADDR2
BUF3: .WORD 60000+31.
.WORD ADDR3
ADDR1: .BLKB 32./2
ADDR2: .BLKB 32./2
ADDR3: .BLKB 32./2
.EVEN
.END START
.EXE TEST
+12345
+23456
+35801
+123456789012345
+234567890123456
+028958998520042431946358064320
.
Третье число - результат сложения первых двух чисел (в ASCII формате, без преобразования (!))
Шестое число - результат умножение четвёртого числа на пятое (преобразования - ровно три машинных команды)
Проверил результат на калькуляторе Windows, он сказал, что должно быть - 28958998520042431946358064320
Вот прям жутко интересно - какая же скорострельность этих команд :) Надо писать тест :)
- - - Добавлено - - -
Блин, жалко, что DEC так и не допилила, похоже, до результата, ещё пару микросхем для J-11. И ведь даже место есть!
Но теперь никто не мешает восстановить эту несправедливость для новодельных процессоров семейства PDP-11 :)
- - - Добавлено - - -
Память подсказывает, что вроде не один раз попадалась мне инфа, что этот набор (CIS) DEC делала с прицелом Кобол и свои компиляторы с Кобола.
И что вроде только компилятор с Кобола умеет генерить код под них.
Если так, что этот набор вполне можно назвать Cobol Instruction Set :)
Надо посмотреть, есть ли в принципе компилятор с Кобола для RT - в коллекции у меня есть только компиляторы под RSX и RSTS-E. Первая у меня есть только в PLUS варианте (а на 256 кб она не взлетает - уже попробовал), а по RSTS-E я не знаток. Так что пока - не проверить :)
Кстати, попадалась информация об ещё одном (не шибко распространённом) наборе команд процессоре PDP-11 - DIS, который реализует KEV11-CA (23-004B5 и 23-005B5) DIBOL chip set. Который ставится в LSI-11 :) Пока он мне не попадался...
- - - Добавлено - - -
В Software Product Description на те версии Кобола, которые у меня есть - ни слова про RT-11. Похоже, компиляторов под RT у DEC не было...
Первый вариант программы вычисления быстродействия с прицелом на CIS
.SPEED3
ТЕСТ БЫСТРОДЕЙСТВИЯ
R1 + R0
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК) 533
R1 + @R0
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК) 332
R0 * R0
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК) 41
R2 / R0
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК) 130
CIS MULI
БЫСТРОДЕЙСТВИЕ (ТЫС.ОП./СЕК) 8
.
Команда тестирования CIS - взята из демо-теста - MULPI +123456789012345 на +234567890123456
Щас попробую на более мелком умножении
- - - Добавлено - - -
То ли в опубликованном варианте напортачил, то ли в новом, но... сейчас кажет не 8, а 32 тысячи оп/с
- - - Добавлено - - -
Малость подправил программы в плане того, как делается вывод:
.RUN SPEED3
Тест быстродействия
R1+R0 13217 тыс. оп./сек
R1+@R0 12716 тыс. оп./сек
R0*R0 17681 тыс. оп./сек
R2/R0 16424 тыс. оп./сек
CIS MULPI 1 - команда не реализована
CIS MULPI 2 - команда не реализована
.
- - - Добавлено - - -
Новый результат с KDF11-B
.SPEED3
Тест быстродействия
R1+R0 533 тыс. оп./сек
R1+@R0 332 тыс. оп./сек
R0*R0 41 тыс. оп./сек
R2/R0 130 тыс. оп./сек
CIS MULPI 1 32 тыс. оп./сек
CIS MULPI 2 32 тыс. оп./сек
.
- - - Добавлено - - -
Буду ещё думать :)
Как и скребло подсознание - что то тут не так с последним вариантом программы и последними результатами соответственно :)
Видимо, уже был сонным и посадил ошибку :)
С утра увидел и поправил.
Новый (думаю, теперь более правильный - буду ещё думать с методикой подсчёты быстродействия) результат:
.RUN SPEED3
Тест быстродействия
R1+R0 533 тыс. оп./сек
R1+@R0 332 тыс. оп./сек
R0*R0 41 тыс. оп./сек
R2/R0 130 тыс. оп./сек
CIS MULPI 1 8 тыс. оп./сек
CIS MULPI 2 32 тыс. оп./сек
CIS ADDNI 1 52 тыс. оп./сек
CIS ADDNI 2 104 тыс. оп./сек
.
Первый MULPI - это вычисление (+123456789012345) * (+234567890123456)
Второй MULPI - (+11) * (+12)
Первый ADDNI - (+123456789012345) + (+234567890123456)
Второй ADDNI - (+11) + (+12)
Как я и предполагал, должна быть зависимость от длины операндов - а не одинаково, как в предыдущем сообщении.
Скорее всего позже добавлю ещё тестов CIS с разной длиной операндов.
Всё таки напортачил ещё в одном месте. Надо было делить, а я умножил. Так что старые результаты по CIS по прежнему не верны.
Новые данные (и вроде корректные :D )
.RUN SPEED3
Тест быстродействия
R1+R0 533 тыс. оп./сек
R1+@R0 332 тыс. оп./сек
R0*R0 41 тыс. оп./сек
R2/R0 130 тыс. оп./сек
CIS MULPI 1 0,5 тыс. оп./сек
CIS MULPI 2 2 тыс. оп./сек
CIS ADDNI 1 3,25 тыс. оп./сек
CIS ADDNI 2 6,5 тыс. оп./сек
MOV 8 word 1 7,75 тыс. оп./сек
MOV 8 word 2 9,22 тыс. оп./сек
.
Ну, если не насажал опять ошибок, то вот как то так:
.RUN SPEED3
Тест быстродействия
R1+R0 532 554 оп./сек
R1+@R0 331 706 оп./сек
R0*R0 40 784 оп./сек
R2/R0 130 207 оп./сек
CIS MULPI 1 432 оп./сек
CIS MULPI 2 2 005 оп./сек
CIS ADDNI 1 3 145 оп./сек
CIS ADDNI 2 6 496 оп./сек
MOV 8 word 1 7 736 оп./сек
MOV 8 word 2 9 205 оп./сек
.
Как оказалось, DIS - это подмножество CIS. Добавил информацию в первое сообщение.
Обновлённый вариант программы (в чём отличие - Пост 104 (https://zx-pk.ru/threads/31998-dec-i-ya.html?p=1077073&viewfull=1#post1077073)):
.RUN SPEED3
Тест быстродействия
R1+R0 classic 531 272 оп./сек
R1(23456.)+R0(12345.) empty 165 729 оп./сек
R1(23456.)+R0(12345.) 126 598 оп./сек ; 536 172
R1+@R0 classic 331 022 оп./сек
R1(23456.)+@R0(M-12345.) empty 165 728 оп./сек
R1(23456.)+@R0(M-12345.) 110 531 оп./сек ; 331 867
R0*R0 classic 40 764 оп./сек
empty 11.*12. 165 722 оп./сек
11.*12. 32 670 оп./сек ; 40 692
R2/R0 classic 140 979 оп./сек
R2-R3(34567.)/R1(321.) empty 126 606 оп./сек
R2-R3(34567.)/R1(321.) 20 122 оп./сек ; 23 924
CIS MULPI 1 432 оп./сек
CIS MULP 1 empty 57 081 оп./сек
CIS MULP 1 459 оп./сек ; 463
CIS MULPI 2 2 005 оп./сек
CIS MULP 2 empty 57 078 оп./сек
CIS MULP 2 2 459 оп./сек ; 2 570
CIS ADDNI 1 3 145 оп./сек
CIS ADDN 1 518 оп./сек
CIS ADDNI 2 6 496 оп./сек
CIS ADDN 2 2 563 оп./сек
MOV 8 word 1 14 503 оп./сек
MOV 8 word 2 17 002 оп./сек
CIS MOV 8 word 1 14 015 оп./сек
.
Последние три тесты - это сравнение классического цикла на SOB и команды MOVC (пересылка строки символов) CIS
ACTION <<CR><LF>\MOV 8 word 1\>
LET R0 := #ABUF01
LET R1 := #ABUF02
THRU R2 := #<ABUF02-ABUF01>/2
LET (R1)+ := (R0)+
END
ACTION <<CR><LF>\MOV 8 word 2\>
LET R0 := #ABUF01
LET R1 := #ABUF02
THRU R2 := #<ABUF02-ABUF01>/4
LET (R1)+ := (R0)+
LET (R1)+ := (R0)+
END
ACTION <<CR><LF>\CIS MOV 8 word 1\>
MOVCI
MBUF01, MBUF02, SPACE
8 и 9 слов против 4-ых. Надо будет увеличить длину строки с 16-ти символов на побольше :)
Вот блин :) Память мне упорно подсказывала, что в MACRO-11 есть директива .PACKED :)
И точно - полез в документацию - есть такая :)
748 000046 022 064 126 .PACKED +123456789012345, P01LEN
000051 170 220 022
000054 064 134
749
750 000056 D01:
751 000056 060017 .WORD 60000+P01LEN
752 000060 000046' .WORD P01VAL
А вот LINK отказался собирать такую программу :D Или я что то не так делаю :)
Очень похожие на CIS инструкции есть в х-86. Я ранее думал, для чего их впихнули??? Однако ветер дул в том числе от DEC :)
Возможно в Воронеже и были прошивки с CIS для F-11... Но в массы не пошло.
И вопрос-вопросов, был ли CIS для J-11?
SuperMax
18.08.2020, 17:18
ну CIS появились еще во времена IBM360 и DEC их впихнул именно для поддержки бизнес-приложений
собственно Oracle2 как раз на PDP-11 и работал и явно использовал CIS
И вопрос-вопросов, был ли CIS для J-11?
Пока есть только один факт, не требующий подтверждения - на обратной стороне подложки J-11 есть контакты для подключения ещё пары микросхем, а сверху не распаян ещё один трехножечный элемент :) И в интернете мне попадалась информация и не раз (не могу сказать, насколько можно ей доверять - я, по крайне мере, не пытался её проверить), что для J11 ДЕЛАЛИ, но ОТМЕНИЛИ CIS. И так же попадалась причина - что бы и J11 не создавал конкуренцию первым VAX-ам (не даром же производительность J11 в топе достигает 1 vup).
ну CIS появились еще во времена IBM360
Мне кажется вполне возможным, что идеи работы с форматом данных, которые использует CIS, могли (и скорее всего) появились гораздо раньше - как только компы начали более менее активно использовать для бизнес задач. Причём, наверное, в первую очередь - финансовые. Ибо формат с плавающей точкой может и быстрее, но он не точный (как там выглядит в нём запись, скажем, числа 0.3? Вот как - 037631, 114631, 114631, 114632 - это я выбрал двойную точность :) ), а объяснить что нашей налоговой, что их - куда это делись копейки? Какой такой неточный формат чисел? Это вы от налогов прибыль скрываете! - округлениями/усечениями - не прокатит :) А формат CIS - это, по сути, целые числа, для которых просто договорились - где находится десятичная точка :) И результаты будут точным - вот вам результат деления, вот вам остаток - всё, с точностью до копеек-центов.
Oracle2 как раз на PDP-11 и работал и явно использовал CIS
Нууу... совсем не уверен. Вроде как CIS был только в PDP-11/23(F11),23+(F11),24(F11),44(1980 - а вроде как Oracle 2 вышел в районе 79-ого) и (по инфе из simh) J11 - везде как опция.
То есть если Oracle 2 и использовал CIS (именно набор инструкций, а не формат данных) - то это могло быть только на F11, а он вышел вроде в 1979 - что то тоже сомнительно - что бы выпуcтить Oracle в этом же году, надо было иметь информацию и возможность тестирования продукта на (ещё) не вышедшем процессоре. Да, DEC отличалась тем, что часто инфа о новых продуктах выходила до того, как их можно было приобрести (и бывало, что так и оставалась инфой), но что бы она раскрыла внутреннюю инфу и дала доступ к предварительным вариантам железа.. Чёт я сомневаюсь
KEF11-B - Commercial Instruction Set option chip.
Year of Introduction - 1979
Value - $200
Comments - "A very rare option chip for the two boards above (KDF11-A (PDP-11/23) и KDF11-B(PDP-11/23-Plus)), but usually only seen on the second type; of considerable value by itself."
Мои комментарии - нууууу, видимо мне жутко повезло :) И то, что он появился на eBay и то, что цена оказалась хоть и большой, но не максимальной для меня - я готов был заплатить и больше :) Хотя для меня самое большое везение состоит в том, что он оказался рабочим :)
Нашёл ошибку в загрузке дескрипторов CIS (https://zx-pk.ru/threads/31998-dec-i-ya.html?p=1077641&viewfull=1#post1077641). Влияло только на тесты CIS (ну а ещё могло портить память). Исправил и обновил тесты (в том числе и CIS)
.RUN SPEED3
Тест быстродействия
R1+R0 classic 529 528 оп./сек
R1(23456.)+R0(12345.) empty 165 433 оп./сек
R1(23456.)+R0(12345.) 126 565 оп./сек -> 538 695 оп./сек
R1+@R0 classic 330 002 оп./сек
R1(23456.)+@R0(M-12345.) empty 165 431 оп./сек
R1(23456.)+@R0(M-12345.) 110 383 оп./сек -> 331 724 оп./сек
R0*R0 classic 40 774 оп./сек
empty 11.*12. 165 434 оп./сек
11.*12. 32 667 оп./сек -> 40 704 оп./сек
R2/R0 classic 140 720 оп./сек
R2-R3(34567.)/R1(321.) empty 126 561 оп./сек
R2-R3(34567.)/R1(321.) 20 125 оп./сек -> 23 930 оп./сек
34567.89022+32109.754321 empty 26 696 оп./сек
34567.89022+32109.754321 9 787 оп./сек -> 15 451 оп./сек
34567.89022*32109.754321 empty 26 696 оп./сек
34567.89022*32109.754321 3 595 оп./сек -> 4 154 оп./сек
34567.89022/32109.754321 empty 26 698 оп./сек
34567.89022/32109.754321 3 499 оп./сек -> 4 026 оп./сек
CIS MULPI 1 432 оп./сек
CIS MULP 1 empty 56 831 оп./сек
CIS MULP 1 434 оп./сек -> 437 оп./сек
CIS MULPI 2 2 005 оп./сек
CIS MULP 2 empty 56 849 оп./сек
CIS MULP 2 2 041 оп./сек -> 2 117 оп./сек
CIS ADDNI 1 3 144 оп./сек
CIS ADDN 1 empty 56 847 оп./сек
CIS ADDN 1 3 227 оп./сек -> 3 421 оп./сек
CIS ADDNI 2 6 496 оп./сек
CIS ADDN 2 empty 56 852 оп./сек
CIS ADDN 2 6 896 оп./сек -> 7 847 оп./сек
MOV 8 word 1 empty 110 383 оп./сек
MOV 8 word 1 13 876 оп./сек -> 15 871 оп./сек
MOV 8 word 2 empty 110 382 оп./сек
MOV 8 word 2 17 064 оп./сек -> 20 184 оп./сек
CIS MOVCI 8 word 1 13 995 оп./сек
CIS MOVC 8 word 2 empty 58 354 оп./сек
CIS MOVC 8 word 2 16 246 оп./сек -> 22 513 оп./сек
.
Обратил внимание, что команда (символьной) пересылки MOVC работает быстрее (22 513), чем классический (словный) цикл (15871), даже развёрнутый (две инструкции MOV) (20184) :)
А есть общепринятые мнемоники у этих CIS-инструкций?
А есть общепринятые мнемоники у этих CIS-инструкций?
MULPI, MULP, ADDNI, ADDN, MOVCI, MOVC - это мнемоники, которые знает MACRO-11 и описаны в документации
Очень похожие на CIS инструкции есть в х-86. Я ранее думал, для чего их впихнули??? Однако ветер дул в том числе от DEC :)
На мейнфреймах инструкции типа DEC CIS были всегда, а на x86/68k/Z80/6502/... совсем другое, побайтовое.
Мерял тайминги десятичных инструкций на мейнфрейме IBM - там прямая зависимость от длин обоих операторов. Поэтому для таких инструкций нужно приводить формулу, число тактов или мкс с двумя параметрами-длинами. На некоторых мейнфреймах (думаю, всех, начиная с 90-х) эти инструкции оптимизированы, зараз обсчитывают группы до 4-байт (8-и цифр). Может на System/Z там уже зараз и 8 байт берут.
Мне кажется вполне возможным, что идеи работы с форматом данных, которые использует CIS, могли (и скорее всего) появились гораздо раньше - как только компы начали более менее активно использовать для бизнес задач. Причём, наверное, в первую очередь - финансовые. Ибо формат с плавающей точкой может и быстрее, но он не точный (как там выглядит в нём запись, скажем, числа 0.3? Вот как - 037631, 114631, 114631, 114632 - это я выбрал двойную точность :) ), а объяснить что нашей налоговой, что их - куда это делись копейки? Какой такой неточный формат чисел? Это вы от налогов прибыль скрываете! - округлениями/усечениями - не прокатит :) А формат CIS - это, по сути, целые числа, для которых просто договорились - где находится десятичная точка :) И результаты будут точным - вот вам результат деления, вот вам остаток - всё, с точностью до копеек-центов.
Интересно было бы узнать откуда взялся этот BCD. Теоретически длинные двоичные числа лучше. Возможно в стародавние времена проще было сделать BCD, чем что-то типа PRINT USING...
Теоретически длинные двоичные числа лучше
Не факт. Потому что BCD - он почти готов к вводу/вывода (в случае ASCII), а двоичные - ещё надо перевести из строки в двоичное представление и обратно)
Пример https://zx-pk.ru/threads/32126-commercial-instruction-set-(cis)-na-pdp-11-i-ya.html?p=1076627&viewfull=1#post1076627 это наглядно показывает - берём строку в ASCII, умножаем на строку в ASCII, получаем строку в ASCII, которую сразу печатаем. Никаких преобразования. Ну и в CIS, насколько я помню, были строковые команды перевода из ASCII в BCD и обратно
- - - Добавлено - - -
Кстати, теперь я могу попробовать CIS с Коболом под RSX, так как и для KDF доступно 4 (чуть не написал гига) мегабайта памяти – то есть без проблем загрузится RSX-Plus :)
"Под руководством Дика Брауна (если я правильно помню) в разработке был 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. По крайней мере, до Альфы ..."
Не факт. Потому что BCD - он почти готов к вводу/вывода (в случае ASCII), а двоичные - ещё надо перевести из строки в двоичное представление и обратно)
Пример https://zx-pk.ru/threads/32126-commercial-instruction-set-(cis)-na-pdp-11-i-ya.html?p=1076627&viewfull=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 Ваксами много всего странного связано.
но расчеты с двоичными быстрее
Ну и попробуйте умножить 123456789012345 на 234567890123456, с переводом из строковое в двоичное и обратно - и сравним скорость.
Какая-то логика лузеров.
Сказал человек, живущей через 40 лет после того принятия решения.
Раньше задачи были другие :)
Больше ввода-вывода, меньше расчётов. Процессоры считали медленнее. Была экономия.
А на счёт интела не правы... На x-86 есть символьная арифметика. Она по сравнению с прочими порезана, скорее обходная но:
AAA
AAD
AAM
AAS
:)
Ну и попробуйте умножить 123456789012345 на 234567890123456, с переводом из строковое в двоичное и обратно - и сравним скорость.
Если работать в режиме калькулятора, то, конечно, BCD быстрее. Но если работаем в режиме компьютера, например, нужно сложить 1000 чисел и напечатать сумму, то BCD будет большим тормозом.
в "больших" СУБД, как то Oracle, для хранения финансовых данных и расчетов используется BCD (NUMERIC формат данных, MONEY), а не float-point. Нужно ли объяснять причину такого решения?
Нужно ли объяснять причину такого решения?
Причина - в точности вычисления. Двоичные данные с плавающей точкой - приблизительны. Я уже приводил выше пример. В случае BCD будут точные данные.
BCD будет большим тормозом.
У вас опять тон абсолютного авторитета, а вы, уверен, никогда и не имели возможности поработать с CIS.
Ля ля ля ля ля ля ля. Про ваши предположения уже давно известно что они только ваши предположения.
Причина - в точности вычисления. Двоичные данные с плавающей точкой - приблизительны. Я уже приводил выше пример. В случае BCD будут точные данные.
Маловероятно. Обычные целые в дополнительном коде обеспечат такую же точность плюс процентов на 20 займут меньше памяти, ну и арифметические операции будут быстрее. ИМХО, единственное преимущество BCD это быстрый вывод в десятичной форме очень длинных чисел.
Маловероятно. Обычные целые в дополнительном коде обеспечат такую же точность плюс процентов на 20 займут меньше памяти, ну и арифметические операции будут быстрее. ИМХО, единственное преимущество BCD это быстрый вывод в десятичной форме очень длинных чисел.
100% - проблема точности при работе с дробными, невозможности точно представить дроби с базой 10 в виде дробей с базой 2.
Обычные целые в дополнительном коде обеспечат такую же точность
Во первых, я имел ввиду представление с плавающей точкой. Во вторых, речь идёт о временах, когда и 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
Ну насчёт точности... Например, двойная точность вполне обеспечивает потребности, но проблема в том, что адекватные FPU по разумной цене появились позднее. Вот Электронике-60(LSI-11/3) попробуй в двойной точности посчитай, а если ещё и прерывания постоянно идут если даже FIS есть?? То же самое касается первых PDP-11 да их конкурентов тож... Да и у нашего на 1801ВМ2 FIS был реализован чисто для совместимости со старым п/о. Без поддержки FIS должно считаться быстрее... Не тратится время на обработку прерываний и переключение контента USER/HALT. Единственное достоинство - код будет занимать чуть места меньше.
По этому народ пошёл по пути такой арифметики... И реализация CIS - инерция. Типа народ хочет, так ведь мы можем ему это дать за "разумные" деньги.
Когда сделали J-11, то там быстродействие самого процессора и инструкций с плавающей запятой оказалось таково, что возиться с CIS не стали(а если уж был FPA). Экономия на преобразовании из символьной в плавающую форму свелась к минимуму.
двойная точность
Ещё раз. Вычисления с плавающей точкой по своей сути - приблизительные вычисления. То, что в десятичных числах является точным (0.1) при использовании плавающей точкой становится приблизительным. BCD по своей сути - это целочисленное представление, так что там 0.1 будет точно 0.1 и 0.1+0.1 будет точно 0.2, а не приблизительно 0.2. Если для науки такая приблизительность допустима, то для финансов - нет.
И реализация CIS - инерция
Нет, это ориентированность на определённый класс задач. Напомню так же, что речь идёт о 60-ых тире 70-ых, когда компьютеры использовались в первую очередь для всяких расчётов, а не как щас - микропроцессор как затычка для всего.
Когда сделали J-11
Я сильно подозреваю, что оказалось, что CIS на нём стал настолько производительным, что уделывал первый VAX (по крайне мере на обычных вычислениях в топе у него производительность 1 VUP на 18 МГц, а я уже показал успешность его запуска на 20 МГц). Дальше - см тему DEC и я, там есть воспоминания тех, кто участвовал в создании 11/74. К сожалению, тут приходится полагаться только на воспоминания, ибо по микросхемам CIS для J-11 нет никакой инфы, даже фоток. В отличии от CIS для F11.
Пока времени нет, но я попробую сделать реализацию своего тестового примера - умножить 123456789012345 на 234567890123456 на целых числах нужной разрядности - тогда можно будет сравнить. В том числе - в полном варианте - преобразовать числа из внешнего представления во внутреннее, умножить, преобразовать во внешнее представление. Тогда у нас будет однозначный ответ на вопрос - что быстрее. Но лично я ставлю, что CIS будет быстрее. Хотя меня и несколько смущает фраза из воспоминаний участников, что CIS к F11 прилепили на позднем этапе проекта - то есть, читай - есть ошибки (точно есть) и неоптимальная производительность (это моё предположение).
Вместо символьной строки вполне можно воспользоваться целым числом, только длина его должна быть нехилым...
Даже 32-разрядов маловато будет(Бюджет США больше). Если учесть, что тогда большая часть процессоров на мини-ЭВМ работала с 16-битными целыми... :(
Надо 64-бита... Какова же была арифметика с 64-битными целыми на мини-ЭВМ??? Только программно ...
В принципе двойной точности хватало... Но с ней тоже не всё ладно было.
Наши 1801ВМ4 в массы так и не смогли пустить :(
Вот Интел свой 8087 делал, так ввёл 80-разрядный формат, в коем и проводились внутренние вычисления. Как я понимаю, чтобы свести к минимуму ошибки округления. И есть у меня некое подозрение, что там на 80-битах округления просто нет. Проблемы с FPU у интела были аж на пентиумах ...
По идее FPU должен проводить округление, но есть подозрения, что не так всё просто.
Да и ещё по поводу точности ... В целочисленной двоичной арифметике никакого округления просто не было... Да и сейчас нет. Только программно. Но это тормоза...
Я помню, что в специфических численных задачах, применялись специальные методы, чтобы не потерять точность на уровне алгоритма вычислений, не смотря на двойную точность с плавающей запятой переменных.
Если честно, то интересно как по факту с округлением в CIS обстояло...
Надо 64-бита
123456789012345 в двоичном виде это - 11100000100100010000110000011011101111101111001 - 48 бит
123456789012345*234567890123456 = 28958998520042431946358064320
К сожалению, калькулятор Windows даёт двоичное представление только до 64 бит. Могу предположить, что результат умножения - это где то 96 бит
Какова же была арифметика с 64-битными целыми на мини-ЭВМ
На PDP-11 считай, не было арифметики на 32 бита (32 бита умножить на 32 бита - это 64 бита), так, отдельные возможности с 32-мя битами - получить как результат умножения и можно было в принципе 32-ух битное разделить на 16-ти битное, но так, что бы получить в результате два 16-ти битных числа.
Мне понадобилась 32-битная арифметика в программе SPEED3 - пришлось нарисовать процедуру умножения (32 бита на 32 бита) и деления (64 бита делим на 32 бита).
Так что даже В ТЕ времена разрядности целых чисел на PDP-11 НЕ ХВАТАЛО. FPP - это приблизительность и ошибки округления. Решение было и оно было реализовано в командах CIS. Кстати, насколько я помню, по крайне мере первые модели VAX-ов тоже реализовывали CIS
По идее FPU должен проводить округление
Насколько я помню (лень лезть в доки), у FPP от PDP-11 есть возможность задать как округление, так и усечение.
целочисленной двоичной арифметике никакого округления просто не было...
В CIS это не нужно, они при деление (как и DIV) дают частное и остаток.
Я помню, что в специфических численных задачах, применялись специальные методы
У нас на мехмате был курс вычислительной математики. Так вот - никаких специфических методов - нет. Просто стараются свести количество операций при вычислений к минимуму. Есть методы оценки накопления ошибок округления/усечения. Соответственно, зная, сколько операций и какого рода применялись, можно сказать - какая ошибка накопилась. То есть получил ты, скажем в результате 123.456789, а ошибка накопилась в десятых - можешь не радоваться - у тебя от 122.5 до 124.5 (очень примерно, что бы показать идею, я всё таки больше 20 лет назад это дело проходил)
Так что ещё раз - нет никаких специальных методов - есть разные алгоритмы с разными количеством операций для достижения результата с определённой точностью. И чем больше операций, тем быстрее теряем точность
- - - Добавлено - - -
Вдогонку.
Мне сложно сказать про быстродействие FPP на чём нибудь типа PDP-11/70 (типа - топовая машина не на микропроцессоре), могу лишь предположить, что принцип выполнения операций был примерно такой же, как и в J11, а не FPA, то есть - микропрограммный.
Почему так думаю.
Потому что FPA был выпущен позже J11, с большой задержкой, вроде его даже дважды отзывали. Напомню, что FPA пилила сама DEC. Если бы в PDP-11/70 было бы что то типа FPA, мне кажется, они бы его запили быстрее.
И потом - FPA использовали как основу для реализации плавающей точки в микроваксах - на этом этапе вроде как проблем уже не было (все были пофиксены, пока пилили FPA для J11).
Я на кафедре физической химии работал... Там были такие задачи, что производительность любой ЭВМ(даже современного суперкомпьютера) сожрут, и мало покажется... Тогда на ЕС-1066 бегали. Расчёты квантовой механики, расчёты по прямой и обратной кинетической задачи(системы жёстких дифуров возили)
Причём на вычислительной математике нам про точность расчётов и не заикались. Сказали, типа сколько мантисса и сколько порядок и увсё... Но у меня химико-технологический институт...
На кафедре люди сами алгоритмы контроля точности городили. В основном сводилось, к тому, чтобы переменные не обнулялись и не теряли значимость мантиссы.
И программа могла попытаться просчитать одно и то же разными путями и выбрать "лучший" по каким-то критериям. На сколько это эффективно было, вопрос интересный :)
Простая программа (пусть на Perl, на C будет то же самое)
my $s = 0;
for(my $i=0; $i <10; $i++)
{
printf "%s: %.18f\n", $i, $s;
$s += 0.01;
}
и ее выхлоп:
0: 0.000000000000000000
1: 0.010000000000000000
2: 0.020000000000000000
3: 0.029999999999999999
4: 0.040000000000000001
5: 0.050000000000000003
6: 0.060000000000000005
7: 0.070000000000000007
8: 0.080000000000000002
Я на кафедре физической химии работал
ГЫ :) Я начинал учиться на химфаке МГУ, во втором семестре первого курса дали программирование (практика - на СМ-3 под DOS/Batch-11) - и усё. Увлечение химией с первого класса школы (ну почти с первого - летом между первым и вторым классом нашёл выброшенные несколько книг, в том числе научно-популярные и школьные учебники - это была любовь, как мне казалось, на всю жизнь) пошло по боку :) Компьютеры - наше всё :)
Причём на вычислительной математике нам про точность расчётов и не заикались.
А нас два семестра (ЕМНИП) дрючили :)
Простая программа (пусть на Perl, на C будет то же самое)
Я похоже на C# нарисовал, там тоже видны "точные" результаты операций :)
100% - проблема точности при работе с дробными, невозможности точно представить дроби с базой 10 в виде дробей с базой 2.
Хм, о плавающем формате с точкой слева я не подумал. Обычно если мне надо "точно-точно" я беру дополнительный код с точкой справа.
Ну, это обычное дело для людей, которые знают - КАК хранятся числа с плавающей точкой. И сколько раз мне приходилось демонстрировать "точность" плавающей арифметики людям, которые не знали...
Кстати, пример с аналогом BCD из C# :)
int i = 0;
decimal r = 0.0M;
while (r != 1.0M)
{
Console.WriteLine(r);
r = r + 0.1M;
i++;
if (i > 200) return;
}
Результат:
0,0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
- - - Добавлено - - -
А сегодня в современных языках уже просто "из коробки" знак числа в его конце или разделение на тысячи не напечатаешь
Не внимательно прочитал первый раз.
Ну что могу сказать.
Человек в очередной раз демонстрирует свои "знания".
decimal i = 0;
for (i=-10000; i <= 10000; i=i+1000)
{
Console.WriteLine(i.ToString("00 000+;00 00#-"));
}
Результат
10 000-
09 000-
08 000-
07 000-
06 000-
05 000-
04 000-
03 000-
02 000-
01 000-
00 000+
01 000+
02 000+
03 000+
04 000+
05 000+
06 000+
07 000+
08 000+
09 000+
10 000+
Я четверть века занимался кассовыми аппаратами. И мы как-то умудрились все сделать на 48-битной целочисленной арифметике - назывался у нас тип tword. На ассемблере была написана основная арифметика с конверторами, и еще там была пара процедур с промежуточными 14-ти байтными значениями. От x86, AVR, ARM7TDMI, Cortex-ы, сертифицировано все (то есть арифметика и округления проходили гос испытания со сторонними тестами) в десятке стран. Никакой плавучки (на AVR - медленно, аппаратный FPU - не по карману), так шо - кому она та плавучка нужна? :) Тока богатым.
Немного оффтоп. Самое смешное, что MySQL еще лет 10 тому хранил и обрабатывал NUMERIC не как BCD, а как Float. С потерей точности на операциях. И приходилось людям объяснять, почему биллинг нельзя просто так перенести на MySQL. Может он и сейчас такой ущербный, лень проверять.
так шо - кому она та плавучка нужна?
При научных вычислениях, когда нужно быстрее, так как вычислений МНОГО :)
MySQL еще лет 10 тому хранил и обрабатывал NUMERIC не как BCD, а как Float
Ну а чё, вместо того, что бы написать соответствующие процедуры, берём float - и всё типа тип-топ. Ключевое слово - типа :)
- - - Добавлено - - -
Я тут прикинул так на пальцах, если делать для (современного) проца что то типа CIS от DEC, то надо максимальную длину BDC числа делать не 31 (десятичная) цифра, а 124 :)
При научных вычислениях, когда нужно быстрее, так как вычислений МНОГО :)
Угу, и моделированием плазмы в фронте волны ядерного взрыва я тоже занимался. Но это было еще до кассовых аппаратов :)
На СМ4 с FIS, потом СМ1420 с FPP. Сначала ты две недели считаешь, потом проводишь проверку законов сохранения заряда, имульса и энергии и ничего не сходится, начинаешь искать где же оно точность потеряло. Блин, фортрановский REAL, оказывается фигня, DOUBLE? Ну здравствуйте, виртуальные массивы :)
Но мой пост был о том что кассовый аппарат - это навороченная бухгалтерская программа - скидки, налоги, конвертация валют, проценты за услуги, накопительные итоги, весовые товары - дофига всего бухгалтерского, и вполне нормально живет без этих ваших флоат и бцд.
... и вполне нормально живет без этих ваших флоат и бцд.
А расскажи про 4-bit ALU в серии AM2900: зачем там отдельный флаг для переноса, если число == 10?
А расскажи про 4-bit ALU в серии AM2900: зачем там отдельный флаг для переноса, если число == 10?
В Am2900 такого флажка не припомню. А вот в 8080 оно есть, да. Ну не все умеют в кассовый аппарат без float. Вот для людей попроще такой флажок и сделали :)
Ты бы видел структуру дневного Z-отчета. Там все упаковано-переупаковано, какой там BCD, размер фискальной памяти очень жесткий, изволь 2100 отчетов (7 лет срок службы, 2100 минимум для сертификации надо) в 64К засунуть, бо 128К уже денег больше стоит.
Насчет точности BCD для десятичной плавучке - оно возможно, но для бухгалтерии точность банально решается увеличением разрядности (см. кассу), для научки тоже нужна разрядность, но точность там менее критична (более того - точность десятичных дробей там бессмысленна), скорость важнее - BCD в пролете. Единственное реальное преимущество BСD - это быстро делить/умножать на 10, в остальном оно сомнительно. Ну и да, историческая совместимость, для фана. 8080 инструкцию для BCD имеет, а вот SSE/AVX инструкций для BCD не видать :)
вполне нормально живет без этих ваших флоат и бцд
Ещё раз напомню, когда это всё первоначально создавалось. Какие, блин, микропроцессоры, какие, блин 64 кб памяти?? Вот и запихали формат, который удобен хранения и вычислений на уровень команд. Да, сейчас всё это уже не сильно применимо в силу разрядности процов, доступной памяти и скорострельности.
но для бухгалтерии точность банально решается увеличением разрядности
Да? И как это сделать на 16-ти разрядной машине, у который крайне ограниченные возможности по большей разрядности? Очень просто - уходить от двоичной на большую разрядность. Идеальные варианты будут кратны степеням двойки, ещё более идеальные - размеру байта. Как тебе арифметика с основанием 256? Но вот проблема - эту нужно рисовать соответствующие команды и опять таки - проблемы с вводом/выводом (нужны преобразования). Поэтому и придумал кто-то промежуточный вариант - хранение чисел в формате с основанием 10. Очень удобно для людей, ввода/вывода, больше разрядов, большая относительная скорострельность по сравнению с основание 2 (меньше циклов), а уж если это запихать на уровень команд процессора...
Да? И как это сделать на 16-ти разрядной машине, у который крайне ограниченные возможности по большей разрядности?
Ну кассовые аппараты лет 10 жили на AVR, оно как бы 8-битное. Мы еще с mega103 начинали, в 1997 году, как только оно появилось на рынке - сразу в оборот пошло. Я еще avreal помню :), потом уже свой прошивальщик замутили. Написали на ассемблере библиотеку для типа tword - основные арифметические операции + плюс несколько специальных функций с больших промежуточным итогом и все.
Как тебе арифметика с основанием 256?
Да нормально, тем более целочисленная обеспечивает полную точность, а там где округления - ТУ на кассы все очень точно описывает (и в обычной бухгалтерии - тоже).
проблемы с вводом/выводом (нужны преобразования).
С вводом-выводом проблем нет - индикатор, принтер, порт выводят числа сильно медленнее чем даже AVR успевал это преобразовать.
Там проблема со счетом, приходит тебе SQL-запрос и нужно посканировать флешку и миллион записей сложить, от тут BCD лишние секунды и сожрал бы.
больше разрядов, большая относительная скорострельность по сравнению с основание 2 (меньше циклов)
Вот я не понял где тут в BCD большая скорострельность. Возьмем два числа - 1222333444 1000111222, в дополнительном коде это 4 байта, в BCD - 5. Уже на 25 процентов больше объема. Перенос в BCD между байтами кривой, на ALU не ложиться. Даже между разрядами в байте кривой - на 8080 нужно сначала сложить, потом делать коррекцию.
Не, ну исторически применение BCD понятно, но сейчас-то оно никак не живет. Ну нету SSE/AVX инструкций BCD, не надо оно сейчас никому.
Если интересно, почему "VAX загнулся" и при чем тут сложные для реализации инструкции - есть Long Read:
https://yarchive.net/comp/vax.html
Вот цитата, которая объясняет невозможность реализации Out-Of-Order (OOO) execution в VAX:
ILP, NORMAL INSTRUCTIONS, and IA-32 VERSUS VAX
Consider the normal unprivileged instructions that need to be executed
quickly, meaning with high degrees of ILP, and with minimal stalls from
memory system.
RISC instructions make 0-1 memory reference per operation. Despite the
messy encodings, *most* IA-32 instructions (dynamic count) can be
directly decoded into a fixed, small number of RISC-like micro-ops,
with register references renamed onto the (larger) set of physical
registers. Both IA-32 and VAX allow unaligned operations, so I'll
ignore that extra source of complexity in the load/store unit.
In an OOO design, the front-end provides memory references to a
complex, highly-asynchronous load/store/cache control unit, and then
goes on. In one case, [string instructions with REP prefix], IA-32
needs the equivalent of a microcode loop to issue a stream of micro-ops
whose number is dependent on an input register, or dynamically, on
repeated tests of operands. Such operations tend to lessen the
parallelism available, because the effect is of a microcode loop that
needs to tie together front-end, rename registers, and load/store unit
into something like a lock-step. Although this doesn't require that
all earlier instructions be retired before the first string micro-ops
are issued, it is likely a partial serializer, because it's difficult
do much useful work beyond an instruction that can generate arbitrary
numbers of memory references (especially stores!) during its execution.
However, the VAX has more cases, and some frequent ones, where the
instruction bits alone (or even with register values) are insufficient
to know even the number of memory references that will be made, and
this is disruptive of normal OOO flow, and is likely to force difficult
[read: complex, high-gate-count or long-wire] connections among
functional blocks on a chip. Hence, while the VAX decoding complexity
can be partially ameliorated by a speculative OOO design with decoded
cache [I alluded to this in the RISC CISC 1991 posting], it doesn't
fix the other problems, which either create microcode lock-steps
between decode, load/store, and other execution units, or require other
difficult solutions. In some VAX instructions, it can take a dependent
chain of 2 memory references to find a length!
VAX EXAMPLES [1], [2], especially compared to IA-32 [10] and sometimes
S/360.
Specific areas are:
- Decimal string ops
- Character string ops
- Indirect addressing interactions with above
- VAX Condition Codes (maybe)
- Function calls, especially CALL*/RET, PUSHR/POPR.
DECIMAL STRING OPERATIONS: MOVP, CMPP, ADDP, SUBP, MULP, DIVP, CVT*,
ASHP, and especially EDITPC: are really, really difficult without
looping microcode. [S/360 has same problem, which is why (efficient)
non-microcoded implementations generally omitted them. The VAX
versions, especially the 3-address forms, are even more complex than
the 2-address ones on S/360, and there are weird cases. DIVP may
allocate 16-bytes on the stack, and then restore the SP later.
Написали на ассемблере библиотеку для типа tword - основные арифметические операции + плюс несколько специальных функций с больших промежуточным итогом и все.
Ну так вот это и есть, по сути, идея CIS - уйти от арифметики с основанием 2 к большему основанию.
4 байта
Не 4 байта, а 32 бита, то есть, грубо - цикл, повторенный 32 раза (ещё раз - мы берём классическую арифметику по основания 2), 1222333444 - 10 цифр - цикл, повторенный 10 раз. Если развивать идею с битностью, предположим, что у нас на аппаратном уровне есть 8-ми битный умножитель, тогда да, для 4-ёх байтного числа - цикл, повторенный 4 раза.
на 8080 нужно сначала сложить, потом делать коррекцию.
А причём здесь 8080 - мы ведём разговор о PDP-11, CIS и почему оно будет в общем случае быстрее (на больших числах), чем программная реализация. И CIS у нас вполне полноценный в этом плане - без всяких этих костылей в 8080
- - - Добавлено - - -
Если интересно, почему "VAX загнулся"
С моей точки зрения, VAX загнулся, потому что идеи его архитектуры базировались на устаревших принципах :)
Но RISC мне тоже не нравится :)
Где то в какой то момент развитие процессоров свернуло не туда.. Но вот как лучше и более правильно - пока не могу придумать :)
Не 4 байта, а 32 бита, то есть, грубо - цикл, повторенный 32 раза
Каких 32 раза? АЛУ у всех сделано на обычную арифметику, тот же 8080 или AVR складывает 4 байта, всего 4 цикла. И они же умеют 16-битные сложения - всего две операции, вместо минимум 3-х для BCD. А вот для BCD надо и флаг специальный чтобы ловить перенос между тетрадами, и перенос между байтами не особо. Умерло оно все, невыгодно ни по скорости, ни по плотности данных.
CIS у нас вполне полноценный в этом плане - без всяких этих костылей в 8080
Именно что костыли там, по-крайней мере, глядя на LSI-11 понятно как они могли BCD арифметику в микрокоде сделать. АЛУ LSI-11 тупо не умеет в десятичную арифметику, но там есть флажок межтетрадного переноса C4, вот на нем и играют. Если бы сделали обычную длинную арифметику - она была бы быстрее BCD.
АЛУ у всех сделано на обычную арифметику, тот же 8080 или AVR складывает
Я про умножение и деление
- - - Добавлено - - -
АЛУ LSI-11 тупо не умеет в десятичную арифметику, но там есть флажок межтетрадного переноса C4, вот на нем и играют.
Для LSI-11 есть микросхема с микрокодом реализации Dibol Instruction Set - типа подмножества CIS под Dibol
Я про умножение и деление
Это лукавство, я не думаю что оно десятичными знаками умножает/делит. Тогда в двоичной системе надо умножать/делить сразу на 4 разряда.
Для LSI-11 есть микросхема с микрокодом реализации Dibol Instruction Set - типа подмножества CIS под Dibol
Да есть, и они кому-то ее даже продавали. BDС на каком-то историческом отрезке жил, может из табуляторов/калькуляторов пришел. Но фундаментальных преимуществ у BDC нету, поэтому оно умерло. Число 10 вообще математически ничем не примечательно. Раскладывается на 2x5, было бы у человека три руки, да по три пальца - вот это гораздо интереснее :). Ну или четыре пальца вместо пяти - про десятичную систему знали бы сейчас примерно столько сколько про шестидесятиричную.
я не думаю
Правда? Уже известен микрокод - как это дело там реализовано?
Правда?
Правда. Потому что для умножения сразу десятичными знаками нужна аппаратура - соответствующий умножитель. А ее нету. Поэтому микрокод иначе как через костыли работать не может. И если уж ухитриться умножать программно сразу десятичным разрядом, то аналогичный алгоритм на шестнадцатиричном разряде (тетраде) будет гораздо эффективнее.
Уже известен микрокод - как это дело там реализовано?
Кому известен? CIS прочитан? Dibol разобран?
Кому известен? CIS прочитан? Dibol разобран?
Так я и спрашиваю - это кто-то сделал? Или всё это - обычные догадки, типа - говорят, "у J11 производительность до 2.5-3 миллионов операций регистр-регистр в секунду". Что оказалось неправдой.
Пока я только вижу, что про CIS и её реализацию ходят много догадок и предположений.
И пока я - единственный человек (на этом форуме), который хоть как то трогал эти инструкции.
Пока я только вижу, что про CIS и её реализацию ходят много догадок и предположений.
Да, догадки и предположения. Но - основанные на личном богатом многолетнем опыте реализаций длинных арифметик для криптографии - обычной, модульной, по модулю 2. Шнайер и третий том Кнута долго были моими настолниыми книгами :)
Просто напиши умножение двух BDC чисел на том же PDP-11 без использования специальных инструкций, чисто реализация алгоритма. И то же самое для умножения числе в дополнительном коде. И сравни. Дополнительный код будет компактнее и быстрее. Можно сделать то же самое для 8080, который типа продвинут и имеет десятичную коррекцию, на результат оно не должно повлиять. Почему ты думаешь что реализация десятичного алгоритма в микрокоде будет эффективнее двоичного алгоритма там же? Алгоритм он и есть алгоритм, если нет аппаратного ускорения (а его в LSI нет точно, насчет F11 - очень сомнительно) , то разница в результатах на одинаковой платформе будет точно та же.
Просто напиши умножение двух BDC чисел на том же PDP-11 без использования специальных инструкций, чисто реализация алгоритма.
А при чём здесь это? Речь идёт о том, что будет быстрее - аппаратная реализация десятичной арифметики (CIS) или программная реализация того же диапазона чисел в двоичном представлении. Понятно, что АППАРАТНАЯ реализация второго будет быстрее - НО ЕЁ У НАС НЕТ.
аппаратная реализация десятичной арифметики (CIS) или программная реализация того же диапазона чисел в двоичном представлении.
А имеет смысл сравнивать яблоки с апельсинами?
А имеет смысл сравнивать яблоки с апельсинами?
Тема называется - Commercial Instruction Set (CIS) на PDP-11.
О чем ещё может идти разговор, когда появляются вопросы - а что, CIS будет быстрее двоичной арифметики (ещё раз - тема - CIS на PDP-11)?
Тема называется - Commercial Instruction Set (CIS) на PDP-11.
О чем ещё может идти разговор, когда появляются вопросы - а что, CIS будет быстрее двоичной арифметики (ещё раз - тема - CIS на PDP-11)?
Нет, можно утверждать что:
- программная реализация умножения BDC будет медленнее программной реализации двоичного кода, за исключением случаев когда есть инструкция умножения базового слова. Для многих процессоров двоичный MUL есть, а вот десятичного MUL пока не попадалось, BDC пролетает.
- то же самое для микрокодовой реализации, двоичной сейчас нет, да, только CIS. Но для LSI-11 уже можно сделать, написан нормальный микроассемблер, можно пробовать.
- аппаратные реализации, скорее всего будут одинаковы.
Можно попытаться сравнить быстродейситвие CIS BDC с обычным MUL. Какой длины слова CIS позволяет умножать?
Вопрос ещё в том, как именно реализована целочисленная арифметика... Что-то мы уже знаем(1801ВМ1 и 1801ВМ2, LSI-11/3(Электроника 60)), благодаря полезным трудам и Vslav. Но увы, мы ещё очень много не знаем :( Но надеюсь, что узнаем более :)
Уважаемый Hunta сравнил в реальности разные системы по производительности. До него я не слышал, чтобы кто-то такую производил. Возможно разработчики и делали 1801 серии ... Но что-то мне говорит, что объём сравнения был менее(CIS в союзе не использовали).
Можно попытаться сравнить быстродейситвие CIS BDC с обычным MUL
То есть яблоко с апельсинами.
программная реализация умножения BDC будет медленнее программной реализации двоичного кода
Это и так понятно. Но. ЕЩЁ РАЗ. Тема называется - Commercial Instruction Set (CIS) на PDP-11. Поэтому и сравниваться будет АППАРАТНАЯ РЕАЛИЗАЦИЯ ДЕСЯТИЧНО АРИФМЕТИКИ с другими реализациями, КОТОРЫЕ ЕСТЬ НА PDP-11
о для LSI-11 уже можно сделать, написан нормальный микроассемблер, можно пробовать.
Вот когда будет - тогда и будем сравнивать.
Какой длины слова CIS позволяет умножать?
Такого понятия в CIS нет. Есть - максимальное количество (десятичных) цифр в числах (два варианта хранения) с которыми оперируют арифметические инструкции CIS. Максимальное количество - 31 цифра. Но поскольку речь идёт об умножении - я тестировал быстродействие умножение двух чисел из 15 цифр (десятичных)
- - - Добавлено - - -
До него я не слышал, чтобы кто-то такую производил
Я думаю, найти можно, но вот что бы в одной таблице и два разных способа тестирования (синтетический и генерация RT) почти в одинаковых условиях - да, мне такое не попадалось.
Кроме того, я сравнил (поскольку тут особых усилий прилагать не пришлось) производительность пересылки блока памяти - классическим MOV и CIS-овским MOVC
Это и так понятно. Но. ЕЩЁ РАЗ. Тема называется - Commercial Instruction Set (CIS) на PDP-11. Поэтому и сравниваться будет АППАРАТНАЯ РЕАЛИЗАЦИЯ ДЕСЯТИЧНО АРИФМЕТИКИ с другими реализациями, КОТОРЫЕ ЕСТЬ НА PDP-11
Ты имел ввиду микрокодовая? Это - не аппаратная. Ну и понятно, что микрокодовая будет быстрее программной.
Мой поинт был всего лишь в том, что сам BDC уже историческая древность, умершая ввиду отсутствия фундаментальных преимуществ над двоичным кодом.
Посмотрел описание CIS, умеют до 31 десятичных знаков, логично, то есть до 128 бит, иначе регистров внутри не хватает.
Но если базу уравнять - умножаем два 16-битных (2 по 4 десятичных знака), то MULP сольет обычному MUL :)
Update: И не факт что и на 32-битном умножении MULP обойдет MUL, дескрипторы строк подготовить, то-сё...
Ты имел ввиду микрокодовая?
В данном контексте - без разница - аппаратная она или микрокодовая.
Ну и понятно, что микрокодовая будет быстрее программной.
Тем не менее - вопрос возник (не у меня)
Мой поинт был всего лишь в том, что сам BDC уже историческая древность, умершая ввиду отсутствия фундаментальных преимуществ над двоичным кодом.
Так и PDP-11 уже историческая древность. Сливаем и его? Тогда о чем мы тут вообще рассуждаем?
Но если базу уравнять - умножаем два 16-битных (2 по 4 десятичных знака), то MULP сольет обычному MUL
И кто бы сомневался.
Вот только для финансовых прог (а именно на них был нацелен CIS) - 65000 - это ни о чём. Почему и появился CIS
Другой вопрос - чё б сразу не реализовать двоичную арифметику до 128 бит, но - это с наших позиций, знаний и возможностей. Какая была логика принятия решения тогда - мы уже врят ли узнаем. Подозреваю, правда, что это было логика меренья штангенциркуля - как часто это происходит, когда решения принимают бизнес-аналитики
- - - Добавлено - - -
Жаль, что никакой инфы про CIS на J-11, только слухи...
В данном контексте - без разница - аппаратная она или микрокодовая.
Мы залазим внутрь процессоров, смотрим схему. Могут быть и аппаратные реализации умножения базовых слов (та самая таблица умножения, которую мы учим во втором классе), поэтому - микрокод это микрокод, а аппаратный умножитель - это аппаратный умножитель. 1801ВМx имеют аппаратную реализацию умножения? Нет - только микрокодовую.
Мы залазим внутрь процессоров, смотрим схему
Сейчас мы смотрим на всё это дело снаружи. И не можем выбирать - хотим мы CIS с аппаратной или микропрограммной реализацией. Поэтому - без разницы, от того, как мы это дело назовём (в контексте данной темы) - НИЧЕГО не изменится.
- - - Добавлено - - -
Вот когда появится тема, наподобие - Реализация CIS для F11 и её особенности - там да, написать - аппаратная реализация - будет грубой ошибкой.
пока не разберём F-11 и не поймём как он работает...
Предполагать можно много чего :)
Реальность иногда приносит сюрпризы...
Например: аппаратный умножитель есть, но он не используется в силу того, что кого делали CIS его ещё не было... Или по другой причине...
Предполагать можно много чего
Я не удивлюсь, если Vslav окажется прав, но.. можно гадать-догадываться - и ошибаться.
Хотелось бы и микрокод CIS заиметь, но.. микруха у меня одна - если только аккуратно крышки отпаять, сфоткать и обратно припаять.. Жертвовать на деструктивное вскрытие, по крайне мере пока, не готов :):):)
Хм... можно разобраться с протоколом, как именно считывается микрокод... Поди другие с микрокодом модули как-то считываются при работе...
И просто считать. И единственный модуль с CIS останется жив-здоров :)
Возможно этот протокол где-то и описан...
На сколько я понимаю, процессорная сборка на 1811 вещь хоть и более редкая, чем 1801, но найти несколько штук вполне можно.
Как установил Hunta, если вставить 1811 вместо F11, то всё вполне работает... :)
Почему бы не исследовать 1811?
И вполне возможно, что можно сделать на FPGA ;)
можно разобраться с протоколом, как именно считывается микрокод... Поди другие с микрокодом модули как-то считываются при работе
Насколько я помню, Vslav говорил, что у F11 не только ПЗУ микрокода, но и матрица PLM. Которую возможно удастся считать, а возможно нет.
На сколько я понимаю, процессорная сборка на 1811 вещь хоть и более редкая, чем 1801
Нет, вполне покупаемая на eBay. У меня есть парочка (именно процессорных сборок), правда с разными кодами на микрухах (303E-302H, 303D-302F и 303D-302H), хотя коды вида 21-ххх-нн совпадают. ПЗУ микрокода - это 303
если вставить 1811 вместо F11, то всё вполне работает
Ну, работать то работает - это не удивительно - вроде воронежцы драли один-в-один, но вот чем отличаются наша ПЗУ с 1811 от 303D и 303E..
Идеально было бы, конечно, считать ПЗУ, а не разбираться по снимкам...
https://gunkies.org/wiki/FP11_floating_point
https://gunkies.org/wiki/FPF11_floating_point_processor
Всё это есть и в более полном виде - в документации.
И да - это сайт я прекрасно знаю.
И ещё вдогонку - у меня есть FPA.
Интересное кино https://yadi.sk/i/xQFlB1q73tdMOg
В файле J-11_Programmers_Reference_Jan82.pdf есть перечисление CIS...
В файле J-11_Programmers_Reference_Jan82.pdf есть описание CIS
Ну так не раз уже встречалась информация, что по крайне мере начинали делать CIS для J-11.
И учитывая пометку о конфиденциальности - особо удивляться нечему..
И просто считать. И единственный модуль с CIS останется жив-здоров :)
Если ты там ebay мониторишь - увидишь F11 с CIS - маякни, если там цена дурная, прикуплю на реверс.
Если ты там ebay мониторишь - увидишь F11 с CIS - маякни, если там цена дурная, прикуплю на реверс.
Ок. Но, боюсь, цена будет действительно дурная...
- - - Добавлено - - -
F11 без CIS купить можно без проблем, можно даже налететь на недорогие...
Ок. Но, боюсь, цена будет действительно дурная...
У меня последнее время часто НЕ/NOT выпадают из текста :)
Предыдущее сообщение следует читать: "если цена НЕ дурная", то есть - не очень высокая.
KDF11 простой у меня есть.
то есть - не очень высокая.
Я это предположил :)
CIS для J-11
а это:
https://gunkies.org/wiki/FPJ11_floating_point_accelerator
Это называется FPA - floating point accelerator, заменяет микрокодовую реализацию FPP в J-11, к CIS никаким боком
- - - Добавлено - - -
В файле J-11_Programmers_Reference_Jan82.pdf есть перечисление CIS...
Когда в первый раз наткнулся - не сильно обратил внимание, что там везде встречается упоминание CIS. А сейчас листаю - про CIS рассказывается так, как будто собирались реализовать. Вот только что было упомянуто, что по производительности CIS J-11 будет эквивалентен PDP-11/44
- - - Добавлено - - -
"J-11 содержит дополнительный функционал, отсутствующий в PDP-11/70:
...
- инструкции CIS"
Судя по тому, что спужались конкуренции с VAX - похоже, что сделали CIS на J-11 и испугались шустрости.. :)
Но что мешало им эту шустрость малость притормозить ;)
Судя по тому, что спужались конкуренции с VAX - похоже, что сделали CIS на J-11 и испугались шустрости..
По крайне мере - сей факт упоминается часто :) В том числе встречал и в preliminary и company confedetial доках. Жалко только, что раньше не сильно CIS интересовался, ибо не было в пределах досягаемости соответствующих процов - так что глаз на упоминание в доках CIS не останавливался...
Но что мешало им эту шустрость малость притормозить
Проблему решили кардинальней...
Сказал человек, живущей через 40 лет после того принятия решения.
Речь не только про DEC. Подобные истории происходили и с другими компаниями-лузерами, например, Коммодор свернул много перспективных проектов...
Ля ля ля ля ля ля ля. Про ваши предположения уже давно известно что они только ваши предположения.
Готов подписаться в подписке на построение вам памятника как заслуженному цифровому археологу. Такого CIS-динозовра раскопали! Кстати, знающие люди говорят, что лучше всего эмулятор CIS писать под RSTS/E.
Во первых, я имел ввиду представление с плавающей точкой. Во вторых, речь идёт о временах, когда и 32 бита - это было много. 16 десятичных цифр - это сколько будет бит? А 31 десятичная цифра? А реализация умножения деления с числами с таким количеством бит?
Какие проблемы? Это элементарно, но в дремучие 60-е, когда ещё и концепции флага переноса толком не было, с этим могли быть проблемы. Например, на очень недешевых ИБМ-мейнфреймах реализовывать 64-битную арифметику было тормознуто из-за отсутствия в архитектуре работы с флагом переноса. На PDP-11 с этим флагом работа сделана неуклюже, но сделана. А умножения и деления - это сдвиги и сложения/вычитания с переносом. Сделать на PDP-11, например, 256-разрядную арифметику - это запросто.
К сожалению, калькулятор Windows даёт двоичное представление только до 64 бит. Могу предположить, что результат умножения - это где то 96 бит
В CIS это не нужно, они при деление (как и DIV) дают частное и остаток.
А идея 16-х чисел для вас неизвестна? И причем тут CIS - это нормально для любой целочисленной арифметики.
Не внимательно прочитал первый раз.
Ну что могу сказать.
Человек в очередной раз демонстрирует свои "знания".
decimal i = 0;
...
Очень вас благодарю за информацию. Есть оказывается наследники у кобола и древних бейсиков. С этой си-музыкой никогда не работал и не желал даже, есть же нормальные языки вроде плюсов с явой, питона, рубина, js, хаскеля, ... - пхп и то лучше.
Если интересно, почему "VAX загнулся" и при чем тут сложные для реализации инструкции - есть Long Read:
https://yarchive.net/comp/vax.html
Благодарю вас за ссылку. Но вроде давно известно, что DEC и Motorola перемудрили с системой команд и имели проблемы с маркетингом. Билл Джой хорошо сказал "Стало ясно, что Motorola развивает свои процессоры примерно также ошибочно как и DEC. Другими словами, 68010 68020 68040, становились более и более сложными. И они буксовали, не становясь быстрее такими же темпами как транзисторы, из которых они были сделаны."
И пока я - единственный человек (на этом форуме), который хоть как то трогал эти инструкции.
Ваш покорный слуга недавно на IBM 4361 прогонял бенчмарки для десятичной арифметики. Они там почти такие же как и CIS - неслучайно наверное? ;)
Подобные истории происходили и с другими компаниями-лузерами
Назвать кого-то, через сорок лет, компанией-лузером - много ума не надо. Попробуйте создать свою компанию, которая реализует много перспективных проектов. А мы посмотрим.
Готов подписаться в подписке на построение вам памятника
Нахера он мне?
знающие люди говорят, что лучше всего эмулятор CIS писать под RSTS/E
Вот пусть знающие люди и пишут эмулятор. Мне это не сдалось от слова совсем.
но в дремучие 60-е, когда ещё и концепции флага переноса толком не было
Лузеры это проектировали - правда?
Сделать на PDP-11, например, 256-разрядную арифметику - это запросто
Это сейчас с возможностями современной электроника и овердохрена ресурсов на компе. Но как показывает практика, как только современный "программист" суётся в область с крайне ограниченными ресурсами - нихера у него не получается.
А идея 16-х чисел для вас неизвестна?
Вот только компы (большинство современных) работают с двоичной арифметикой и им насрать, как двуногие расписывают для себя двоичное представление чисел. Хотя, о каких числах вообще стоит говорить?? Сигналы НетНапряжения - ЕстьНапряжение. CIS - это как раз пример, когда арифметика десятичная, хотя бы снаружи проца. Но даже тут мы не знаем - как оно внутри реализовано.
нормальные языки вроде плюсов с явой, питона, рубина, js, хаскеля, ... - пхп и то лучше
Аха, большинство приведённых языков - наследники Си и тоже полная хрень
не становясь быстрее такими же темпами как транзисторы, из которых они были сделаны."
Главное в процессоре - вовсе не быстрота. Вот только те же самые маркетолухи успешно засрали людям голову, преподнося это как единственный критерий хорошего проца - БЫСТРЕЕ
про "дремучие 60е" я бы был по-осторожнее.
Вот статья про ускоренный расчет бита переноса при сложении:
https://en.wikipedia.org/wiki/Carry-lookahead_adder
Патент выдан в 1960 году.
Почему при "одинаково быстрых транзисторах" (одинаковом технологическом процессе) в одних процессорах можно было распаралелить исполняющие блоки CPU и/или поднять частоту, а в других - нет -- там же в статье про VAX.
Надо было 64 бита...
И нормальную целочисленную арифметику...
Но экономилиВообще-то, 31 десятичная цифра - это ближе к 100 двоичным разрядам...
И, кстати, коллеги, вы не сравнивали скорость байтовой пересылки с программной при разной четности адресов? Типа, переслать строку, начинающуюся с четного адреса по нечетному? Пересылать такое программно - только по байту, что более, чем вдвое тормознее пословной пересылки, А если это сделано на уровне CIS-овского микрокода,то, теоретически, есть возможность сделать эту пересылку по словам, используя пару каких-то внутренних регистров, как промежуточных, перекомпоновывая в них байты в слова с правильным положением байтов. А байтовой пересылкой останется только пересылка самого первого и самого последнего байта.
А как оно там сделано на самом деле?
И, кстати, коллеги, вы не сравнивали скорость байтовой пересылки с программной при разной четности адресов?
У кого то есть ещё CIS микросборка?
А как оно там сделано на самом деле?
Кто то имеет на руках текст микрокод?
Странно, что люди сравнивают десятичную и вещественную арифметику - это очень разные типы данных. Очевидная альтернатива 31-разрядным десятичным данным - 128-битные целые бинарные. Их GCC уже довольно давно поддерживает "из коробки".
Нахера он мне?
3а заслуги.
Это сейчас с возможностями современной электроника и овердохрена ресурсов на компе. Но как показывает практика, как только современный "программист" суётся в область с крайне ограниченными ресурсами - нихера у него не получается.
Интересная тема. Действительно почему-то некоторые очевидные и несложные алгоритмы в прежние времена в упор не видели. Например, не мог найти для 6502 быстрой сортировки, для z80 нормального деления, ... Очень странно, что поддержки бинарных больших чисел в ЯВУ не было вплоть до 2000-х. У меня студенты длинную арифметику делали - какие проблемы?
Аха, большинство приведённых языков - наследники Си и тоже полная хрень
А чем плох си? Минималистичность и мощь, а также продуманность в мелочах, которой не хватала паскалю и прочим адам.
Главное в процессоре - вовсе не быстрота. Вот только те же самые маркетолухи успешно засрали людям голову, преподнося это как единственный критерий хорошего проца - БЫСТРЕЕ
Это что-то новенькое. Более быстрый процессор автоматически киллит более медленный. Хотя сейчас Интел всё держит под контролем и может, как это любят маркетологи, тормозить инновации.
про "дремучие 60е" я бы был по-осторожнее.
Патент выдан в 1960 году.
Почему при "одинаково быстрых транзисторах" (одинаковом технологическом процессе) в одних процессорах можно было распаралелить исполняющие блоки CPU и/или поднять частоту, а в других - нет -- там же в статье про VAX.
Это про поразрядный перенос - с ним все было в порядке, мы же про пословный, внешний. Его, повторю, даже на IBM/390 по-нормальному не было.
Об этом Джой и говорил - намудрили с инструкциями. Кстати, когда в Интел узнали, что 68020 делается со сверхтяжелыми командами, которые никогда не разогнать - там сразу начали хвалить конкурента. :)
Очевидная альтернатива 31-разрядным десятичным данным - 128-битные целые бинарные
GCC уже довольно давно поддерживает "из коробки".
Когда - в 60-ые и 70-ые? Ещё раз - не надо смотреть на компы 60-ые и 70-ых годов с текущих позиций.
3а заслуги.
Не интересно
Действительно почему-то некоторые очевидные и несложные алгоритмы в прежние времена в упор не видели.
Что может быть проще колеса - но вот не видели его в прежние времена майи в упор
Минималистичность и мощь, а также продуманность в мелочах
фигня
Более быстрый процессор автоматически киллит более медленный.
Аха, конечно
делается со сверхтяжелыми командами
И сверхлегкие (RISC) и сверхтяжёлые (CISC) команды - одинаковая хрень. Но RISC даже больше
Захотелось мне странного... Один из результатов этого :)
KDF11B-BH ROM V1.0
4088KB MEMORY
9 STEP MEMORY TEST
STEP 1 2 3 4 5 6 7 8 9
TOTAL MEMORY ERRORS = 0
CLOCK ENABLED
Boot Switch (S1) Invalid
Type ? for HELP
Enter one of [Boot, Diagnose, Help, List, Map]:BOO DU0
TRYING UNIT DU0
BOOTING FROM DU0
BOOTING UP XXDP-XM EXTENDED MONITOR
XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM DU0
124KW OF MEMORY
NON-UNIBUS SYSTEM
RESTART ADDRESS: 152000
TYPE "H" FOR HELP !
.R JKDH??
JKDHB0.BIC
CJKDHB KEF11-B CIS DIAGNOSTIC
SWR = 000000 NEW =
END PASS # 1
Это про поразрядный перенос - с ним все было в порядке, мы же про пословный, внешний. Его, повторю, даже на IBM/390 по-нормальному не было.
Об этом Джой и говорил - намудрили с инструкциями. Кстати, когда в Интел узнали, что 68020 делается со сверхтяжелыми командами, которые никогда не разогнать - там сразу начали хвалить конкурента. :)
Что Вы имеете ввиду под "пословный, внешний" (перенос): ripple-carry adder (RCA) или carry-lookahead adder (CLA)?
Что Вы имеете ввиду под "пословный, внешний" (перенос): ripple-carry adder (RCA) или carry-lookahead adder (CLA)?
На IBM 360/370 не было инструкций сложения/вычитания с флагом переноса. Поэтому многословная арифметика всегда требовала явной проверки флага переноса после каждой операции и выполнения условного перехода.
На IBM 360/370 не было инструкций сложения/вычитания с флагом переноса.
Это которые на PDP-11 - ADC SBC ?
Это которые на PDP-11 - ADC SBC ?
Да, и практически на всех более поздних архитектурах. Честно говоря, на практике мне не попадались архитектуры без поддержки арифметики с флагом переноса.
Да, и практически на всех более поздних архитектурах. Честно говоря, на практике мне не попадались архитектуры без поддержки арифметики с флагом переноса.
На MIPS вообще нет флагов - делать там многословные сложения - это реально ужос.
Сегодня обнаружил удивительный факт. Оказывается бейсики атари, msx и tandy trs-80 model 100 используют BCD для представления мантиссы.
@Hunta, можешь измерить размеры для посадочного места блока с CIS MicROM?
Я вижу 40 ножек, по длине понятно, что там по ширине?
Я сейчас делаю плату читалки, можно будет или запаять микросхемы напрямую,
или вставлять MK1 в панельку (но там 46 ног), ну и хорошо бы твой CIS тоже заходил бы.
Я маршрут считывания откатаю (там stm32 будет) и могу тебе пустую плату читалки прислать,
если будет настроение - прочтешь свой CIS.
размеры для посадочного места блока с CIS MicROM
Имеешь ввиду - размеры между ногами этой микросборки на шесть микрух?
Да. Чтобы ты мог запаять в плату читалки панельку и потом вставить в нее cis для чтения.
Размеры посадочного места (замеры линейкой)
- 48.3 мм (между крайними ножками по длинному ряду, оценка на глаз) на 35.5 мм (поперёк микросборки, оценка на глаз)
Размеры по измерениям между ножками микросхем (замеры штангенциркулем)
- 48.25 мм (между крайними ножками по длинному ряду) на 35.4 мм
- - - Добавлено - - -
Получается, по идее, что между ножками 0,1 дюйма, а поперёк микросборки между ножками 1.4 дюйма
Получается, по идее, что между ножками 0,1 дюйма, а поперёк микросборки между ножками 1.4 дюйма
Да, по ширине выходит 0.6" + 0.2" + 0.6".
Еще схему бы широкого носителя, но у меня есть узкие (0.6") носители DEC c двумя микросхемами, по ним срисую, они там все параллельны должны быть.
Блин, МК1 сделали 46 ножек, отличается от DEC-овских 40, надо тоже схему перепроверять.
Там вроде крайние не используются...
Еще схему бы широкого носителя
Могу сфоткать с близкого расстояния, но, боюсь, это мало что даст...
Посмотрел с обеих сторон... Ничего не видно. На нашей МК1 что то просвечивает, а тут не фига...
Могу сфоткать с близкого расстояния, но, боюсь, это мало что даст...
Да не надо, там понятно что должно быть, я на узком модуле вполне перепроверю. МикROM все параллельно цепляются.
Да не надо, там понятно что должно быть, я на узком модуле вполне перепроверю
Ну, как я и написал - ничего там особенного не видно, так что... я смысла не вижу фоткать, но если вдруг - бест проблем. Могу и саму KDF11-B сфоткать, если что :) В смысле - без микросборок, что бы дорожки были видны. Если вдруг понадобится :)
Из занимательного. Похоже, микросборка CIS всплывает на eBay чаще, чем я думал :) С моей любовью иметь всё в двух экземплярах - я не мог пройти мимо :) И скоро ещё одна должна начать движение ко мне. С ней едет приятный аддон - KDF11-B :)
У меня, кстати, импортный модуль с FIS на читалке не прочелся, то ли неисправен, то ли цоколевка отличается, то ли контактные явления какие. Попробую чипы выпаять, на переходник посадить, потом одну читалку вам с anasana отправлю, можете поковыряться.
импортный модуль с FIS
Наверное, всё таки FPP? Если речь идёт о F11 :)
потом одну читалку вам с anasana отправлю
Буду ждать :)
Наверное, всё таки FPP? Если речь идёт о F11 :)
Да, конечно, FPP.
Но 1811ВУ-шки все вычитались и совпали с тем что вытащили с микрофотографий, то есть достоверность высокая.
Но 1811ВУ-шки все вычитались и совпали с тем что вытащили с микрофотографий
Внушает оптимизм и в отношении CIS :)
импортный модуль с FIS на читалке не прочелся
можно посмотреть фото этого FIS ?
можно посмотреть фото этого FIS ?
Можно.
google.com -> DEC303E -> Картинки
Одна из: http://www.cpucollection.se/details.php?image_id=1311
Тесты CIS (для PDP-11/23-24 с CIS и для PDP-11/44) - JKDHA0.BIC и JKDHB0.BIC (более старый и более новый вариант)
Листинги - http://www.bitsavers.org/pdf/dec/pdp11/microfiche/Diagnostic_Program_Listings/Listings/
CJKDHA0__11-23,11-24-__KEF11-B_CIS_DIAG__AH-S433A-MC__OCT_1981_gray.pdf
и
CJKDHB0__11-23-24-73,MICRO_11__KEF11-B_CIS_DIAG__AH-S433B-MC__JUL_1985_gray.pdf
- - - Добавлено - - -
Завтра постараюсь погонять тесты на своей платы и выложу результаты. Сегодня уже поздновато стенд собирать :)
Время первого прохода - (очень) примерно 30 секунд, второго и последующих - примерно минута 25 секунд.
BOOTING UP XXDP-XM EXTENDED MONITOR
XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM HX0
124KW OF MEMORY
NON-UNIBUS SYSTEM
RESTART ADDRESS: 152000
TYPE "H" FOR HELP !
.R JKDHA0
JKDHA0.BIC
CJKDHA KEF11-B CIS DIAGNOSTIC
SWR = 000000 NEW =
END PASS # 1
END PASS # 2
END PASS # 3
- - - Добавлено - - -
BOOTING UP XXDP-XM EXTENDED MONITOR
XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM HX0
124KW OF MEMORY
NON-UNIBUS SYSTEM
RESTART ADDRESS: 152000
TYPE "H" FOR HELP !
.R JKDHB0
JKDHB0.BIC
CJKDHB KEF11-B CIS DIAGNOSTIC
SWR = 000000 NEW =
END PASS # 1
END PASS # 2
Посылка с KDF11-B (с микросборкой CIS) и ещё одна, из Штатов, застрявшая на две недели с копейками на отметке - прибыло в Германию, вчера и сегодня таки прибыли в Россию, уже прошли таможню и переданы в доставку по России... Я уже было начал печалится что таки всё, прощаться с ними надо, но нет, эти всё таки получу. А вот новых покупок на eBay, скорее всего, придётся ждать очень долго...
Одну посылку получил (там J11), а вторая, которая с KDF11-B - на подходе - практически наверняка в понедельник смогу получить.
Последняя посылка с eBay получена.
Из хорошего - микросборка CIS вроде рабочая (надо ещё тесты погонять)
Из плохого - плата в серийник ничего не шлёт (возможно, какие-то перемычки не так поставил)
Из хорошего - судя по морганию светодиодов - тест при включении проходит норм.
Так что с плохим буду разбираться.
Запретил набортные SLU, воткнул плату со SLU - работает. То есть проблема наблюдается только с набортными SLU
Занимательно..
"The Commercial Instruction Set (CIS) was a late addition to the PDP-11 architecture. Modeled after the commercial instructions in the VAX, CIS was intended to boost the PDP-11’s COBOL performance. It provided an extensive set of string and decimal instructions; indeed, its capabilities were more complete than its VAX counterparts."
"Коммерческий набор инструкций (CIS) был поздним дополнением к архитектуре PDP-11. Созданный по образцу коммерческих инструкций VAX, CIS был предназначен для повышения производительности COBOL-а на PDP-11. Он предлагал обширный набор строковых и десятичных инструкций и действительно - его возможности были более полными, чем у его аналогов VAX."
Мало того, что CIS пришёл, оказывается из VAX в PDP-11, так имел ещё и бОльший набор инструкций (надо будет, кстати, посмотреть - а что есть на VAX-ах). Тогда "легенда" о том, что PDP-11/74 и CIS на J-11 прикрыли, что бы первые VAX-ы не выглядили бледно на фоне новых PDP-11 и лучше продавыались - может оказаться не такой уж и легендой.. :)
Но вот полностью доверится высказыванию Боба Супника мне пока мешает ещё один факт. Был урезанный вариант CIS (DIS) для LSI-11. К сожалению, по нему маловато информации и непонятно, когда он вышел. Да и в коллекции у меня этих микрух нет :) И в ближайшее время врят ли будет, даже если они и всплывут на eBay...
На vcfed всплыла третья плата (две у меня) KDF11-B с микросборкой CIS. Вот даже не знаю - считать ли эту микросборку редкостью... :)
У нас редкость... С CIS скорее всего не закупали, да и не копировали, так как был Советский Союз в коем ну ни какой коммерции быть не должно...
У них не очень редкая вещица значит :)
У нас редкость
У них не очень редкая вещица значит
Когда первая микросборка всплал на ebay - слегка оболдел. Три штуки - где-то года за три. Продолжаю следить на ebay, но пока тишина. Про наш вариант - это надо специалистов по Воронежу трясти :)
С CIS скорее всего не закупали, да и не копировали, так как был Советский Союз в коем ну ни какой коммерции быть не должно...
"Коммерческий" - это слишком в лоб перевод. По сути, DEC сделала для ускорения программ на Коболе - коих в те времена писалось НЕМАЛО. У нас вроде бы тоже Кобол в те времена достаточно активно - не могу сказать, что использовался, но упомянался - да. На PDP-подобном столкнулся только один раз - где-то в райне 90-ого плюс-минус - в одной конторе использовали прогу на коболе - ЕМНИП - учёт материальных ценностей :) Там же столкнулся и с использованием (аналога?) DEC-овского пакета SORT. Ну и может чего form добавит :)
На Коболе много чего понаписано было да и сейчас кое-что до сих пор работает :)
В лоб, то в лоб... Но многие решения принимали с перекосом в идеологию, особенно, когда объяснить зачем сее надо сложно. Проблемы с компетенцией начальства :(
Вот назывался бы не коммерческий, а, типа, как какой-то, дополнительный набор типа - Auxilary Premium Instruction Set, то он присутствовал бы у нас :)
то он присутствовал бы у нас
Сейчас уже не скажешь :) Тем более, что надо было дополнительно как-то отреверсить шесть микросхем :)
На М6 физически нет места под любые расширения с самого начала. Куда его пихать-то? Да и раз штука и там редкая (а значит невостребованная), то у нас и подавно
На М6 физически нет места под любые расширения с самого начала.
На самом деле можно - если пожертвовать микросхемой FPP или диспетчером памяти :)
а значит невостребованная
Я бы не сказал, что это факт - поскольку
- существовало по крайне мере два варианта CIS - для PDP-11/44 и для PDP-11/74
- DEC даже сделала (облегченный) вариант для LSI-11 (581) - назывался DIS - под язык Dibol (некоторый аналог Cobol-а от DEC)
- насколько можно верить причастным к - сущестовал по крайне мере уже написанный микрокод CIS для J-11 и на самих J-11 есть посадочные места (с обратной стороны :) ) под ещё две микросхемы - и вроде как народ сходится во мнении - что в том числе и под это дело
- ну и на каком-то количестве моделей VAX-ов есть аналог CIS, но вроде как на PDP-11 более полный набор команд :)
То есть по крайне мере какое-то время востребованность была. Но - в специфических задачах. А потом это дело заглохло вместе с "умиранием" процесса написания нового софта на Коболе. Плюс - процессоры стали быстрее, а, как я понимаю - реализация CIS (или аналога) - ещё то занятие, так что сделали как сейчас - мы просто выпустим более быстрые проца и пусть программисты мучаются :)
Как оказалось, там не такая уж и редкая штука...
На коболе очень много чего понаписано было, всякий документооборот, бухгалтерия да прочая ...
У достопочтимого Hunta всё пихается и работает :)
На коболе очень много чего понаписано было
Почему, как я понимаю, в DEC CIS и сделали - думаю, ускорение будет реальным, но... я всё никак не доберусь до их Кобола, что сравнить с CIS и без CIS быстродействие :) А писать самому, скажем, умножение двух 15-ти циферных десятичных числа... Да и не факт, я уж такой супер-скоростной код напишу :)
У достопочтимого Hunta всё пихается и работает
Просто потому что у меня не М6 (или её первородитель KDF11-A) - половинчатая плата, хотя и эти есть, так что по крайне мере в KDF11-A можно попробовать запихать), а KDF11-B - а на ней всё предусмотрено :) А её вроде как в Воронеже не сделали...
KDF11-B - а на ней всё предусмотрено А её вроде как в Воронеже не сделали...
М9
Фотография есть?
Фотографии нет.
Фотографии нет.
Тогда это только догадки.
Тогда это только догадки.
догадки - аргументированные.
https://phantom.sannata.org/viewtopic.php?f=33&t=14616&start=77
А Ваши догадки, что Электроника-79 - точная копия PDP-11/70 - разве не догадки, причем бездоказательные (т.к. документации на 79ю пока нет).
догадки - аргументированные.
Я уже ржу :D
Читайте внимательней, речь шла о KDF11-B, а не о KDJ11-B
И остальное про М9 там тоже - догадки сплошняком.
Так что пока о том, что была копия KDF11-B - даже догадок нет.
А Ваши догадки, что Электроника-79 - точная копия PDP-11/70 - разве не догадки
Я её в живую щупал.
Я уже ржу :D
Читайте внимательней, речь шла о KDF11-B, а не о KDJ11-B
И остальное про М9 там тоже - догадки сплошняком.
Так что пока о том, что была копия KDF11-B - даже догадок нет.
повторите, как это сделал я, анализ различных исполнений МС0108, вычислите состав М9 и попытайтесь догадаться как она выглядит,
тогда и смейтесь.
Кстати - имел беседу с разработчиком М11, он мало что помнит, но сказал, что разрабатывал плату с 1831 для PC (фото чего-то такого где-то мне попадалось)
Я её в живую щупал.
и что нащупали ? ( по железу, а не то как она виртуально представляется программистам ).
вычислите состав М9 и попытайтесь догадаться как она выглядит,
Ещё раз об особо одарённых. Речь в данном контексте шла о KDF11-B, а не KDJ11-B
Буквы внимательней поразглядывайте.
по железу
Именно по железу, а не так, как она представляется гадателям на кофейной гуше.
Речь в данном контексте шла о KDF11-B, а не KDJ11-B
Буквы внимательней поразглядывайте.
внимательно посмотрите - на моем муляже 1811, а не 1831.
Именно по железу
расскажите, пожалуйста, подробно - что Вы увидели по железу, ведь внутрь Электроники-79 никто, кроме Вас не заглядывал и многим будет интересно.
Кстати - а PDP-11/70 не "щупали" ? (что бы сравнивать)
внимательно посмотрите - на моем муляже 1811, а не 1831.
"Я уже начинаю сомневаться, но я в те годы видел процессор на 1831 с ОЗУ и терминальными портами на одной плате, наверное - М9."
А муляж слепить можно любой.
ведь внутрь Электроники-79 никто, кроме Вас не заглядывал и многим будет интересно.
То есть то, что там была команда электрронщиков и программистов - это действительно - никто.
И дальше - все свои догадки насчёт М9 - в своих темах. И пока не будет фотографий реальных М9 - свои муляжи - туда же.
Это тема - не про ваши догадки.
Добавилось ещё три микросборки (не мои :D ) в число известных мне микросборок CIS
За бугром не такая уж и редкость была, раз дожили до нашего времени в таком количестве :)
Ну за бугром то понятно. Теперь возникает вопрос - а у нас то (в то время) были? :)
- - - Добавлено - - -
Скачал себе фотки. На одной не очень видно напечатнное на микросборке, на другой (с тремя) вроде всё отлично видно. Вечером после работы ещё гляну - чего там :)
Ещё две - итого восемь :)
Эх ёёёёё..... https://www.ebay.com/itm/225875574424 - похоже - DIS всплыл на ebay.... ЖЖЖЖЖЖЖЖ!!!!
Как всплыл, так и уплыл... Увы.. не ко мне..
- - - Добавлено - - -
Если судить по тестам, то DIS - это
ADDN 076050
SUBN 076051
CMPN 076052
CVTNL 076053
MOVC 076030
MOVRC 076031
CMPC 076044
LOCC 076040
SKPC 076041
SCANC 076042
SPANC 076043
- - - Добавлено - - -
Захотелось, как обычно, странного :)
Итак - запуск тестов DIS на PDP-11 с CIS
VKAIB0
Первая и вторая правки - обход проверки неверных для DIS (верных для CIS) кодов
Третья правка - обход проверки прерываемости DIS инструкций (пока не понял - что не так).
BOOTING UP XXDP-XM EXTENDED MONITOR
XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM DU4
124KW OF MEMORY
NON-UNIBUS SYSTEM
RESTART ADDRESS: 152000
TYPE "H" FOR HELP !
.L VKAIB0
VKAIB0.BIN
.
112330
@3556/004567 137
003560/010466 3656
@7622/004567 137
007624/004422 7722
@14520/001004 404
@200G
CVKAIB
END PASS
END PASS
END PASS
END PASS
END PASS
END PASS
END PASS
END PASS
END PASS
END PASS
END PASS
END PASS
END PASS
010552
@
Второй тест немного позже.
- - - Добавлено - - -
Второй тест отрабатывает хуже. Традиционное выключениe проверки прерываемости и:
VKAJB0
BOOTED FROM DU4
124KW OF MEMORY
NON-UNIBUS SYSTEM
RESTART ADDRESS: 152000
TYPE "H" FOR HELP !
.L VKAJB0
VKAJB0.BIN
.
112330
@15126/001004 404
@200G
CVKAJB
001376 ; TEST 1 ADDN
001660 ; TEST 2 ADDN
002142 ; TEST 3 ADDN
002424 ; TEST 4 ADDN
005274 ; TEST 16 ADDN
013260 ; TEST 46 CVTNL
013304 ; TEST 46 CVTNL
013314 ; TEST 46 CVTNL
013610 ; TEST 50 CVTNL
013764 ; TEST 51 CVTNL
END PASS
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot