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

[Hunta]

Пусть даже у нас только три моды

Как мне кажется, основная причина появления режима Supervisor, так же DataSpace - попытка увеличить доступную для приложения память с 64 кб на что то побольшее. Поэтому смысла увеличивать количество режимов работы процессора не вижу. По идее - даже три (как и dataspace) - пока никак не просматривается - для чего? - в 32-битном режиме. Для 16-битном - да, там всё понятно.
Идём дальше. Почему может понадобиться наличие страниц в адресуемом 4гб пространстве. Я пока вижу след. сценарии:

- Доступ из ядра в адресное пространство пользовательского процесса
- Доступ из ядра к странице в/в
- Доступ из пользовательского процесс в адресное пространства ядра
- Доступ из пользовательского процесс в адресное пространства другого процесс
- Доступ из пользовательского процесс к странице в/в
- Единственная копия библиотеки (типа FCSRES FSCFSL) в памяти и отображение на неё в адресном пространстве ядра или пользовательского процесса
- Коду ядра или пользовательского процесса выделили кусок памяти при загрузке, оно захотело больше, пробуем расширить, а за сразу за физической памятью, которая была выделена - нужного количества свободного памяти нет - занята другим процессом - возможность строить из ненепрерывных сегментов физической памяти непрерывный сегмент виртуальной памяти окажется в такой ситуации плюсом.

Первые шесть пунктов по сути описывают один и тот же сценарий. А теперь, внимание, вопрос - возможность отобразить куски своей памяти на память других процессов в количестве 2 в 20 степени штук (реально, конечно, поменьше - примерно так на один - для себя то память тоже надо иметь) - оно в какой ситуации может понадобиться? Даже моя буйная фантазия отказывает. Доступ к памяти пары десятков библиотек и пары десятков других процессов - я думаю покроют 99 процентов возможных сценариев - то есть, скажем 64 сегмента в 4гб-ом адресном пространстве - почти за глаза. Ну, что бы точно гарантировать - пусть будет 1024 сегмента. И то с моей точки зрения уже будет напоминать некоторые современные программные пакету - а давайте сделаем, что бы ВСЁ было.

Дальше вопрос - откуда взялось адресное пространство на 42 бита? 4Тб - нафига столько?

поэтому объём физически доступной виртуальной памяти ограничен только объёмом SSD своп-диска ( для которого 4Тб уже не фантастика ).

Вы чего такого объёмного собрались напихать в (свопнутую) память и получить дикие тормоза на свопе?

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

Вообщем, если не развлекаться виртуалками - много памяти не требуется, если только не идти по пути раздутых приложений и ядра - а основной цимес PDP-11 с моей точки зрения - легковесные по объёму приложения. Извините, для приложений по 4 гига у меня есть Windows и архитектуры x86-x64 - вот пусть там и остаются.

Именно это и предлагалось, с учётом того, что дескриптор может находиться в кеше, ОЗУ или свопе

или свопе.

А вот тут мы получим развлекуху покруче варианта пары виртуалок с 16-гигами памяти на 4 гигах физической памяти плюс своп. Даже размещение в основном ОЗУ (которое по определению медленное по сравнению с кэш-память) - уже развлекуха. А кэш к тому добавляет дополнительного куража - MMU закэшировало дескриптор, а потом ядро взяло и изменило дескриптор в озу - получается, надо следить - кто куда и чего записал. Как бэ MMU не потребовался мощней проца.

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

Да, забыл про расширение памяти. RSX такой подход не использует, про другие системы ничего сказать не могу - если что то и попадалось - память молчит, зараза. Учитывая, что теоретически это ускорило бы выделение памяти (RSX вроде в такой ситуации выгружает в файл подкачки, а потом загружает в новое место с требуемым новым размером) - видимо, что то есть плохое, почему DEC решило так не выделять память. Но.. у меня мыслей на эту тему пока нет

[Advertiser]

[Patron]

откуда взялось адресное пространство на 42 бита?

Из расчёта = 1024 моды по 32 бита. Win64 поддерживает 44 бита адреса, внутренняя шина адреса у x64 = 52 разряда, внешняя = 40 разрядов ( если правильно понимаю ). А какое принципиальное ограничение максимального объёма ОЗУ, адресуемого данной архитектурой, хотелось бы иметь?

Ну, чтобы точно гарантировать - пусть будет 1024 сегмента.

Вот и я о том же - 8 сегментов по 512Мб уж слишком мало. 1024 сегмента по 4Мб - уже веселее ( точнее - от 512б до 4Мб с шагом 512б ).

И то с моей точки зрения уже будет напоминать некоторые современные программные пакеты - а давайте сделаем, что бы ВСЁ было.

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

