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

[Vitamin]

насчет memcpy и проч.
данные функции просто необходимо включить в ядро по той простой причине, что ядро предоставляет свой интерфейс доступа к памяти. они будут работать с дескрипторами блоков, осуществлять самые быстрые алгоритмы, возможно даже с использованием аппаратных средств. для работы в локальной памяти конечно хватит ldir и иже с ним.

насчет вызовов.
зачем тратить память (3 байта на каждую точку) и время (10 тактов на вызов), организуя набор точек перехода? или тратить туеву хучу тактов на интерпретацию параметров рестартов? если можно сделать так, что система будет подставлять адреса вызовов в тело процесса, настраивая его. не считая время на настройку, получаем 2 лишних байта на точку входа (таблицу-то надо хранить) и никаких лишних тактов на вызов

[Advertiser]

[random]

таблица необходима для совместимости! чтобы программы все не пересобирать когда будут явные системные изменения!!!

[Vitamin]

таблица необходима для совместимости! чтобы программы все не пересобирать когда будут явные системные изменения!!!

читай внимательней предыдущий пост. не компилятор будет подставлять адреса, а СИСТЕМА. т.е. начихать что там адреса физические сменились. лишь бы порядок нумерации не менялся (на нем основывается подстановка)

[random]

ты чего, предлагаешь делать DLL сразу же? не быстровато ли? по любому будет проще систему собирать если у самой системы есть общая таблица всех вызовов. и не 4 байта а всего 2, если не хотите версии проверять.

[Vitamin]

ты чего, предлагаешь делать DLL сразу же? не быстровато ли? по любому будет проще систему собирать если у самой системы есть общая таблица всех вызовов. и не 4 байта а всего 2, если не хотите версии проверять.

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

[Vladimir Kladov]

лично мне нравится вызов системных функций через RST - это сокращает код, на 1 байт на вызов как минимум, и неважно, что на интерпретацию кода уходит еще несколько тактов. И одновременно решает вопрос независимости от версии осы - лишь бы номера функций совпадали. А загрузчику можно было бы доверить подгонку адресов в самой загружаемой программе "по месту", не всегда в Z80 удается делать код перемещаемым без само-подгонки. Вот на ось и можно было было бы положиться.

[Vitamin]

лично мне нравится вызов системных функций через RST - это сокращает код, на 1 байт на вызов как минимум, и неважно, что на интерпретацию кода уходит еще несколько тактов. И одновременно решает вопрос независимости от версии осы - лишь бы номера функций совпадали.

что короче:
ld a,func_number
rst N

или

call NNN
?

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

[Spectre]

что короче:
ld a,func_number
rst N

или

call NNN
?

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

А если метод которому уже почти 25 лет?

RST n
DB n

[Vitamin]

А если метод которому уже почти 25 лет?

RST n
DB n

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