Про Motorola, IBM, DEC, ...

[HardWareMan]

Писал про реальное быстродействие, которое этими тактами просчитывается. Вы не ответили на вопрос, отличник! Похоже и вам двойка. Нет тут отличников.

36 лет назад, когда я был в первом классе, за мной уже закрепляли двоечника. И уже тогда я понял - нельзя двоечников вытягивать, им это не надо. Более того, их надо сразу в профкласс и на урановые рудники. Так пользы больше и государство сэкономит большие деньги. Это моё личное мнение.

Далее, вот ты писал:

Спасибо, отличнику! Но как он такой умный объяснит, что MOV из памяти выполняется на 80286 выпоняется всегда за 3 такта, а на 68030 за от 5 до 42 (если повезет с кэшем, то от 3 до 30).

Посмотрим в букварь

[свернуть]

Оказывается, что не всегда 3, верно?

А потом заглянем туда, куда двоечники никогда не смотрят

[свернуть]

Т.е., эти самые CLK, указанные рядом с инструкцией, на самом деле PROC CLK, про который я говорил здесь. И это внутренняя частота, которая является /2 от внешней, настоящей CLK. Таким образом, PROC CLK по сути тактовая частота шины, можно приравнять по смыслу к частоте того же M6502, который каждый такт делает обращение к шине. Но при этом, процессор 80286 работает на удвоенной частоте, в отличии от 6502. А раз так, то 3 шинных цикла вполне логично для команды, работающей с памятью. И теперь абсолютно понятно, почему в маркетинге любят PROC CLK а не CLK: проц по факту работает на удвоенной частоте, FIFO PIPLINE у 286 еще с 8086 остался, так что занизим заявленную частоту, чтобы в датащитах красиво смотрелись тайминги по сравнению с конкурентами.
Моторолла, кстати, оперирует не тактами а состояниями.

Например, чтение шины без ожидания занимает 8 состояний или 4 честных такта

[свернуть]

При этом, тайминги инструкций указаны именно в периодах (тактах) честной внешней частоты в обоих режимах:

Скрытый текст

[свернуть]

Что вполне логично выливается в +4 такта на каждое обращение к шине:

Скрытый текст

[свернуть]

Так что для прямого сравнения 286 и 68000 надо либо умножать такты на 2 у первого, либо делить на 4 у второго.


Шах и мат. Теперь я буду только читать твои потуги под попкорн.

[AFZ]

непрямая работа - оверлеи, резидентные в памяти - в RSX. Вроде что то подобные было и в XM мониторе

Подтверждаю. ХМ-монитор вполне поддерживает оверлеи, резидентные в верхней памяти. И остальные два подхода тоже. Более того, не удивлюсь, если узнаю, что эти три подхода впервые были сочинены для ХМ, а в RSX перенесены. Хотя, скорее всего, над этим работали параллельно: группа разработки ДП сочинила и выдала рекомендации, а группы разработки ОС эти рекомендации воплотили.

учитывая его убогую многозадачность, я RT практически не использую

Есть еще и TSX-11, у которой многозадачность нормальная - на каждом рабочем месте юзер может считать, что у него главная консоль RT-11XM - все ХМ-ные фенечки поддерживаются, кроме той самой убогой ХМ-ной многозадачности, которая в нормальной многозадачной ОС и даром не нужна (вроде-бы, точно не помню, ни разу ей не интересовался в силу ее убогости). Правда, TSX-11 не DEC-овская разработка, но MS-DOS тоже не межделмашевская. Родная ОС от IBM - OS/2 - увы, не состоялась.

-------------------------------------------

А вообще, как сказал Говорящий Клоп, "все это - хорошо оплачиваемый вздор, а на самом деле Вселенная имеет форму пружинного матраса".

Те, кто в курсе, не спорят, что по состоянию на начало 80-х PDP-11 была лучшей 16-разрядной машинкой, и "феномен IBM PC" имел место быть только потому, что руководство и IBM, и DEC относились к самой идее персонального компьютера с глубочайшим презрением. Мол, модные игрушки, мода пройдет, а наши изделия останутся...