[Hunta]

А какое принципиальное ограничение максимального объёма ОЗУ

Это достаточно сложный вопрос.

Если брать с прицелом на железный проц и если не мультиплексировать данные-адрес то у нас - 32 проводника на данные и 32+неизвестно сколько на адрес, то есть 64+ - вот откуда ещё будет расти ограничение на физической размер памяти

По поводу Win и x86-x64, ЕМНИП, проблема максимально возможного размера памяти ещё в другом - там вроде бы надо через дескрипторы описать ВСЮ доступную физическую памяти страницами (то есть на каждую страницу - свой элемент в дескрипторе) и даже при странице в 4 мб объем этих дескрипторов получается неприлично большим, если памяти много. Именно поэтому MS и ограничила макс поддерживаемый размер физической памяти не смотря на возможности проца.

Надо будет попробовать собрать все мои мысли по поводу "PDP-11 моей мечты" в один файл, но боюсь это дело не ближайшего будущего - нужен практический опыт, что бы не спроектировать нереализуемый на практике проц (в FPGA, эмуляторы не в счёт, в эмуляторы можно всё что хочешь наворотить) Поэтому я и хочу поиграться с FPGA пока с "PDP-11 моей юности"

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

точнее - от 512б до 4Мб с шагом 512б

И опять вопрос - с практической точки зрения нафига нам шаг в 512 байт на 4 гигах адресного пространства?

[Patron]

Как мне кажется, основная причина появления режима Supervisor, так же DataSpace - попытка увеличить доступную для приложения память с 64 кб на что то побольшее. Поэтому смысла увеличивать количество режимов работы процессора не вижу. По идее - даже три (как и dataspace) - пока никак не просматривается - для чего? - в 32-битном режиме.

Специальный режим, в котором после включения питания процессор работает только с внешними устройствами - нужен для того, чтобы стартовый код мог находиться не в микрокоде процессора, а обычном ПЗУ по нулевому адресу моды супервизора. Выпадение в HALT и другие напасти также должны автоматически обрабатываться системным ПЗУ моды супервизора.

Проще говоря, мода супервизора - это режим пульта.

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

И опять вопрос - с практической точки зрения нафига нам шаг в 512 байт на 4 гигах адресного пространства?

Изучение интеловских документов по работе с памятью подсказало, что сделать можно иначе.

Оставить 8 сегментов ( которых в DEC называют "страницами" ) и дать каждому сегменту по 1024 страницы ( которых в DEC называют "блоками" ). Тогда общее число страниц в моде будет 8К при размере страницы 512К.

Если принять старый интеловский лимит для 32-разрядных MMU в миллион страниц, то такое количество страниц позволяет иметь 128 мод. А раз по меркам 10-летней давности 128 мод не пугают, то по современным меркам и 1024 моды не сильно страшны.

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

В интел ( насколько я понял ) применяется чисто страничная организация памяти, когда вся толпа флагов и признаков режима использования страницы хранится в её дескрипторе. Однако, все флаги и признаки можно разделить на имеющие отношение к аппаратуре и имеющие отношение к процессу-владельцу страницы. Смешанная сегментно-страничная организация памяти выделяет все общие свойства страниц процесса из дескрипторов и хранит их отдельно - в специальной "таблице регионов", объединяющей ссылки на дескрипторы всех страниц процесса с общими свойствами.

При таком подходе, возможно - есть смысл не задавать фиксированное количество регионов в моде ( 8 или 1024 ), позволив каждому процессу создавать столько наборов страниц, сколько надо.

Например, таблица первого уровня - может содержать 1024 ссылки на описатель региона ( все на один, каждая на свой или как угодно ещё ). Описатель региона задаёт свойства региона и содержит ссылки на описатели страниц. Для полного заполнения одного "атомарного региона" ( занимающего одну ссылку в таблице регионов ) нужно 8 страниц по 512К. Соответственно, полные регионы имеют шаг размера 4Мб, а минимальное изменение размера региона = 512К.

[Hunta]

Проще говоря, мода супервизора - это режим пульта.

У DEC режим супервизора - это не режим пульта! Это третий режим работы - типа пользовательского со своим набором PAR/PDR. В RSX-11M-Plus есть поддержка этого режима и в него можно загнать, скажем, резидентную библиотеку FCS, обычно собирается с именем FCSFSL.
Ещё раз - ЭТО НЕ ПУЛЬТОВЫЙ РЕЖИМ!

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

что есть мода в Вашем разговоре

Насколько я понял - первоначальная идея моды у Патрона - попытка ускорить по крайне мере описание отображения виртуальной памяти в физическую при переключении контекста процессов.

