в 8086 ELKS сделали работу с многосегментными прогами.

Ну теперь заживём

На системе ОСРВ для компа СМ-1420 (это вроде DEC PDP-11/70) были программы с «оверлеями». Программа автоматически подзагружала свой код с диска в память при выполнении. Памяти было 128 килослов по 2 байта каждое слово, а программы размером даже по мегабайту и более.

свап обычный

Не совсем, тут скорее получается какой-то статический MMU

Меня больше всего умиляет, что OpenWatcom, ELKS, 8086 ещё живы и ими ещё занимаются.

выше уже написали что это называется «оверлей» https://en.wikipedia.org/wiki/Overlay_(programming)

с появлением MMU и возможности свопа, виртуальная память заменила оверлеи

Нет. Программные оверлеи на уровне языка не похожи на свап. Там было ограничение, что процедура из одного оверлея не могла вызывать процедуру из другого оверлея, что не похоже на свап.

ещё живы и ими ещё занимаются

Занимаются и живы это разные вещи. Врачи в морге тоже занимаются.

вот кстати да, меня тоже что-то недавно на БК-шки потянуло. понастольгировать, чтоль.

прикольный там был ассемблер, в PDP-11. вот интересно, под БК-шки кроме BKUNIX ещё что-нибудь было подобное?

Чему нас научила PDP-11

Союз-Неон ПК-11/16: альтернативщина

эмуляторное – в конце треда аж два эмулятора запилили, раз и два

Союз-Неон ПК-11_16 архитектура — Emuverse

вот ещё на фпга пытаются возродить: тыц

ютубовое: ноль раз два демодуляция

hobot.pdp-11.ru…PK11_NEON

cм. также Downgrade № 17 от 2016 про интервью с Александром Гречишкиным об истории Союз-Неон ПК-11/16 : DowngradeN17.pdf

фпга бк-шка: emulyator-bk-0011m-na-esp8266

Программирование под БК 0010 в 2019-ом году

БК-0011М - Руководство системного программиста

воспоминания о БК

Эмуляторы БК раз и два на WASM прямо в браузере укнц

Ю.А. Зальцман, МИКРО-ЭВМ БК-0010. АРХИТЕКТУРА И ПРОГРАММИРОВАНИЕ НА ЯЗЫКЕ АССЕМБЛЕРА тыц

manwe

Союз-Неон ПК-11_16 архитектура — Emuverse

 РЕГИСТР УПРАВЛЕНИЯ ПАМЯТЬЮ MEMCSR ДОСТУПЕН  В	 ОБОИХ
     РЕЖИМАХ ПО	АДРЕСУ 177540 И	ИМЕЕТ СЛЕДУЮЩИЙ	ФОРМАТ:

     РАЗРЯД 00
	    - ИСПОЛЬЗУЕТСЯ ДЛЯ ОТОБРАЖЕНИЯ ПЗУ В  РЕЖИМ	 USER;
	      ЕСЛИ РАЗРЯД РАБЕН	0, ТО В	 ПРОСТРАНСТВО	РЕЖИМА
	      USER ПО АДРЕСАМ 000000-077777 ОТОБРАЖАЕТСЯ  ПЗУ;
	      ЕСЛИ РАЗРЯД РАВЕН	1, ТО ОТОБРАЖАЕТСЯ  ФИЗИЧЕСКОЕ
	      ОЗУ С АДРЕСАМИ 000000-077777;

     РАЗРЯДЫ 01-07
	    - ДАННЫЕ РАЗРЯДЫ ОПРЕДЕЛЯЮТ	НОМЕР  БЛОКА  (ОБ'ЕМОМ
           16К)  ИЗ  ДОПОЛНИТЕЛЬНОГО  ПЗУ,  КОТОРЫЙ  ДОЛЖЕН
           ОТОБРАЖАТЬСЯ  ПО  АДРЕСАМ  040000-077777;  ТАКИМ
           ОБРАЗОМ ДАННЫЙ МЕХАНИЗМ ПОЗВОЛЯЕТ ПОЛУЧИТЬ  ДОС-
           ТУП К ПАМЯТИ, ОБ'ЕМОМ ДО 2 МБ;

довольно неплохо – 2 Мб для 16-битного компьютера.

страничная адресация, 8-ричные адреса.