А тема началась с моего заявления, что 68000 не состоялся потому, что не он был выбран Межделмашем в ЦП для писюка. Все тут же полезли в детали, с пеной у рта доказывая, что интелёвые процессоры лучше - быстрее, удобнее для программирования и т.п. Забывая о том, что 68000 надо сравнивать не с 80386, и даже не с 80286, а с 8088 (не 86!). Именно между ними стоял выбор у Межделмаша.

А дальше - дело в конкуренции. На рынке писюков конкуренция была высочайшей, мамаши для них клепали все, кому было не лень, процессоры тоже, как минимум, 3 производителя. Неудивительно, что параметры и процессоров и компьютеров на них росли, как на дрожжах, и цены падали до бросовых. Напротив, и 68000 делали одни мотороллеры, и клонмейкеров для компов на них, практически не было - те же надгрызенные жестко запатентовали все свои разработки и клонмейкерства не допускали. И, как результат, сдулись полностью, сейчас их Мак - это разновидность писюка. Равно, как и мотороллеры - нет процессоров 680х0, где-то в контроллерах они еще применяются иногда, а так, увы...

[Hunta]

Есть еще и TSX-11, у которой многозадачность нормальная

Но не файловая система. Поэтому, поигравшись в своё время с TSX на Кванте (память упорно грызёт, что при более менее активной работой с диском отзывчивость системы была хуже, чем у RSX. Возможно, ошибаюсь), я перенёс RSX-11M-Plus 4.0 и дальше все варианты игр с RT были с флопов.

Напротив, и 68000 делали одни мотороллеры, и клонмейкеров для компов на них, практически не было - те же надгрызенные жестко запатентовали все свои разработки и клонмейкерства не допускали.

На самом деле, ровно такая же ситуация и у DEC - там вроде даже по лицензии то ли нельзя было делать, то ли с большими сложностями. Ну и как монополист, DEC, соответственно, "несколько" завышала цены

[yuriy_sazonov]

Доброго !

... процессоры тоже, как минимум, 3 производителя. Неудивительно, что параметры и процессоров и компьютеров на них росли, как на дрожжах, и цены падали до бросовых. Напротив, и 68000 делали одни мотороллеры, и клонмейкеров для компов на них, практически не было ...

Ну не... мотороллеров тоже выпускалось разными производителями много. На достаточно известном сайте можно посмотреть, даже с картинками www.cpu-world.com без этого как-то не полно...
В одном из компьютеров (которые есть у меня) производства 1986г. стоит чип от Signetics

[Hunta]

интелёвые процессоры лучше - .... удобнее для программирования

И даже сейчас это - полная хрень

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

А вот макро-11 даже просчитать сдвинутый переход вперед не может - все известные мне ассемблеры для х86 и других систем могут.

И вперёд и назад

[* КОНЕЦ СТРАНИЦЫ *]


      1                                         .TITLE  SH
      2                                         .MCALL  EXIT$S
      3                                         .ENABL  LSB
      4 000000                          START:
      5 000000  000421                          BR      20$
      6 000002                                  .BLKW   10
      7 000022                          10$:
      8 000022  000421                          BR      30$
      9 000024                                  .BLKW   10
     10 000044                          20$:
     11 000044  000766                          BR      10$
     12 000046                                  .BLKW   10
     13 000066                          30$:
     14 000066                                  EXIT$S
     15         000000'                         .END    START
[* КОНЕЦ СТРАНИЦЫ *]
Symbol table

START   000000R

. ABS.  000000    000   (RW,I,GBL,ABS,OVR)
        000074    001   (RW,I,LCL,REL,CON)
Errors detected:  0

*** Assembler statistics


Work  file  reads: 0
Work  file writes: 0
Size of work file: 201 Words  ( 1 Pages)
Size of core pool: 13506 Words  ( 51 Pages)
Operating  system: RSX-11M/M-PLUS
Elapsed time: 00:00:00.01
SH;1,TMP;1/-SP/NL:TTM=SH
[* КОНЕЦ ТЕКСТА *]

[AFZ]

Ну не... мотороллеров тоже выпускалось разными производителями много.

