Как мне кажется, основная причина появления режима Supervisor, так же DataSpace - попытка увеличить доступную для приложения память с 64 кб на что то побольшее. Поэтому смысла увеличивать количество режимов работы процессора не вижу. По идее - даже три (как и dataspace) - пока никак не просматривается - для чего? - в 32-битном режиме. Для 16-битном - да, там всё понятно.Сообщение от Patron
Идём дальше. Почему может понадобиться наличие страниц в адресуемом 4гб пространстве. Я пока вижу след. сценарии:
- Доступ из ядра в адресное пространство пользовательского процесса
- Доступ из ядра к странице в/в
- Доступ из пользовательского процесс в адресное пространства ядра
- Доступ из пользовательского процесс в адресное пространства другого процесс
- Доступ из пользовательского процесс к странице в/в
- Единственная копия библиотеки (типа FCSRES FSCFSL) в памяти и отображение на неё в адресном пространстве ядра или пользовательского процесса
- Коду ядра или пользовательского процесса выделили кусок памяти при загрузке, оно захотело больше, пробуем расширить, а за сразу за физической памятью, которая была выделена - нужного количества свободного памяти нет - занята другим процессом - возможность строить из ненепрерывных сегментов физической памяти непрерывный сегмент виртуальной памяти окажется в такой ситуации плюсом.
Первые шесть пунктов по сути описывают один и тот же сценарий. А теперь, внимание, вопрос - возможность отобразить куски своей памяти на память других процессов в количестве 2 в 20 степени штук (реально, конечно, поменьше - примерно так на один - для себя то память тоже надо иметь) - оно в какой ситуации может понадобиться? Даже моя буйная фантазия отказывает. Доступ к памяти пары десятков библиотек и пары десятков других процессов - я думаю покроют 99 процентов возможных сценариев - то есть, скажем 64 сегмента в 4гб-ом адресном пространстве - почти за глаза. Ну, что бы точно гарантировать - пусть будет 1024 сегмента. И то с моей точки зрения уже будет напоминать некоторые современные программные пакету - а давайте сделаем, что бы ВСЁ было.
Дальше вопрос - откуда взялось адресное пространство на 42 бита? 4Тб - нафига столько?
Вы чего такого объёмного собрались напихать в (свопнутую) память и получить дикие тормоза на свопе?
У меня на комп 64 гига и мне его хватает более чем за глаза за ОДНИМ конкретным сценарием - когда я начинаю развлекаться с виртуалками. Но - о возможностях виртуализации пока никто не вспомнил, это раз, а во вторых - даже пара виртуалок и половина памяти в свопе - это будет крайне "весёлая" развлекуха.
Вообщем, если не развлекаться виртуалками - много памяти не требуется, если только не идти по пути раздутых приложений и ядра - а основной цимес PDP-11 с моей точки зрения - легковесные по объёму приложения. Извините, для приложений по 4 гига у меня есть Windows и архитектуры x86-x64 - вот пусть там и остаются.
А вот тут мы получим развлекуху покруче варианта пары виртуалок с 16-гигами памяти на 4 гигах физической памяти плюс своп. Даже размещение в основном ОЗУ (которое по определению медленное по сравнению с кэш-память) - уже развлекуха. А кэш к тому добавляет дополнительного куража - MMU закэшировало дескриптор, а потом ядро взяло и изменило дескриптор в озу - получается, надо следить - кто куда и чего записал. Как бэ MMU не потребовался мощней проца.
- - - Добавлено - - -
Да, забыл про расширение памяти. RSX такой подход не использует, про другие системы ничего сказать не могу - если что то и попадалось - память молчит, зараза. Учитывая, что теоретически это ускорило бы выделение памяти (RSX вроде в такой ситуации выгружает в файл подкачки, а потом загружает в новое место с требуемым новым размером) - видимо, что то есть плохое, почему DEC решило так не выделять память. Но.. у меня мыслей на эту тему пока нет
Ответить с цитированием