Менеджер памяти для многозадачной ОС

[GriV]

(Page)+(Address)?

Нет, именно три байта.
Все проблемы с трансляцией трёхбайтового адреса на страницы на себя берёт система (менеджер).

Хотя если разбивать как Page*65536+Address, то наверное да

[Advertiser]

[dwt]

Нет, именно три байта.
Все проблемы с трансляцией трёхбайтового адреса на страницы на себя берёт система (менеджер).

А не вызовет ли эта трансляция излишних "тормозов"? Ведь, трансляция прямой трехбайтовой адресации (16MB) - дело хоть и не очень многотактовое, но как мне кажется, полная инкапсуляция "в систему" процедур обработки памяти в целом выйдет довольно-таки тактозатратным (всяческие проверки, арифметика, и т.д.).
Я имел ввиду (номер page16k)+(физический адрес).

[GriV]

да, в любом случае такая система предполагает притормаживание приложений/процессов из-за того, что происходит служебная работа (перемещение блоков памяти)
НО: такая система даёт плюс в использование виртуальной памяти ЛЮБОГО размера (до 16 метров) для блоков данных для КАЖДОГО процесса.

И ещё, при такой организации возможно при помощи виртуальной памяти "расширять" память для 48кб до 48кб+размер своп-файла на диске (или дискете)

[dwt]

да, в любом случае такая система предполагает притормаживание приложений/процессов из-за того, что происходит служебная работа (перемещение блоков памяти)
НО: такая система даёт плюс в использование виртуальной памяти ЛЮБОГО размера (до 16 метров) для блоков данных для КАЖДОГО процесса.

А цель? Цель оправдывает средства?

[GriV]

А цель? Цель оправдывает средства?

Цель в этом случае оправдывает средства.

Программист не сможет просчитать все варианты использования памяти, система же будет просчитывать всё автоматически и приложения писать становится до смешного просто: указывайте что надо использовать память, связывайте индекс и ваяйте!

[dwt]

Цель в этом случае оправдывает средства.

Программист не сможет просчитать все варианты использования памяти, система же будет просчитывать всё автоматически и приложения писать становится до смешного просто: указывайте что надо использовать память, связывайте индекс и ваяйте!

А не вызовет ли это необходимость создания языка выского уровня или хотя бы интерфейса для обработки не присущих z80 команд работы с памятью/адресов? В последнем случае команды/адреса будут передаваться посредством дека/стека/очереди/...?

[GriV]

Сам дескриптор имеет длину два байта (т.е. всего теоретически возможно 65536 процессов и из областей), но адрес задаётся тремя байтами не путайте плиз

[GriV]

А не вызовет ли это необходимость создания языка выского уровня или хотя бы интерфейса для обработки не присущих z80 команд работы с памятью/адресов? В последнем случае команды/адреса будут передаваться посредством дека/стека/очереди/...?

Чисто технически отвечу так: запрос может передаваться КАК УГОДНО (любой из указанных вариантов) текущий менеджер использует конструкцию

Call New
Defb <Старший_байт>
Defw <Слово_младшей части_адреса>

на выходе рутина даёт BC= номер дескриптора

[Vladimir Kladov]

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

[dwt]

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

В принципе, наверное, это выход из ситуации. Однако, наверное, необходимо держать эту таблицу "открытой", чтобы не вызвать излишней централизации.