Поразглядывал картинки и почитал к ним описания. Очень похоже, что это произведено по лицензии от Моторолы, по широко применяемой в то время программе вторых поставщиков. А не самостоятельные изделия "по мотивам", как это было у АМД и Cyrix. Но, по-любому, спрос на интелёвые и совместимые с ними процессоры был намного больше, чем на мотороллеры, соответственно, они и развивались заметно быстрее. И, в итоге, 680х0 банально сдулись, нет их...

На самом деле, ровно такая же ситуация и у DEC - там вроде даже по лицензии то ли нельзя было делать, то ли с большими сложностями. Ну и как монополист, DEC, соответственно, "несколько" завышала цены

Вот-вот, и я о том же. Зажрались, зажирели, и, в итоге, пролетели. Очередной повод задуматься на тему: вред наносит пиратство, или пользу? То есть да, владельцу авторских (или каких там еще) прав, пиратство - чистый убыток, а вот рядовому юзеру - только плюс, и сейчас, и в перспективе. Мораль - бей копирастов!

И даже сейчас это - полная хрень

Так вестимо! Конфетку из говна, конечно, сделать можно, только вот запах...

[Advertiser]

[litwr]

36 лет назад, когда я был в первом классе, за мной уже закрепляли двоечника. И уже тогда я понял - нельзя двоечников вытягивать, им это не надо. Более того, их надо сразу в профкласс и на урановые рудники. Так пользы больше и государство сэкономит большие деньги. Это моё личное мнение.

Типа употребили хорошо крепленного пивка и мысли светлые пошли?

[Посмотрим в букварь]
Оказывается, что не всегда 3, верно?

Ну описался чуть-чуть. Робот бы сказал 3 такта занимают команды записи и 5 чтения. Человек в непринужденной беседе может и слегка сбиться. Однако, как уже писал уважаемому Lethargeek, команда MOVS занимает 5 тактов, а это чтение из памяти, запись в память, работа с индексными регистрами, ...

[А потом заглянем туда, куда двоечники никогда не смотрят]
Т.е., эти самые CLK, указанные рядом с инструкцией, на самом деле PROC CLK, про который я говорил здесь. И это внутренняя частота, которая является /2 от внешней, настоящей CLK. Таким образом, PROC CLK по сути тактовая частота шины, можно приравнять по смыслу к частоте того же M6502, который каждый такт делает обращение к шине. Но при этом, процессор 80286 работает на удвоенной частоте, в отличии от 6502. А раз так, то 3 шинных цикла вполне логично для команды, работающей с памятью. И теперь абсолютно понятно, почему в маркетинге любят PROC CLK а не CLK: проц по факту работает на удвоенной частоте, FIFO PIPLINE у 286 еще с 8086 остался, так что занизим заявленную частоту, чтобы в датащитах красиво смотрелись тайминги по сравнению с конкурентами.
Моторолла, кстати, оперирует не тактами а состояниями.

Начало интересное. Про этот лишний такт у двойной индексной даже и не встречал наверное раньше информации. Премного благодарен. Хотелось бы ещё ссылку на первоисточник. Но вот дальше опять пошли светлый мысли. И где же вы на старых первых писюках видели частоты 12 или 16 МГц вместо 6 и 8? Частота кварца и процессора - это вещи разные и иногда в разы разные. Далее следует маленький расчет по пи-затвору (счет циклов есть в исходниках по процессорам 8088, 80186, 80286, 80386). Главный цикл программы для 80286 занисает 98 тактов. Число циклов для расчета 3000 цифр числа π находим из формулы 7*(4+3000)*3000/16. Полученное число умножаем на 98 и делим на 6 миллионов (6 МГц), получаем 64.4 секунды. Смотрим на данные из таблицы по XT/286 (там память без задержек). Там на 100 цифрах скорость 0.11 секунды, что означает, что сам вывод 3000 цифр в этой системе проходит примерно за 3 секунды. Итого получаем примерно 67.4 секунды. Данные с аппаратуры 71 секунда. Имеем разницу в 5%, которую можно объяснить задержками очереди команд и системной активностью. В вашем великолепном приведенном тексте говорится именно о такой 5-10% разнице. Подумаем чуть больше. Очередь команд у 80286 работает со скоростью не меньшей байт за два такта. Когда-то считал циклы для 68000 - там тоже все как на бумаге. А вам уважаемый, опять двойка. Стране нужен уран. А чтобы было веселее употреблять, вам на бонус песенка.

