32-разрядный процессор, полностью совместимый с архитектурой PDP-11.

[Hunta]

В ваших терминах на классическом PDP-11 всего три моды, одна из которых - пользовательская, что не мешает запускать теоретически любое количество процессов, память которых изолирована и которые не могут повредить друг дружке и ядру операционки.

а при работе в разных модах - регистр базы кода всегда нулевой, потому что каждому процессу выделяются все 4Гб 32-разрядных виртуальных адресов.

В ваших терминах - в PDP-11 используется всего одна мода для пользовательских процессов, что не мешает

каждому процессу выделяются все

выделить полные 64 кб

там где есть две моды - почему не быть остальным

Принцип - пусть будет, но для чего это пригодится - не понятно - плохой принцип.

Ещё раз вопрос - практический смысл в наличии не трёх, а большего количество мод.

Особенно учитывая, что у Вас идёт совмещение - старых двух бит из PSW, задающих режим работы процессора и непонятного xMode

Нулевой процесс имеет особые привилегии и выполняется в адресном пространстве KERNEL-моды

Нулевой процесс - этот тот, которые имеет xMode=0? А если в старых битах PSW для него стоит режим работы процессора 11 (то есть пользовательский) - это тогда как. А если (xMode=0, psw 00) и (xMode=0, psw=11) - тогда как - это разные процессы, это один процесс, если это один процесс - на что влияют биты в psw?

[Advertiser]

[Patron]

в PDP-11 используется всего одна мода для пользовательских процессов, что не мешает выделить полные 64 кб

Но для этого надо вручную управлять диспетчером памяти, меняя мапинг USER-моды при каждой смене активного процесса. Если бы у разработчиков PDP11 было не по 2 бита на номер моды, а по 9 ( и диспетчер памяти имел не несколько единиц наборов регистров PAR, а несколько сотен ) - они вряд ли отказались бы от 512 мод вместо двух-трёх. Ведь тогда содержимое регистров PAR не надо изменять при переключении процессов и это ничего не стоит.

Конечно, можно вместо 512 наборов PAR использовать только два, но ЗАЧЕМ, если это ничего не стоит, тем более, что диспетчер виртуальной памяти может сам заполнять всё содержимое PAR, и лишь иногда процессор может изменять для некоторых страниц приоритет вытеснения в своп. Когда диспетчер памяти работает параллельно с процессором - общая работа идёт гораздо быстрее, для этого и нужны расширенные биты моды.

идёт совмещение - старых двух бит из PSW, задающих режим работы процессора и непонятного xMode

xMode - это старшие биты моды, дополнительно к "старым" битам моды из PSW. Если отдать всю моду супервизора под работу с устройствами - остаётся 9 битов моды ( старший бит моды "старого" PSW + 8 битов xMode ). У KERNEL-моды все биты моды нулевые.

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

если два бита моды "старого" PSW = 00 - номер моды определяется как [xMode*2 + 0]
если два бита моды "старого" PSW = 01 - значение xMode не учитывается и выбирается мода супервизора
если два бита моды "старого" PSW = 11 - номер моды определяется как [xMode*2 + 1]

При этом нулевая мода - это KERNEL-мода, а все остальные ( кроме моды супервизора ) - это USER-моды.

...

В принципе можно наплевать на запрещённую моду 16-разрядного режима, тогда номер моды будет иметь 10 битов:

если два бита моды "старого" PSW = 00 - номер моды определяется как [xMode*4 + 0]
если два бита моды "старого" PSW = 01 - и значение xMode == 00 - выбирается мода супервизора
если два бита моды "старого" PSW = 01 - и значение xMode != 00 - номер моды определяется как [xMode*4 + 1]
если два бита моды "старого" PSW = 10 - номер моды определяется как [xMode*4 + 2]
если два бита моды "старого" PSW = 11 - номер моды определяется как [xMode*4 + 3]

При этом нулевая мода - это KERNEL-мода, первая мода - мода супервизора, а все остальные - это USER-моды.

[Hunta]

они вряд ли отказались бы от 512 мод вместо двух-трёх

Может да, а может нет.

Сколько потребуется регистров-описателей памяти? Если я не ошибаюсь, то при минимальной единицы 4 мб (22 бита) и общем адресном пространстве 42 бита количество адресуемых единиц 2 в 20 степени. Если идти по логике работы MMU PDP-11 - 2 в 20 степени регистров и если предположить регистр в 32 бита - то получается, один набор аналогов PAR - 4 мб (вроде не ошибся в вычислениях). Плюс 8+2=10 2 в 10 = 1024 - 256 = 768 - итого 3 гигабайта памяти на описание всех PAR. А в PDP-11 было два регистра - PAR и PDR (смещение и дескриптор) - итого 6 гигабайт памяти внутрь проца - если его делать железным.

И даже если это эмулятор - 6 гигов - только эта структура. Какой то толстый эмулятор получается.

А теперь другой вопрос - если у меня в систему запущено пара десятков процессов - нафига мне большая часть этих регистров описателей?

Напомнить, как пошла Интел в своём диспетчере памяти проца?

[Patron]

Сколько потребуется регистров-описателей памяти?

Вряд ли есть смысл подходить к вопросу статически. Как внутри себя работает диспетчер памяти - это его проблема. Главное, чтобы он обеспечивал максимальное быстродействие при оптимальном использовании ресурсов. Сразу понятно, что диспетчеру памяти нет смысла описывать больше виртуальной памяти, чем размер ОЗУ + размер своп-файла. Если размер ОЗУ мал, а размер своп-файла большой - всё умрёт в свопе и никто не станет ругать диспетчер памяти, если он высвопит часть таблицы доступа. Когда ОЗУ некуда девать - никто не станет ругать диспетчер памяти, если он использует малую часть ОЗУ под таблицы доступа. Главное, чтобы всё происходило оптимальным образом - тогда итоговое быстродействие будет максимальным по сравнению с любым другим сценарием.

[Hunta]

, чтобы всё происходило оптимальным образом

если он использует малую часть ОЗУ под таблицы доступа

Ну то есть пока никакого понимания - как оно всё должно работать.
Помните, что компьютер - это дурак. Оно что то умеет делать (и его умений мало), но умеет это делать очень быстро. И если у человека в голове нет понимания того, как должна работать его программа (а внутренности проца - это тоже программа) - трудно ждать чего либо вменяемого от программы.

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

пожалуйста, сделайте полноценную МПИ 24-х бит адрес по ГОСТ

Смысл?