вот там да, похоже на оверлеи. но при этом линейная адресация.

ещё недавно книжку про XEDIT нашёл, «Программирование в системе виртуальных машин ЕС ЭВМ, Коваль Г.И.»

там про OS/360 (ОС ЕС): СВМ, PTS, ПДО и в конце немного про XEDIT и REXX.

внезапно, неплохое такое описание текстового редактора XEDIT/SPF в частности, да и в целом СВМ и «девопсового тулчейна с контейнеризацией» в общем.

на понятном русском языке, с картинками (адресного пространства, например).

вот там понятные оверлеи и вообще подход к виртуалками интересный.

отдельная однозадачная ДОС под СВМ в которой запускать прогу на ПЛ/1, Фортране или Коболе.

и отдельный шелл с перезаписью из гостя в хост и обратно.

и своё специфическое понимание «индексированных файлов» точнее их access method, а точнее – контейнеров с ФС в виде датасетов DSDM оттуда.

оттуда и такие навороты по файловому API в Коболе или ПЛ/1 по другим типам файла которые не LINEAR SEQUENTIAL.

оттуда же и FILEDEF для определения задач в шелле, и прочие занятные навороты по описанию окружения задач, среды и ввода-вывода.

если дополнить это тем как линковались там проги (например, что из чего вызывать можно, а что нельзя), виртуальную фс, карту памяти и оверлеи

– становится понятно для чего были такие навороты по файловому API и виртуальной памяти там в СВМ реализованы.

…. а тут кто-то расказывать будет теперь, что контейнеризация, девопсинг и виртуалки — совсем недавнее изобретение цивилизации, блин.

читаю СССР-овскую книжку 1990 года про ОС ЕС,ЕС ЭВМ, СВМ, МВМ, ПДО. ну и ПЛ/1 и XEDIT с REXX-ом, разумеется.

и всё понимаю.

блин, так если первоисточник искать про MVS там наверное это лет на 15-10 старше будет 1990-го года.

и это ещё даже толком не касаясь OS/370, /390, AS/400 и i.

рассказывайте теперь что виртуалки и контейнеризация с девопсингом — это недавнее достижение цивилизации.

бимеры эту SNA сколько там лет продвигали – как минимум середину 80х и все 90е, если не раньше про 3270 и его обновлённый вариант.

даже странно что полуось прибили в начале 2000-х, и до терминала к мейнфрейму с рексом толком не доросла.

наверное веб и прочие сети были бы совершенно другими, в какой-то альтернативной реальности. если бы SNA, MVS и прочие победили естественный отбор.

в журнале открытые системы 1997 года есть такое адекватное сравнение этих динозавров про производительности в виде таблицы.

при стоимости в 2-3 раза дороже – производительность в 10х раз и более лучше на обработке транзакций.

но – проблема последней мили.

они там бурный рост мейнфреймам предсказывали на 1998-1999, но потом как известно, наступил дефолт и очередной кризис.

в общем – люблю иногда перечитывать старые компьютерные газеты. старые прайсы ещё занятные тоже.

поностальгировать.

ещё наткнулся на такую вот коллекцию эмуляторов некоторого WadiM-а: spc-emu.uphero.com и https://soviet-pc.narod.ru/

где-то там в вебархиве есть емуляторы не только БКшек, Радио-86РК и прочих Векторов — но и XT и даже 486 AT.

вот интересно, ELKS под ним надо будет попробовать позапускать аутентичный.

эпичное:

Ш е д е в р ы э л е к т р о н н о й г р а ф о м а н и и

Это самый персональный (личный) компьютер. Заметьте-не приставка к джойстику, а именно компьютер и при этом из очень хорошего семейства фирмы DIGITAL.

Как ни старались анонимные «разработчики», они не смогли испоганить главных преимуществ исходной модели LSI-11: мощный ассемблер и полная открытость к внешнему миру: СЛОТ, параллельный и последовательный порты, сответствующие промышленным стандартам.

«Неспособность решить ту или иную задачу часто сваливают на низкое качество отечественных компьютеров. Вот-де дайте нам суперкомпьютер и мы горы сдвинем. И очень часто тратятся огромные средства там, где для решения задачи хватило бы даже микро-ЭВМ БК-0010. А беда была не в компьютере, не в объеме памяти или оперативности, а в том, что заказчик не смог сконструировать необходимый алгоритм и сответствующую програму, не представлял себе, как это вообще можно сделать, а попытался переложить всю эту работу на компьютер, который тем более этого не сделает.»