https://www.youtube.com/watch?v=jvyqO-1eT_4

[litwr]

Тогда не несите чушь и слушайте, что говорят те, кто работает с RSX с 84-ого года.

Слушают вас, уважаемый. Только не могли бы дать ссылки на свои программы? Вот у меня под пдп-11 архитектуру есть 3 больших проекта (кросс-компилятор бейсика, лаборатория клеточных автоматов, текстовый редактор) и один маленький (π-затвор).

Запросы к ядру

Оно и понятно.

Вообще то первый уровень - это каталог [0,0]. Рабочие каталоги - это уже второй уровень. Файловая система ODS-1. Третий уровень делали в P/OS. Поддержка третьего и дальше уровней штатно - ODS-2 и выше. Не могу сказать точно, почему не сделали, но судя по тому что я виде в исходниках VMS - это слишком ресурсно-затратно для тех времён. Хотя у меня есть мысль - добавить это дело на современных процессорах PDP-11

Если корень считать за уровень, то все файловые системы поддерживают каталоги. RSX-11 нет поддержки нормальной подкаталогов, в отличие от VMS. Добавить можно, но фирменного софта для этого нет. BQT сам такое написал - можете у него спросить - должен поделиться - зачем опять колесо изобретать?

Продвинутый пользователь перенес на неё RSX примерно лет за 10 до того, как на этом форуме поднялся вопрос (и долго муссировался), что RSX на ВМ3 не заработает, потому что в нём ошибки. Хорошо, что я примерно так в 91-92 годах об этом не подозревал и просто перенёс.

С этим Вам - респект.

Вы не спрашиваете. Вы утверждаете вещи, в которых не разбираетесь, по вашему же признанию

Уважаемый оппонент, давайте факты. Признаю, что считал, что с большими кодами поддержка в RSX-11 существенно похуже и разговор с вами помог мне с этим разобраться. Нашел даже некоторые большие файлы на серверах BQT: компилятор бейсика - DU:[3,54]BP2IC2.TSK (992 блоков), си-компилятор DU:[3,54]PDP11C.TSK (985 блоков)... Однако, базовый вопрос был о том, что получить более 64 КБ в PDP-11 системах - это намного сложнее и тормознее, чем в ДОСе. И всё, что вы сообщаете, это подтверждает.

А ничего, что первая RSX вышла в 74 году? Или тогда тоже ставили "много" памяти?

И первый ДОС вышел в 1981, когда по 64 КБ ставили. Думаю в это время на хорошие пдп-11 системы ставили уже все 4 метра, но для пользователя всё за пределами 64 кб получалось что-то типа памяти EMS для первых IBM PC, что-то типа продвинутого банкования.

Ещё одна полная хрень. Для RSX и XM монитора RT - отлично документировано и достаточно легко используется. Причём можно насчитать аж три подхода.

