Великий знаток ретрокомпьютинга Куздра
Feb. 23rd, 2013 03:45 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
pargentumкак выясняется, ничего не слышал о том, что собой представляли PDP от 1 до 10 включительно. Судя по вот этой реплике, история DEC для него началась с PDP-11.
Как я понимаю, главной причиной выбора 8-битных байтов в System/360, и, позднее, в Intel 8008 было то, что в 8 бит влезают две десятичных цифры, а у PDP-11 и VAX - упрощение конверсии данных при обмене оными с System/360.
Как я понимаю, главной причиной выбора 8-битных байтов в System/360, и, позднее, в Intel 8008 было то, что в 8 бит влезают две десятичных цифры, а у PDP-11 и VAX - упрощение конверсии данных при обмене оными с System/360.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-02-23 12:05 pm (UTC)no subject
Date: 2013-02-23 01:02 pm (UTC)no subject
Date: 2013-02-23 01:06 pm (UTC)no subject
Date: 2013-02-23 01:52 pm (UTC)no subject
Date: 2013-02-23 02:14 pm (UTC)Корреляция не определяет направление причинности и вообще ее не подразумевает. Причиной 16-битности PDP-11 как я уже уточнил - была конкуренция с DG NOVA. Но есть большое сомнение, что причиной того что DEC за 1 год перекрыла DG по продажам этой модели в 3 разы была 16-битность и 8-битноость-байтововсть.
Может просто все-таки архитектура оказалась удачной?
no subject
Date: 2013-02-23 03:01 pm (UTC)no subject
Date: 2013-02-23 03:04 pm (UTC)no subject
Date: 2013-02-23 03:29 pm (UTC)Во-вторых, у PDP-7, PDP-8 и PDP-10 с проверенностью архитектуры и развитостью сообщества на начало 70х все было гораздо лучше - однако названные архитектуры это не спасло.
no subject
Date: 2013-02-23 03:38 pm (UTC)Но вот 8-битный байт к таковым точно не относится - зато относится к явным недостаткам - именно потому что "64 к". При этом желания вернуться на PDP-8 почему-то не было (равно как и острого желания немедленно перелезть на x86).
Я конечно могу допустить, что народ был так щастлив от 8-битного байта что аж есть ничего другого не мог - но мне это не понятно - особенно в разрезе совместимости с S/360 и ее замечательнейшей кодировкой EBCDIC (где количество битов мягко гря не главное)
no subject
Date: 2013-02-23 04:23 pm (UTC)no subject
Date: 2013-02-23 04:27 pm (UTC)Зато вот ее 16-битность была перманентным геморроем - просто потому что память есть, а возможности ее человечески использовать - нет. Причем разница 64-256 под один процесс тут как раз критична.
no subject
Date: 2013-02-23 04:59 pm (UTC)1. Простота обмена данными с System/360 - не только текстовыми, но и числовыми
2. Удобное представление двоично-десятичных чисел
3. Значительное упрощение переноса программного обеспечения.
no subject
Date: 2013-02-23 05:32 pm (UTC)2. На PDP-11 ни разу не встречал (а вот ее софта я видел очень много)
3. Какого? Ну хоть один пример?
no subject
Date: 2013-02-24 05:13 am (UTC)1.1 PDP - она, если вы не помните, и не тупо-, и не остроконечная. Даже специальный термин такой есть - PDP-endian.
2. Ну просто с задачами с такмим не сталкивались. Хотя до появления SQL вся бухгалтерия и большая часть баз данных жила на BCD, потому что 32- и даже 36- значных целых диапазона представления не хватает, а считать надо до копейки. У x86, кстати, до сих пор и сопроцессор умеет делать операции над BCD, и команда десятичной коррекции на основном процессоре сохранилась.
3. CERNLib
no subject
Date: 2013-02-24 09:07 am (UTC)1.1 Мучительно вспоминал где там вообще 32-битные слова в архитектуре?
2. Я не грю что с двоичной-десятичной арифметикой не сталкивался (да хоть кобол-PLI) - я о том что ни разу таковой на PDP-11 не наблюдал.
3. Ээээ - с тогдашней адаптированностью фортранного софта к вовсе экзотическим разрядностям? Тогда же байтовая архитектура (не гря уж о разрядности байта) ни разу не стандарт - это именно нововведение.
no subject
Date: 2013-02-24 10:12 am (UTC)1.1. Команда mul. Она, правда, регистровая, но регистры-то потом все равно в память надо складывать. Так или иначе, все компиляторы лонги складывали именно в mixed-endian виде.
2. То есть не решали соответствующих задач на PDP-11. Ну и о чем дискуссия?
3. Адаптировать софт так, чтобы он одинаково учитывал ошибки округления? Не так-то просто, не случайно потом стандартизовали не только набор длин целочисленных типов, но и формат чисел с плавающей точкой (IEEE754).
no subject
Date: 2013-02-24 10:21 am (UTC)1.1 Гм - какая разница в каком порядке регистры в память складывать-то? Особенно на этой изумительно ортогональной архитектуре
2. Не только не решал - но и не видел. А разнообразного софта я видел под эту машину много - слово DECUS вам что-то грит?
3. Разумеется - только вот не является в 1970-м S/360 основной вычислительной платформой - и это совершенно дежурный гимор, к которому все привыкли и от которого никакая разрядность не убережет.
Я это к тому что "следование стандартам" - конечно аргумент - но вот как раз стандарта-то и не было - и PDP-11 - как раз одна из двух архитектур этот стандарт тогда и задавших.
no subject
Date: 2013-02-24 10:52 am (UTC)1.1. Разницы никакой, но на уровне компилятора соглашение нужно, и при передаче бинарных данных оно тоже вылезает. И у всех компиляторов на PDP-11 оно именно PDP-endian.
2. Извините, я не офтальмолог, и разбираться, что и почему вы не видели - не моя сфера компетенции
3. Является.
А стандарт IEEE 754 был принят через много лет после PDP-11, и PDP-11 FPU ему не соответствует. Но тем не менее, сам факт принятия этого стандарта свидетельствует о том, что проблема при переносе софта между платформами с разной разрядностью существует.
no subject
Date: 2013-02-24 11:06 am (UTC)3. И какой % они тогда составляют в общем вычпарке? (я кстати не знаю) И обращу ваше внимание - что в качестве кодировки на PDP-11 принят был ASCII, а не IBM-овский EBCDIC. Хотя EBCDIC бы как раз сильно облегчил бы "обмен информацией"
Ну и по конечности совместимостью как я отметил не озаботились.
no subject
Date: 2013-02-24 11:36 am (UTC)3. By 1965 IBM had a 65.3-percent market share of the industry. The seven dwarfs shared the rest. They were: Burroughs, Sperry Rand (formerly Remington Rand), Control Data, Honeywell, General Electric, RCA and NCR. - никакого DEC, что характерно. К 1970 году положение вряд ли существенно изменилось, потому что в 1969 году против IBM подали антимонопольный иск.
Конверсия ебсдика в аски и обратно возможна достаточно тривиальной трансляцией по таблице, и конверсия конечности тоже задача для программиста вашего уровня. А вот трансляция чисел некратной разрядности - это "поебаться по настоящему" (с) анекдот про танкистов и фею.
no subject
Date: 2013-02-24 10:56 am (UTC)Стандарт задала одна архитектура - IBM 360. В мини-микрокомпьютинговом мире было три очень близких по времени по времени попытки присоединения к этому стандарту - упоминавшаяся вами DG Nova (1969), PDP-11 (1970) и 8008 (1972). Две из этих трех попыток мы задним числом видим как весьма успешные. Но стандарт был задан шестью годами раньше.
no subject
Date: 2013-02-24 11:08 am (UTC)no subject
Date: 2013-02-24 11:24 am (UTC)А что за ужас 4Кб адресации? Вы бы еще про ужас 256-байт адресации на x86 рассказали, бугога. У большинства RISC-процессоров адресные смещения в команде тоже далеко не 32 бита, и ничего, народ особо не жалуется.
no subject
Date: 2013-02-24 11:31 am (UTC)А что за ужас 4Кб адресации?
То что все (включая переменные со статическим адресом) требует индексного регистра, наведенного на нужный диапазон. На x86 напомню - вы можете обратиться по любому адресу в пределах 64k (хотя там это тоже жопа).
no subject
Date: 2013-02-24 12:20 pm (UTC)А если в вашей программе больше 4кб скалярных статических переменных - мне кажется, у вас есть проблемы посерьезнее, чем адресация.
На x86 для данных есть два типа смещений: байтовое и 32-битное (это если не извращаться с префиксами), 16-битные смещения - это 8086/286.
Вы лучше посмотрите, как на RISC-процессорах 32-битный литерал в регистр грузят, я уж не говорю про 64-битный. И ниче, живут как-то.
no subject
Date: 2013-02-24 12:24 pm (UTC)no subject
Date: 2013-02-24 01:16 pm (UTC)no subject
Date: 2013-02-24 01:27 pm (UTC)для современного состояния этой отрасли науки, оптимизировать размещение регистров в такой ситуации - задача относительно простая
Для современного - конечно да. Но оно опять завязано и на технику компиляции - которой тогда просто не существует. И под ресурсы под эту технику - которых тогда нет просто физически.
А уж если учесть что код компилятора обычно написанн в лучшем случае на ассмеблере.
no subject
Date: 2013-02-24 01:33 pm (UTC)no subject
Date: 2013-02-24 01:36 pm (UTC)no subject
Date: 2013-02-24 01:40 pm (UTC)Если все писать на ЯВУ, то, по большому счету, неважно, какого размера байт, главное, чтобы он был везде одинаковый.
no subject
Date: 2013-02-24 01:47 pm (UTC)Совершенно не надо как раз - на Жабе вы хоть где-то про байт вспоминаете или про -кнечность? Нет есть места - но не очень важные.
Там в том и фишка, что езык тут как раз может выступить в качестве киллера байта - бо запрос на абстрагирование от как раз крайне актуально.
no subject
Date: 2013-02-24 02:07 pm (UTC)no subject
Date: 2013-02-23 07:43 pm (UTC)no subject
Date: 2013-02-24 04:58 am (UTC)У PDP 6/10, насколько я знаю, для хранения текста использовались 7-битные байты, как раз пять байт входило в слово.
У PDP-11 был формат 6 5-битных символов RADIX в двойном слове (имена файлов в RT-11 в таком виде хранились).
no subject
Date: 2013-02-24 09:21 am (UTC)no subject
Date: 2013-02-24 10:07 am (UTC)no subject
Date: 2013-02-24 09:09 am (UTC)