В PDP-11 три "моды" (режима работы процессора) и три набора PAR/PDR (которые реализованы как сверхОЗУ в MMU - по крайне мере такую аналогию можно провести). Соответственно, если пользовательский процесс обращается за обслуживанием к ядру или происходит прерывание - происходит переключение режима работы процессора (моды) по информации из вектора прерывания - и вот уже мы работаем с другим (ранее загруженным) набором PAR/PDR. И только если нужно переключиться с одного процесса на другой, когда оба работают в одном режиме работы процессора (планировщик активирует другой процесс, например) (в одной моде) - тогда нужно перезагрузка PAR/PDR.

У Патрона попытка ускорить этот процесс за счёт того, что количество режимов работы процессора резко увеличивается, у каждого свой набор PAR/PDR - мы их когда то проинициализировали - и вуаля - значительно реже их перезагружаем.

Проблема только в том, что при большом количестве памяти и/или маленьком размере страницы (то, что у PDP-11 64 кб и 8 кб) - этих самых PAR/PDR (если использовать аналогичный PDP-11 механизм описания страниц и работы MMU - только расширить на большие размеры памяти - физ и вирт) получается чуть больше, чем дохера.

Поэтому с моей точки зрения - не взлетит. Нужно думать - как уменьшить или реализовывать другой механизм

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

64кб физической памяти организовать многозадачную OS

при 32-битном процессоре (и размере команды (минимум) в 4 байта, а не 2) - думаю - это тоже утопия. Нэ влэзит

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

В дополнение к описанию моды.

Если реализовывать на эмуляторе - может и взлетит, только или памяти будет жрать дохера или MMU будет работать медленно.
А если пихать в FPGA - более чем уверен, что или не влэзит (памяти там все токи чуть меньше, чем недохера) или MMU будет тормозить аки Конь Древний На Борозде

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

И поскольку я опять запутался в терминах Патрона, определение моих терминов (может, DEC использует свои, более правильные - но я их щас вспомнить не могу, а лезть в доки лень)
Окно в виртуальном адресном пространстве - грубо говоря - начиная с какого виртуального адреса и сколько отобразить на физический адрес.
С какого - с границы 8 кб
Сколько - от 64 байт до 8 кб.
Почему с границы 8 кб - потому что регистров-описателей (регистров базы) - всего восемь
Почему от 64 байт (100 в восьмеричном) - потому что MMU берет содержимое регистра PAR (16 бит) (номер регистра - старшие три бита виртуального адреса - номер окна) сдвигает его влево на шесть бит (и вот вылез минимальный блок в 64 байта) (теперь 22 бита, младшие шесть - нули), берет виртуальный адрес (16 бит), режет старшие три бита (номер окна) (на самом деле ничего он не режет - просто берет младшие 13 бит) и складывает, формируя физический адрес (22 бита)
Сколько отобразили - ЕМНИП - в PDR - как количество 64 байтных блоков

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

С ваксами в живую дело не имел - поэтому как оно там - даже с памятью-изменщицей не скажу - надо листать талмуды. Но учитывая наличие режима совместимости - видимо не кардинально отличающееся

[Patron]

У DEC режим супервизора - это не режим пульта! Это третий режим работы - типа пользовательского со своим набором PAR/PDR.

А в 32-разрядном режиме - это режим пульта. Другие варианты организации режима пульта: 1) микропрограмма в CPU; 2) специальный контроллер режима пульта с поддержкой в CPU; 3) железный пульт. Отдельная мода пульта выглядит на порядок проще любого другого варианта.

Окно в виртуальном адресном пространстве - грубо говоря - начиная с какого виртуального адреса и сколько отобразить на физический адрес.
С какого - с границы 8 кб
Сколько - от 64 байт до 8 кб.
Почему с границы 8 кб - потому что регистров-описателей (регистров базы) - всего восемь
Почему от 64 байт (100 в восьмеричном) - потому что MMU берет содержимое регистра PAR (16 бит) (номер регистра - старшие три бита виртуального адреса - номер окна) сдвигает его влево на шесть бит (и вот вылез минимальный блок в 64 байта) (теперь 22 бита, младшие шесть - нули), берет виртуальный адрес (16 бит), режет старшие три бита (номер окна) (на самом деле ничего он не режет - просто берет младшие 13 бит) и складывает, формируя физический адрес (22 бита)
Сколько отобразили - ЕМНИП - в PDR - как количество 64 байтных блоков

А какими кусками свопить? Если кусками по 4Мб, которых в 32-битном адресном пространстве всего 1024 - то интел с 1М страниц по 4Кб выглядит в 1024 раза более экономно. Если свопить кусками по 8Кб, которых в 4Гб будет 512К, то предлагается ли для каждого из 512 тысяч этих 8Кб окон иметь собственную пару PAR/PDR? А если нет - то как определить, какое из окон уже в памяти, а какое ещё надо загрузить из свопа?