- прямая работа с соответствующими запросами к ядру системы
- непрямая работа - оверлеи, резидентные в памяти - в RSX. Вроде что то подобные было и в XM мониторе, но учитывая его убогую многозадачность, я RT практически не использую, поэтому сходу не могу не подтвердить, не опровергнутью
- массивы Virtual (теоретически - только под данные, но мы в своё время научились хитрить, но не получив от этого никакой пользы - для кода вернулись к пункту 2

Через прямые запросы к ядру много не наработаешь - хлопотно очень. Оверлеи - там надо со сценариями компоновщика колдовать (хотя некоторые компиляторы могут с этим помочь) и сама система очень тормознутая с множеством ограничений. Помню с чем-то таким на СР/М сталкивался. А для примитивной СР/М были даже хорошие электронные таблицы, которых на пдп-11 почему-то не хватило.

Могу ещё вам, эксперту (хотя скорее только опытному пользователю), кое-что подсказать. Можно ещё создавать отдельный сегмент для данных и получать адресуемых 128 КБ на процесс, но возможно ВМ3 этого не поддерживает, а KB11 и J11 поддерживают. Кроме того, есть ещё путанная возможность компоновать разделяемые библиотеки с исполняемой программой - плохо представляю, что это такое - разбирайтесь сами. Ещё есть что-то типа маппинга памяти - это как-то связано с виртуальными массивами - работать это должно очень небыстро. Осмелюсь предположить, что Х86 с перезагрузкой сегментного регистра для работы с большими массивами тут окажется на порядок или даже больше быстрее.

Хотя да, поскольку создатели Unix поделок шли каким-то своим тёмным путём - возможно, в Unix это так и осталось тёмным шаманством.

И Юникс не уважаете?

Те, кто в курсе, не спорят, что по состоянию на начало 80-х PDP-11 была лучшей 16-разрядной машинкой, и "феномен IBM PC" имел место быть только потому, что руководство и IBM, и DEC относились к самой идее персонального компьютера с глубочайшим презрением. Мол, модные игрушки, мода пройдет, а наши изделия останутся...

Уже были недешёвые системы на 68000 и в Штатах было много всего другого, но возможно по совокупности полезных свойств пдп-11 и был лучшей такой системой до года 83-84. По поводу презрения - сомневаюсь. Скорее чувствовали угрозу своему основному бизнесу (персоналки с конца 70-х пошли быстро растущей массой). IBM до PC сделала довольно популярный DataCenter, потом уже после PC какой-то комп на 68000, возможно ещё что-то. Повторю для вас, главная тема - это открытая архитектура IBM PC, так никогда раньше не делали. Чтобы не повторяться дам ссылку, там всё довольно конкретно - https://www.quora.com/Why-did-IBM-PC...Travis-Casey-4

А тема началась с моего заявления, что 68000 не состоялся потому, что не он был выбран Межделмашем в ЦП для писюка. Все тут же полезли в детали, с пеной у рта доказывая, что интелёвые процессоры лучше - быстрее, удобнее для программирования и т.п. Забывая о том, что 68000 надо сравнивать не с 80386, и даже не с 80286, а с 8088 (не 86!). Именно между ними стоял выбор у Межделмаша.

Отстали мотороловцы, не было никакого выбора. Получилось у них позже, чем надо, и дороже, чем надо. Тупили они всегда много и с своими 8-битками и с 68к, много копировали, рекламировали, а про дело забывали. По мне 68000 был их реально лучший процессор, если сравнивать его относительно других, имевшихся тогда. В 1982 он начал теснить 8086/8088, но пришли 80286 и 80186...

И вперёд и назад

Ну если бы такое не сработало, но мы бы с вами ничего не знали про макро-11 и всю архитектуру пдп-11. Речь была о более сложном случае. Нужен макрос, который бы раскрывался в BR, когда переход короткий и в JMP, когда длинный. Его несложно написать, но он работает только для переходов назад, для переходов вперед он неправильно считает смещение.

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

странная какая конверсия в перевёрнутую строку, но ладно уж
только по-честному вместо mov для загрузки адреса буфера надо бы использовать lds
да и параметры в регистры dx:ax тоже как-то попадают сперва из памяти

но самое смешное, что код arm2, оптимизированный на скорость (~18 тактов на итерацию!) занимает не так чтобы очень много - 56 байт
а если вызывать деление процедурой (каковая всё равно еще где-нибудь в большой программе будет нужна) - только 20 байт

Что-то тупите, уважаемый. Передавать параметры в регистрах - штука обычная. А про арм-код не понял, где он? У арм2 нет аппратного деления, поэтому подобный код для арма должен быть весьма большим, сомневаюсь, что 56 байт хватит.

не-не-не, ничего такого там НЕ написано! первая часть:

...говорит о неких абстрактных "рисках", а вторая:

...говорит о том, что конкретно арм способен ОПРОВЕРГНУТЬ (дословно: "перевернуть") это предположение!

Похоже нужен урок английского. сode density is less so an application in RISC is likely to consume more memory than the equivalent in CISC - переводится как "плотность кодов [у RISC] - МЕНЬШЕ, так что приложение для RISC cкорее всего потребит больше памяти, чем эквивалентное для CISC". however the ARM has a few tricks up its sleeve to reverse this assumption - "однако, АРМ имеет несколько трюков в рукаве, которые могут опровергнуть это предположение"

это ссылка на исследование качества компиляторов 2010-х годов, причём после долгих лет застоя на поле арма

Я встречал и другие с примерно теми же результатами. 2010-е - это не 90-е. Если у вас есть обратные данные, дайте ссылку, сам таких не встречал.

сомневаюсь, что все поголовно не сомневались, почитав, как реагировали амижники

Амиговцев понять можно - код 68000 довольно плотный, но армовцы никогда тут не спорили - зачем бы тогда нужно было Пальцы изобретать? Вот ссылка на мой материал по Арму - https://litwr.livejournal.com/2509.html -в комментах по плотности никто не отметился.

это то, что сделали ради мобильного рынка, где преобладали 16-битные шины, и на самом деле вовсе не для плотности, а для скорости

Почти везде, а может и везде про Пальцы пишут только как о способе повысить плотность кода. Хотя более плотные коды из-за лучшей утилизации кэша могут иметь и преимущества по скорости.

к тому времени амиги прекрасно закрывались самостоятельно в результате "эффективного менеджмента"

Менеджмент менеджментом, но отсутствие доступного по цене компа на 68к, способного запустить Дум - это тоже фактор.

нетушки, только половину этой роли они играют

Мне кажется, вы путаете понятие индексного и базового регистра. Сегменты х86 - никак не индексы, а только базы. В 68к адресные регистры базы могут быть использованы, пусть и с накладками, как индексы. Но писал про необходимую для всех операций с памятью базу. В 68к её надо задавать явно, в х86 она обычно присутствует неявно (можно задать префиксом для редкого случая). Конечно, с адресными регистрами можно работать более гибко, чем с сегментными. Но для простого задания базы - сегментные регистры х86 придуманы отлично.

вообще для знакомых с x86 архитектурой возня привычна, потому что программирование x86 - это и есть постоянная возня со ВСЕМИ регистрами

А как же без возни с регистрами?! Это общий момент программирования на ассемблере.

так, стопэ, а байты откуда брать? как без адресных регистров читать из памяти?

Это верно, отбросим один-два адресных 16-битных регистра для этих нужд и всё-равно у х86 получим 8 байтовых регистров и один-два парубайтовых. А пары байт можно брать и из стека, без адресных регистров (только SP).

как будто "пары байт" x86 для работы с байтами использовать очень просто - в основном обмен и временное хранение
но обмены есть и в 68000 - половинок регистров данных и целых регистров, включая адресные
что примерно так же можно применять для работы с байтами - и сколько тогда байтовой регистровой памяти?

почему это нельзя? из регистров данных можно грузить; и в арифметике и логике применять как байты-источники

Пары байт в х86 отлично работают, а вот 68000 не работают вообще. Там поменять местами байты в слове - это большой тормоз - быстрее из памяти оба байта достать. И с адресными регистрами 68к байты никак не пойдут - байты туда грузить нельзя, только слова, а слова только с четного адреса (для байт - не пойдёт). И даже если вы поместите два байта в адресный регистр, вам чтобы достать их для обработки потребуется больше тактов, чем загрузить их оба из памяти в регистры данных. Итого по 68к имеем 8 байтовых регистров и всё, а х86 имеет чуть, но больше.

ага, нормальный такой мультитаскинг, при котором over 95% наличного софта не работает, всё отлично

Вы опять про ДОС, который был ОДНОЗАДАЧНЫМ. Разработчики 80286 просто не могли знать про ДОС. Могу только удивляться оперативности Интел, который сделал поддержку многозадачности ДОС уже к 1985.

- наблюдаемая в объективной реальности over 95% амижных юзеров

У меня была Амига-500 с 1988 и экранчик Guru Meditation возникал очень даже нередко.

выключалку нужно написать один раз

О том и речь, маленький код сразу написал и готово. Не нужно текст набирать и потом такой хлам хранить, ассемблер запускать, ...

[Hunta]

Только не могли бы дать ссылки на свои программы?

И чем вам драйвера помогут?

Вот у меня под пдп-11 архитектуру есть 3 больших проекта

Раз за вас

Если корень считать за уровень, то все файловые системы поддерживают каталоги.

Не каталоги, а подкаталоги. И подкаталоги - не все. RSX поддерживает (один уровень подкаталогов), MS-DOS 1.0 и 2.0 - нет

Однако, базовый вопрос был о том, что получить более 64 КБ в PDP-11 системах - это намного сложнее и тормознее, чем в ДОСе.

Если проводить аналогию с MS-DOS (которая не берёт на себя управление памятью), то это будет RT-11 SJ монитор - на системе с ДП загрузка аналога сегментного регистра - ровно одна команда. И этих сегментных регистров - восемь штук. Да, безусловно, это сложнее и тормознее.
Под ОС, которые берут на себя управление ДП, что бы программы друг друга не порушили не передрались за память - как и под другими ОС, типа Windows или Unix - будет не одна команда и ремаппинг будет дольше. Плата за центральную власть.

И первый ДОС вышел в 1981, когда по 64 КБ ставили. Думаю в это время на хорошие пдп-11 системы ставили уже все 4 метра

А вы не думайте, а поищите факты.

Через прямые запросы к ядру много не наработаешь - хлопотно очень.

Вы пробовали? Я пробовал.

Оверлеи - там надо со сценариями компоновщика колдовать (хотя некоторые компиляторы могут с этим помочь) и сама система очень тормознутая с множеством ограничений.

Вы пробовали? Я пробовал. Особенно люблю оверлеи, резидентные в памяти. Почитайте про них - глядишь, кругозор и расшириться

были даже хорошие электронные таблицы, которых на пдп-11 почему-то не хватило.

Это вы не в курсе про DECUS и софт оттуда

Могу ещё вам, эксперту (хотя скорее только опытному пользователю), кое-что подсказать. Можно ещё создавать отдельный сегмент для данных и получать адресуемых 128 КБ на процесс, но возможно ВМ3 этого не поддерживает, а KB11 и J11 поддерживают.

Ну прям открытие. Ничего, что я знаю про это с тыща-девятьсот лохматого года, а вон рядом стоит плата DE10, на которой крутился PDP-2011 с поддержкой всего этого? А теперь открытие - под RSX-11M-PLUS на J-11 я легко сделаю 128 кб КОДА плюс 64 кб данных

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

Я эту возможность знаю и легко умею использовать с 1987 года плюс возможность одну разделяемую библиотеку компоновать с другой, плюс возможность любую из них размещать в любой странице ДП (спасибо PIC), плюс знаю как сделать возможным библиотеке обращаться к другой, без знания, с какого адреса она загружена. Просто надо знать RSX и уметь в ней работать.

Ещё есть что-то типа маппинга памяти - это как-то связано с виртуальными массивами - работать это должно очень небыстро.

И опять нулевые знания. Потому что для начала - с точностью до наоборот - виртуальные массивы связаны с возможностью менять маппинг страниц. И опять будет открытие, что компилятор с FORTAN-а поддерживает эти самые виртуальные массивы полностью прозрачно для программера

Осмелюсь предположить, что Х86 с перезагрузкой сегментного регистра для работы с большими массивами тут окажется на порядок или даже больше быстрее.

Осмеливаться будите, когда цифры приведёте - 8086 (1978 год) против PDP-11/70 (1974 год)

И Юникс не уважаете?

Ни в грош.

Ну если бы такое не сработало, но мы бы с вами ничего не знали про макро-11 и всю архитектуру пдп-11

Это на каком языке написано?

Нужен макрос, который бы раскрывался в BR, когда переход короткий и в JMP, когда длинный. Его несложно написать, но он работает только для переходов назад, для переходов вперед он неправильно считает смещение.

Учитывая, что компилятор MACRO-11 двухпроходной, на первом проходе он уже начинает расставлять команды по адресам и ему НУЖНО знать, сколько слов займёт команда, а на втором проходе он генерит код, учитывая, что BR (и её аналоги) занимает слово, а JMP слово или (обычно) два... Я могу сделать так, что бы генерировалось BR или JMP даже вперёд, но смысла из за особенностей MACRO-11 нет - BR займет два слова. Если же разбивать программу на небольшие подпрограммы - то BR хватит всегда

[litwr]

только по-честному вместо mov для загрузки адреса буфера надо бы использовать lds

LDS для работы с памятью, размером с десяток байт?!

И чем вам драйвера помогут?

Помогут, драйверы - это тоже программы.

Не каталоги, а подкаталоги. И подкаталоги - не все. RSX поддерживает (один уровень подкаталогов), MS-DOS 1.0 и 2.0 - нет

Было много пива? Каждый каталог, кроме корневого - подкаталог. А ДОС 2 очень даже каталоги поддерживает и на большую глубину. Вот специально для вас сделал снимок экрана - восхищайтесь - это Дос от 1982.

Если проводить аналогию с MS-DOS (которая не берёт на себя управление памятью), то это будет RT-11 SJ монитор - на системе с ДП загрузка аналога сегментного регистра - ровно одна команда. И этих сегментных регистров - восемь штук. Да, безусловно, это сложнее и тормознее.

Мы говорим о довольно редких вещах. Читал когда-то, что пытались использовать эти регистры базы с системой RT11 и были проблемы.

А вы не думайте, а поищите факты.

А что тут искать? Неужели заказчик не мог попросить 4 метра за свои деньги?!

Вы пробовали? Я пробовал.

Очень интересно. И сколько займет код для обращения байту в массиве из 70000 байт?

Вы пробовали? Я пробовал. Особенно люблю оверлеи, резидентные в памяти. Почитайте про них - глядишь, кругозор и расшириться

А что там такого особенного? Что-то типа использования EMS - банкуем странички.

Это вы не в курсе про DECUS и софт оттуда

Не нашел там электронных таблиц. Помогите.

Ну прям открытие. Ничего, что я знаю про это с тыща-девятьсот лохматого года, а вон рядом стоит плата DE10, на которой крутился PDP-2011 с поддержкой всего этого? А теперь открытие - под RSX-11M-PLUS на J-11 я легко сделаю 128 кб КОДА плюс 64 кб данных

Извините, но без вашей помощи не смогу понять, как можно 128 кб кода в 64 кб адресном пространстве.

Я эту возможность знаю и легко умею использовать с 1987 года плюс возможность одну разделяемую библиотеку компоновать с другой, плюс возможность любую из них размещать в любой странице ДП (спасибо PIC), плюс знаю как сделать возможным библиотеке обращаться к другой, без знания, с какого адреса она загружена. Просто надо знать RSX и уметь в ней работать.

Отлично, но об этом и предыдущем случае вы не упомянули.

Осмеливаться будите, когда цифры приведёте - 8086 (1978 год) против PDP-11/70 (1974 год)

Это про то, что 8086 гораздо более новая и продвинутая технология? Странная для Вас позиция, PDP-11 существено подороже и помощнее была. Только с 80286 (1982) началось технологическое отставание PDP-11. Цифры для PDP-11 не знаю, прошу тут Вашей помощи, а для х86 это лишняя загрузка сегментного регистра и обращение к памяти через префикс, т.е. чуть больше одной команды.

Ни в грош.

Так не долго и в маргиналы попасть.

Учитывая, что компилятор MACRO-11 двухпроходной, на первом проходе он уже начинает расставлять команды по адресам и ему НУЖНО знать, сколько слов займёт команда, а на втором проходе он генерит код, учитывая, что BR (и её аналоги) занимает слово, а JMP слово или (обычно) два... Я могу сделать так, что бы генерировалось BR или JMP даже вперёд, но смысла из за особенностей MACRO-11 нет - BR займет два слова. Если же разбивать программу на небольшие подпрограммы - то BR хватит всегда

BR займет два слова вместо одного?! И зачем такое нужно?! А макрос такой очень даже полезный для систем, где исторически и архитектурно, с памятью не густо. Но макро-11 не умеет.