«Современный компьютер обладает, по существу, одним-единственным талантом-реагировать с молниеносной быстротой на импульсы электрического напряжения»

С Т А Р А Я Р Е А Л Ь Н О С Т Ь

Дружественность интерфейса этой примочки по простоте и наглядности максимально приближена к аналогичным показателям для бутылки водки или сникерса, а игровой манипулятор с парой кнопок сегодня и есть «народный компьютер».

«Цифровое будущее» наконец наступило, и оно оказалось совсем не таким, каким представлялось его инициаторам. Впрочем, так бывает всегда.

и чего это он, интересно – к приставке к джойстику прикопался.

как будто бы что-то плохое. «палка, приносящая радость» лолЪ.

вот это – например, вполне неплохая приставка к джойстику: C64_Direct-to-TV

целый Commodore 64 у джойстика унутре, рядом с неонкой и шморгалкою.

к такой вот приставке к джойстику (в самом джойстике, и даже на совсем приставка) – претензий не имею.

а игровой манипулятор с парой кнопок сегодня и есть «народный компьютер».

прикольный там был ассемблер, в PDP-11. вот интересно, под БК-шки кроме BKUNIX ещё что-нибудь было подобное?

в форуме в паре предпоследних постов здесь тоже интересуются возможностью портирования UNIXv7, или даже 2.11BSD с минимальными доработками, или вовсе без оных из-за совместимости с PDP-11/70.

а тут пишут про PDP11 handbook и реализацию MMU способом совместимым с :

Есть две разновидности: 22-битный физический адрес - pdp-11/70. До 4Мбайт памяти. Нужен для запуска Unix 2.11BSD.

18-битный физический адрес - pdp-11/40, ДВК. До 256кбайт памяти. Используется в Демос-ДВК

в общем, тоже интересно аутентичный олдовый юникс туда воткнуть, BSD или V7 или какой-нибудь xv6 или там демос/инмос/~фобос~ вдобавок к ос рафос, лол.

что там ещё кроме BKUNIX под БК-шки было?

он v6 правда. наверное, будь аутентичный FPGA девайс с БК-кой, можно было бы и Plan9 под PDP-11 портировать.

bk.grfgames.com:

БК-11М В 21М ВЕКЕ

пишут Dave Dangerous под БК и тому подобное (принца персии и Goonies)

с видеоотчётами в бложике

Ю.А. Зальцман, МИКРО-ЭВМ БК-0010. АРХИТЕКТУРА И ПРОГРАММИРОВАНИЕ НА ЯЗЫКЕ АССЕМБЛЕРА

да, занятный ассемблер у PDP-11:

Код 4: MOV -(PC),-(PC) - вирус, с которым мы уже знакомы.

Автодекрементная косвенная адресация. Если сообщить, что «декремент» означает уменьшение чего либо, то этот способ будет почти понятен, не правда ли? У него только два отличия от автоинкрементной косвенной адресации: во-первых, адрес в регистре-указателе не увеличивается, а уменьшается; во-вторых, это происходит не после выполнения команды, а до неё, на что указывает запись -(RN), в которой знак «-» стоит перед обозначением регистра. В остальном же сходство с автоинкрементным способом полное, включая то, что при операциях с байтом модификация числа в регистре делается на 1, а со словом - на 2, и что регистр SP всегда модифицируется только на 2. Пример: пусть в регистре R2 записано число 1002. Тогда команда CLR -(R2) очистит ячейку 1000 (ту, адрес которой на 2 меньше, чем записанное в регистре число), а содержимое регистра после операции, естественно, окажется равным тоже 1000 - оно стало таким ещё до очистки ячейки. Видимо, дальнейших примеров не требуется, по аналогии с автоинкрементным способом всё и так ясно. Этот способ позволяет делать, в общем, то же, что и автоинкрементный, но при работе с массивом его просмотр или пересылка производится «с конца», а перед началом операции в регистре должен быть записан адрес следующей за последним элементом массива ячейки.

