У DEC режим супервизора - это не режим пульта! Это третий режим работы - типа пользовательского со своим набором PAR/PDR. В RSX-11M-Plus есть поддержка этого режима и в него можно загнать, скажем, резидентную библиотеку FCS, обычно собирается с именем FCSFSL.Сообщение от Patron
Ещё раз - ЭТО НЕ ПУЛЬТОВЫЙ РЕЖИМ!
- - - Добавлено - - -
Насколько я понял - первоначальная идея моды у Патрона - попытка ускорить по крайне мере описание отображения виртуальной памяти в физическую при переключении контекста процессов.
В PDP-11 три "моды" (режима работы процессора) и три набора PAR/PDR (которые реализованы как сверхОЗУ в MMU - по крайне мере такую аналогию можно провести). Соответственно, если пользовательский процесс обращается за обслуживанием к ядру или происходит прерывание - происходит переключение режима работы процессора (моды) по информации из вектора прерывания - и вот уже мы работаем с другим (ранее загруженным) набором PAR/PDR. И только если нужно переключиться с одного процесса на другой, когда оба работают в одном режиме работы процессора (планировщик активирует другой процесс, например) (в одной моде) - тогда нужно перезагрузка PAR/PDR.
У Патрона попытка ускорить этот процесс за счёт того, что количество режимов работы процессора резко увеличивается, у каждого свой набор PAR/PDR - мы их когда то проинициализировали - и вуаля - значительно реже их перезагружаем.
Проблема только в том, что при большом количестве памяти и/или маленьком размере страницы (то, что у PDP-11 64 кб и 8 кб) - этих самых PAR/PDR (если использовать аналогичный PDP-11 механизм описания страниц и работы MMU - только расширить на большие размеры памяти - физ и вирт) получается чуть больше, чем дохера.
Поэтому с моей точки зрения - не взлетит. Нужно думать - как уменьшить или реализовывать другой механизм
- - - Добавлено - - -
при 32-битном процессоре (и размере команды (минимум) в 4 байта, а не 2) - думаю - это тоже утопия. Нэ влэзит
- - - Добавлено - - -
В дополнение к описанию моды.
Если реализовывать на эмуляторе - может и взлетит, только или памяти будет жрать дохера или MMU будет работать медленно.
А если пихать в FPGA - более чем уверен, что или не влэзит (памяти там все токи чуть меньше, чем недохера) или MMU будет тормозить аки Конь Древний На Борозде
- - - Добавлено - - -
И поскольку я опять запутался в терминах Патрона, определение моих терминов (может, DEC использует свои, более правильные - но я их щас вспомнить не могу, а лезть в доки лень)
Окно в виртуальном адресном пространстве - грубо говоря - начиная с какого виртуального адреса и сколько отобразить на физический адрес.
С какого - с границы 8 кб
Сколько - от 64 байт до 8 кб.
Почему с границы 8 кб - потому что регистров-описателей (регистров базы) - всего восемь
Почему от 64 байт (100 в восьмеричном) - потому что MMU берет содержимое регистра PAR (16 бит) (номер регистра - старшие три бита виртуального адреса - номер окна) сдвигает его влево на шесть бит (и вот вылез минимальный блок в 64 байта) (теперь 22 бита, младшие шесть - нули), берет виртуальный адрес (16 бит), режет старшие три бита (номер окна) (на самом деле ничего он не режет - просто берет младшие 13 бит) и складывает, формируя физический адрес (22 бита)
Сколько отобразили - ЕМНИП - в PDR - как количество 64 байтных блоков
- - - Добавлено - - -
С ваксами в живую дело не имел - поэтому как оно там - даже с памятью-изменщицей не скажу - надо листать талмуды. Но учитывая наличие режима совместимости - видимо не кардинально отличающееся
Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 
