запуск mapped системы на lsi-11 (вм1, вм2)

[bigral]

Всем привет, мелькала как-то тема запуска многозадачной системы на pdp11 БЕЗ MMU. Все свелось к тому что Form заключил: сделать систему совместимой с вм3 очень маловероятно, так как это требует больших внутренних доработок в процессорах вм1,вм2 (что естественно невозможно). Сама же много-задачность на lsi-11 есть в старом RSTS-11 (который на UNIBUS), еще в каком-то multiuser basic, еще не ясно в каком виде в LSX, еще в rsx. Но изза слабого обьема памяти все эти многозадачные режимы скорее "игрушка" (т.е. это тупиковая ветка развития).

В процессорах вм1 и вм2 есть специальный режим (HALT mode) который как бы должен облегчать реализацию такого рода доработок. Более того вот есть же тот же пк союз-неон 11\16 в котором допилили систему до многозадачного режима. Так вот вопрос, можно ли чтото сделать в железе для того чтобы запускать mapped системы на вм1 и вм2 с минимальными доработками кода этих систем (при этом предпологается что доработан будет только системный софт и драйверы, а прикладные программы должны запускаться без доработок).

[Advertiser]

[Hunta]

можно ли чтото сделать в железе для того чтобы запускать mapped системы на вм1 и вм2 с минимальными доработками кода этих систем

Реализовать ДП

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

Это если пилить под RSX.

В процессорах вм1 и вм2 есть специальный режим (HALT mode)

То, что есть в ВМ1 - не позволяет даже назвать это специальным режимом. А то, что есть в ВМ2 - заточено под именно пульт. Теоретически на ВМ2 можно попробовать использовать этот режим, но поскольку RT и RSX о нём ни сном ни духом -

с минимальными доработками кода этих систем

ничего не получится

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

Потому как - кроме того, что надо реализовывать модуль ДП, нужно ещё вклиниваться в обращение к PS - потому как в нём сидят биты текущего режима (на нормальным процессорах), а поскольку PS внутри проца - я даже не представляю, как это можно сделать, а засадить код внутрь - это из разряда

требует ... внутренних доработок в процессорах вм1,вм2 (что естественно невозможно)

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

Если пилить под RT - возможно, что и будет несколько проще (в силу большей простоты RT), но учитывая, что она тоже ни сном ни духом про HALT режим, зато хорошо осведомлена о стандартном ДП - малой кровью не обойтись.

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

Ну и самый главный момент, связанный с доработкой как железа, так и RSX или RT.

а) У Вас есть на примере спец, который запилит это в железе? Который запилит это в железе - с доработкой существующих платформ ака БК или УК-НЦ? Или который запилит это в железе с созданием новой платформы, программно (в первую очередь для игр - ибо таких пользователей здесь большинство) совместимой со старой?

б) У Вас на примете есть спецы, круто знающие внутренности хотя бы RT, которые ко какой то причине заинтересовались бы этой (нехилой) доработкой-переработкой RT?

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

Моё мнение - не стоит овчинка выделки. Пока ещё есть ВМ3, а кроме того, FPGA модель ВМ1 и на подходе ВМ2 (и надеюсь ВМ3). Кому сильно хочется - могут допилить модель до чего угодно (вплоть до реализации СТАНДАРТНОГО ДП) - и реализовать своим самые смелые фантазии. По чему-то похожему иду я - только мне не интересна многозадачность на ВМ1 и даже на ВМ2. Если к ним добавить ДП - мы получим ВМ3 - и смысл в такой доработке?..

[form]

Реализовать ДП

И, следовательно, полноценный регистр состояния процессора, адресуемый через I/O page
И дополнительный SP.
Ну и команды MxPI.

[Hunta]

полноценный регистр состояния процессора

дополнительный SP

Пока шёл с автобуса домой - подумал.

Технически реализовать - можно.

Но а) получившееся НЕЧТО будет или охрененно по размера и по количеству микросхем или это загонять надо в что то типа FPGA (и тогда затея теряет свой смысл ещё раз чуть более чем полностью) и б) потому что, что на (любимых ретроманьяками) микрухах, что на (не)православных FPGA нужно будет реализовать от (примерно) трети до половину функционала проца - что бы на лету перехватывать - а чего он там читает с памяти (команда, источник или приёмник), а чего он собрался и куда писать - что бы вычислить содержимое (отсутствующего) внешнего PS, (отсутствующего) второго SP и на лету преобразовывать из MхPI в MOV (при передаче команды из памяти в проц) и обратно в MxPI отношении операндов, когда проц начнёт выполнять эту команду ну и тому подобное.

То есть теоретически вроде возможно, а практически... Как в одном анекдоте - Вась, а.... нахрена??

[form]

содержимое (отсутствующего) внешнего PS

В том и дело, что PS должен быть не внешним - он должен быть тем самым который в процессоре
CLx/SEx должны на него влиять, прерывания/возврат из них должны на него влиять
Ну и MFPS/MTPS должны с ним общаться (причем запись через MTPS, в отличие от прямой записи в PSW, должна еще и защищаться ДП).
Ну и до кучи: команды HALT, WAIT, RESET должны блокироваться в UM - первая прерыванием по 4/10, остальные просто работать как NOP.
Не берусь судить насколько все это реализуемо. По-моему реализация сравнима с созданием самого процессора с нуля

Ну и на закуску: системы которые используют ДП ожидают, что EIS команды сами собой разумеются. Это к вопросу про ВМ1

[Hunta]

В том и дело, что PS должен быть не внешним - он должен быть тем самым который в процессоре

Нас не будут интересовать ВСЕ биты, а только - биты приоритета. Их придётся вычислять по поведению проца. Хотя... Есть у меня некоторые сомнения по поводу того, нужны ли они будут. А вот 15-12 придётся хранить нам и в определённых ситуациях - дописывать в записываемое.

MFPS/MTPS

Ловить, обрабатывать и переделывать. Как и остальное.

сравнима с созданием самого процессора с нуля

Поэтому я и написал - реализовать ДП плюс от трети до половины проца снаружи - что сводит затею к нулю - проще реализовать в FPGA полноценный проц (чем я и балуюсь).

Но у нас тут есть мусью, любящие извращения. Флаг в руки. На FPGA я бы ещё попробовал реализовать, но смысла не вижу абсолютно. Хотя... За деньги какие только фентези не приходилось реализовывать