С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Если даже перемапленная с пультового ПЗУ в ОЗУ мода обработки исключительных ситуаций больше похожа на "моду пульта" - пусть будет мода пульта.
Архитектуры со свопом могут работать гораздо быстрее, чем без свопа, потому что операционка получает возможность запускать на выполнение файлы любого размера, просто помечая их как "временные файлы подкачки" и без загрузки файла в память - просто передавая управление на "смотрящий в пустоту" стартовый адрес. Тогда во время исполнения программы в память попадут только те страницы файла исполняемой программы, куда будут происходить переходы и вызовы в коде.
За счёт этого гигабайтные файлы стартуют на выполнение за доли секунд, тогда как при отсутствии в архитектуре свопа - их надо или целиком загружать в память, или использовать убогую концепцию оверлеев.
Человек читает - основана на архитектуре PDP-11. Человек читал доку по PDP-11 и он знает, что такое режим супервизора на PDP-11. Человек видит - мода супервизора... Профит!
Назовём единицу выделения памяти (и подкачки) - страницей.
Только здесь. Больше нигде (я уже начинаю запутываться в терминах, значение которых отлично от тех, к которым я привык в доках по PDP-11)
Операционка пометила запускаемую программу как временный файл подкачки (кстати, в Windows аналогичный механизм носит название - файл, отображённый в память, что позволяет легко обойтись без специальных пометок, что бы не дай бог не вмешался диспетчер файла подкачки и не выгрузил в наш (временный) файл подкачки что то ещё) и передала управление на нулевую страницу - пусть там стартовый адрес. Что происходит дальше.
Операционка - я передаю управление на страницу 0
MMU - упс, памяти нет - подгружаем.
Программа - я передаю управление на страницу 20
MMU - упс, памяти нет - подгружаем.
Программа - я передаю управление на страницу 21
MMU - упс, памяти нет - подгружаем.
Программа - я передаю управление на страницу 100
MMU - упс, памяти нет - подгружаем.
Программа - я передаю управление на страницу 101
MMU - упс, памяти нет - подгружаем.
Программа - я передаю управление на страницу 120
MMU - упс, памяти нет - подгружаем.
Программа - я передаю управление на страницу 12
MMU - упс, памяти нет - подгружаем.
Программа - я передаю управление на страницу 45
MMU - упс, памяти нет - подгружаем.
....
Пусть размер программы - 150 страниц.
Вы серьёзно думаете, что в 150 запросов чтения по странице выполнятся быстрее, чем один, читающий 150 страниц за раз? (помните, у нас памяти сейчас у нас... как грязи)
Это называется "отображение файлов в память" и так сейчас работают все операционки. Но ничто не мешает иметь два варианта архитектуры - со свопом и без. В архитектурах без свопа есть только один способ, как при старте программы не загружать её в память целиком - использовать оверлеи.
- - - Добавлено - - -
Возможно не все знают, что программа DIR в RT-11 v5.0 стала оверлейной не потому, что не лезла в память, а для того, чтобы при обычном просмотре каталога с диска считывались только первые блоки программы и лишь при использовании различных экзотических режимов - подгружался оверлей, обрабатывавший дополнительные ключи запуска.
Похоже, чтение идёт избранных мест.
ЗАЧЕМ МОЖЕТ ПОНАДОБИТЬСЯ НЕ ЗАГРУЖАТЬ ПРОГРАММУ В ПАМЯТЬ ЦЕЛИКОМ, если у нас не монструозные программы и памяти как грязи??
Расскажите это динамически-загружаемым библиотекам, которые, кстати, существовали уже в RSX-11M-Plus, а я делал для RSX-11M в восемьдесят-лохматом году.
Не знаю как там с юникс-системах (на 32-битных процах), но в PDP-11 оверлеи - это способ ПОВТОРНО использовать адресное пространство в первую очередь. А ещё был такой вариант - оверлеи, резидентные в памяти, в системах с MMU (насчёт поддержки под XM монитором не скажу - но по идее должна быть, а уж в RSX - даже в M были) - когда программа целиком располагалась в памяти, но тем не менее использовала оверлеи.
- - - Добавлено - - -
Что даёт хорошо заметный эффект ускорения работы программы на чём нибудь типа DX01 - но нахрен не нужно уже даже на дисках типа RK05 при том размере, который у DIR. Или Ваш замечательный 32-битный проц Вы планируете использовать вместе с DX01??
В системах с файловым отображением памяти - они просто отображаются (без обращения к диску), а в RSX - загружаются с диска только те подпрограммы динамической библиотеки, к которым идёт обращение, или всю библиотеку надо загружать целиком?
Но зачем отказывать любому из двух вариантов в праве на существование. Сэмулировать можно обе архитектуры, но портировать RSX конечно проще на вариант без свопа.
В варианте без свопа 32-разрядный MMU может быть весьма похож на 16-разрядный. На шине будут видны два набора 16-разрядных PAR и PDR - системный и предыдущей моды ( по номеру из битов предыдущей моды в PSW ). 64 регистра PAR могут разбить 4Гб адресов на 64 окна максимальным размером 64Мб и минимальным 64Кб ( с шагом 64Кб ). Если флаг PageWritten перенести в 4-й бит - 16-разрядный PDR позволяет иметь поле PLF длиной 10 бит ( что при странице 64М даёт минимальный размер страницы 64К и шаг размера 64К ).
Для 1024 мод от MMU потребуется 1024*64*16*2 = 2Мб внутренней памяти.
Возможно лучше, чтобы пара 16-разрядных PAR+PDR занимала один 32-разрядный регистр MMU, причём более часто используемый регистр был в младшем слове.
С моей точки зрения - MMU о свопе вообще ничего не должен знать. Его задача (крайне быстро) отобразить виртуальный адрес на физический, проверить возможность записи (если команда пытается что то записать в память) или выдать прерывание - если виртуальный адрес не отображён на физический или писать нельзя. Всё. Своп - прерогатива операционки (если она будет его поддерживать).
Про остальное ничего пока сказать не могу - это уже конкретика (причём конкретика одного блока проца) - и что бы ответить на неё - нужна архитектура в целом и ответ на вопрос - зачем (нам это может понадобиться)? А мы пока ещё далеко в самом начале проекта архитектуры.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)