Однако этот способ позволяет делать и нечто более интересное - например, перемещать числа в памяти. Пусть в R2 записано число 2004, а по адресу 2002 - число 1254. Тогда команда MOV -(R2),-(R2) поместит число 1254 в ячейку 2000, т.е. как бы «передвинет» его в памяти с большего адреса на меньший. (Разумеется, по адресу 2002 число 1254 тоже сохранится.) Как это произошло? Вначале содержимое R2 уменьшилось на 2, став равным 2002, и регистр указал на число 1254. Теперь оно должно быть записано по адресу второго операнда, но его указатель - тот же регистр, и опять вначале его содержимое уменьшится на 2, станет равно 2000, а уже потом туда будет записано число. Нетрудно догадаться, что таким способом можно «сдвигать» массивы в памяти после удаления в середине какого-либо элемента (аналогичное применение может найти и команда MOV (R2)+,(R2)+).

★ ★ ★

А теперь - маленькое развлечение и одновременно интересный пример по практике использования автодекрементной адресации. Запишем команду MOV -(PC),-(PC) (код 14747). Для большего эффекта поместим её в старшие адреса ОЗУ, в ячейку 77776 (с помощью директив МСД это делается просто и безо всякого ассемблера: 77776А14747И), а затем передадим на неё управление (запустим «программу» по адресу этой команды: 77776G) Что случилось? Экран мгновенно стал «полосатым», а ЭВМ… Она «мертва»: не отвечает на нажатие клавиш и даже на такое «мощное лечебное средство», как клавиша «СТОП», никак не реагирует! Только системный сброс (или выключение, а затем включение питания) «приводит её в чувство». Что же это за «бомба», которая мгновенно парализовала все средства ЭВМ?

После запуска в регистре PC содержится адрес следующей команды - число 100000. При обращении к первому операнду содержимое PC уменьшается на 2, давая адрес 77776, а там записан код команды - число 14747. А куда оно перепишется? По адресу второго операнда, но перед этим содержимое PC уменьшится ещё на 2 и станет равно 77774, т.е. укажет уже на следующую («нижележащую») ячейку памяти. А потом, раз теперь в регистре PC адрес 77774, то туда и будет передано управление, а там снова та же команда, тот же «смертельный» код! Команда как бы «размножается» в памяти ЭВМ, причём со страшной скоростью: чтобы заполнить собой всю память, ей достаточно всего лишь 0.2 секунды! А почему ЭВМ отказывает? Это станет ясно, если вы вспомните, что в зоне адресов 0…777 размещается системная область и стек ЭВМ, её «собственная память». А если стереть содержимое памяти любого «существа», пусть даже такого простого, как БК, это если не смерть, то безумие…

Но что же это всё-таки за команда, зачем мы потратили на её разбор столько времени, и для чего она может пригодиться? Вы, наверное, слышали о компьютерных вирусах, но, возможно, ещё не встречались ни с одним из них. Так вот, позвольте представить: MOV -(PC),-(PC) - простейший вирус (точнее, ещё не настоящий вирус, такие программы носят название «червяк»), вызванное им «заболевание» развивается молниеносно и, безусловно, «смертельно». Эта команда уничтожает всю информацию, хранимую в ОЗУ по адресам, меньшим, чем адрес самой команды. А зачем может понадобиться такая страшная команда? Существует ряд случаев, когда нужно срочно уничтожить хранимую в ОЗУ информацию. Например, чтобы в написанной вами игре после запуска разрешалось только определённое число попыток, а потом её нужно было снова загружать с МЛ (что затруднит нахождение решений), поместите в любом месте программы этот вирус и, когда число попыток исчерпано, заставьте его «ожить» (такой «до поры до времени спящий» вирус носит название «троянский конь»). Сложнее, но тоже возможно реализовать активизацию вируса, например, по истечении заданного времени, после определённого числа копирований программы на МЛ (если она имеет встроенный копировщик) или при попытке что-либо изменить в программе. (Известно, что «настоящие» вирусы на IBM-совместимых компьютерах были изначально созданы для наказания «компьютерных воришек», взламывающих защиты от копирования. - Прим. ред.) Как видим, даже вирусы можно заставить работать с пользой. Но это ещё не всё. Изучая вирусы, создавая их и борясь с ними, программисты совершенствуются уже не в ремесле, а в искусстве. Последнее тоже приносит пользу, хотя отнюдь не перекрывает вред, приносимый вирусами. (Рассуждения о полезности вирусов составляют личное мнение автора статьи. На наш взгляд, написание вирусов можно рассматривать скорее как хулиганство и стремление напакостить всем без исключения (ведь вирус «бьёт» бесприцельно!). Учиться же программировать лучше на других, не менее интересных и полезных, но безвредных вещах. - Прим. ред.)