В том и дело, что концепция PAR/PDR плохо масштабируется для перехода от 16-разрядного пространства без свопа к 32-разрядному со свопом.

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

Идею виртуальных пространств со свопом можно показать на простом примере. Допустим, у нас есть архитектура с адресным пространством из 10 адресов, работающая на машне с 3 адресами физического ОЗУ и 10 адресами свопа. Когда программа заказывает выделение памяти в 10 адресов - операционка возвращает указатель на первый адрес.

Потом программа начинает загружать данные в память.

Для виртуального адреса 0 MMU выделяет физический адрес 0
Для виртуального адреса 1 MMU выделяет физический адрес 1
Для виртуального адреса 2 MMU выделяет физический адрес 2
Для виртуального адреса 3 MMU выгружает адрес 0 в своп по адресу 0 и выделяет физический адрес 0
Для виртуального адреса 4 MMU выгружает адрес 1 в своп по адресу 1 и выделяет физический адрес 1
Для виртуального адреса 5 MMU выгружает адрес 2 в своп по адресу 2 и выделяет физический адрес 2
Для виртуального адреса 6 MMU выгружает адрес 0 в своп по адресу 3 и выделяет физический адрес 0
Для виртуального адреса 7 MMU выгружает адрес 1 в своп по адресу 4 и выделяет физический адрес 1
Для виртуального адреса 8 MMU выгружает адрес 2 в своп по адресу 5 и выделяет физический адрес 2
Для виртуального адреса 9 MMU выгружает адрес 3 в своп по адресу 6 и выделяет физический адрес 0

Потом программа читает данные из памяти.

Для виртуального адреса 0 MMU выгружает адрес 0 в своп по адресу 9 и загружает из свопа адрес 0 по адресу 0
Для виртуального адреса 1 MMU выгружает адрес 1 в своп по адресу 7 и загружает из свопа адрес 1 по адресу 1
Для виртуального адреса 2 MMU выгружает адрес 2 в своп по адресу 8 и загружает из свопа адрес 2 по адресу 2
Для виртуального адреса 3 MMU выгружает адрес 0 в своп по адресу 0 и загружает из свопа адрес 3 по адресу 0
Для виртуального адреса 4 MMU выгружает адрес 1 в своп по адресу 1 и загружает из свопа адрес 4 по адресу 1
Для виртуального адреса 5 MMU выгружает адрес 2 в своп по адресу 2 и загружает из свопа адрес 5 по адресу 2
Для виртуального адреса 6 MMU выгружает адрес 0 в своп по адресу 3 и загружает из свопа адрес 6 по адресу 0
Для виртуального адреса 7 MMU выгружает адрес 1 в своп по адресу 4 и загружает из свопа адрес 7 по адресу 1
Для виртуального адреса 8 MMU выгружает адрес 2 в своп по адресу 5 и загружает из свопа адрес 8 по адресу 2
Для виртуального адреса 9 MMU выгружает адрес 3 в своп по адресу 6 и загружает из свопа адрес 9 по адресу 0

[Hunta]

А в 32-разрядном режиме - это режим пульта

Если начинать ТАК жонглировать терминами - мы застрянем в самом начале!
В PDP-11 (от которого мы пляшем - это не режим пульта. Нужен режим пульта - так и пусть будет режим ПУЛЬТА!

А какими кусками свопить?

Зачем свопить?? У нас что - оперативка по 10 баксов за байт???

[Patron]

Нужен режим пульта - так и пусть будет режим ПУЛЬТА!

Предлагается, чтобы после включения питания - мода супервизора была замаплена на 4Гб адресов внешних устройств, где по адресу 0 начинается пультовое ПЗУ. В принципе - загруженная операционка может позже эту моду перемапить, чтобы установить собственный обработчик исключительных ситуаций, но при сбросе питания и обнулении ОЗУ - мапинг моды супервизора на пространство ввода-вывода автоматически восстанавливается.

Зачем свопить?? У нас что - оперативка по 10 баксов за байт???

Когда у нас есть два процесса, каждый из которых имеет доступ к собственному виртуальному адресному пространству 4Гб, то в общем случае без свопа не обойтись даже на машине с 4Гб ОЗУ. А если у нас 64 процесса или 1024 процесса - тогда и подавно. Поэтому 32-разрядные архитектуры изначально проектируют со свопом.

[Hunta]

мода супервизора

Пульта!!

два процесса

виртуальному адресному пространству 4Гб

Операционка будет выделять программе 4 гига оперативки, даже если программе нужно 100 байт???