Ещё одно применение тот же принцип - «уничтожай, размножаясь» - находит в оригинальной компьютерной игре «бой в памяти»: в ОЗУ загружаются специальные «боевые программы», и особый монитор попеременно передаёт им управление, разрешая делать по нескольку «ходов» по очереди. Цель - «вывести из строя» программу противника. Эта игра была очень популярна среди программистов и любителей за рубежом несколько лет назад, но сейчас интерес к ней значительно упал. (О том, как реализовать на БК подобный «многопрограммный режим» с параллельной работой нескольких программ, можно прочитать в журнале «Информатика и образование» №2 за 1992 г. - Прим. ред.)

★ ★ ★

6. Автодекрементная двойная косвенная адресация. Обозначение: @-(RN). Если сделать уже известные нам поправки, что декремент - это уменьшение, и выполняется оно ДО обращения к ячейке, на которую указывает операнд, то из автоинкрементной двойной косвенной адресации легко получается автодекрементная. Далее, не детализируя, приведём пример. Пусть в регистре R2 записано число 1002, по адресу 1000 - число 1254, а по адресу 1254 - 3333. Тогда команда MOV @-(R2),R4 запишет в R4 число 3333. Данный способ может быть применён для тех же целей, что и автоинкрементная двойная косвенная адресация, но даёт возможность, скажем, просматривать таблицу адресов с конца. Отметим, что такого, казалось бы, логичного способа как «двойная косвенная адресация», записать которую можно было бы, например, как @(RN), не существует. А жаль - он бы тоже мог пригодиться… Но ещё не всё потеряно, мы можем «обмануть» ассемблер и всё-таки задать адресацию таким образом! Как именно - увидим позже.

Основные способы адресации

Способы адресации с использованием PC

кавычки здесь чтобы разметка в markdown не ругалась, в коде их быть не должно.

вот сразу отсюда видно, откуда ноги растут у сишного

while(*dst++=*src++);

постинкремент и предекремент были ещё также в ассемблере Motorola 68k, в той же Амиге.

Как видим, действительно ничего принципиально нового в последних четырёх способах адресации нет. Но их так называемая «стандартная» запись для программистов на ассемблере выглядит в высшей степени необычно и почти никогда не применяется.

Можно ли «изобрести» ещё способы с использованием PC? Да, конечно. Но практического значения они не имеют и потому или не применяются, или мы их используем, даже не задумываясь, что у них есть столь «именитые родичи», имеющие отдельные «титулы» и «гербы». Продемонстрируем такие «открытия». Допустим, мы по аналогии захотели создать способ с применением PC, имеющий код 0. Что мы получим? Например, MOV PC,R4. Что же тут нового? Или, скажем, код 1: MOV @PC,R4 - так мы просто запишем в R4 код следующей команды. Это нужно? Мягко говоря, не часто... Код 4: MOV -(PC),-(PC) - вирус, с которым мы уже знакомы. И наконец, код 5: MOV @-(PC),R4 - эта команда перепишет в R4... число из ячейки с адресом, равным коду текущей команды! Чепуха, и ничего более.

Контрольные вопросы и задания

Команда MOV -(PC),-(PC) «саморазмножается» в ОЗУ в сторону младших адресов («вниз» по памяти). Придумайте команду, которая будет исполнять «бег на месте», т.е. переписывать свой код по своему же адресу и передавать себе управление.
        MOV     -(PC),@PC
Придумайте последовательность двух одинаковых команд, исполняющую «бег на месте» (обязательно с использованием кодов обеих команд).
        MOV     @PC,-(PC)
        MOV     @PC,-(PC)
Придумайте команду, которая бы «саморазмножалась» по памяти «вверх».
Такой команды нет.

Что запишет в R3 последовательность команд:
        MOVB    #255,R0
        CLR     MET
        MOVB    R0,MET
        MOV     (PC)+,R3
MET:    CLR     R0
Число 255.