Эксперимент

[SfS]

Я предлагал вроде втроить их, но это не значит, что их надо использовать. По идее программе полная свобода. А выбор типа интерфейса и используемых программ производить самому на этапе сборки или подготовки к использованию.

И вообще, мне как-то ОС видиться больше в статическом исполнении (типа держишь в ОС, что тебе надо). Там я ещё писал, из-за переключения контекста надо делать выгрузку области программ. Поскольку держать уровни ОС там накладно (размеры) и невозможно (выгрузка области), то есть пока только идея расположить ОС в области ПЗУ или теневом ОЗУ (чтоб не занимать память в "области программ" вынести необходимые уровни ОС в другое место). Хотя можно конечно в виде программ в страницах использовать, но вот как эта программа будет обрабатывать данные из других страниц?

На критику "по делу" не обижаюсь - это неоценимаю помощь.

Если писать нормальную ОСЬ - однозначно надо пихать ее в ПЗУ (или теневое ОЗУ с 0). Для работы с другими страницами создается некий стандарт (хотябы по принципу, предложенному мной) и приведенную тут http://zx.pk.ru/showthread.php?t=507&page=7&pp=10 или то что привел Griv там же.
При этом все программы под ОСЬ, должны будут придерживаться этого стандарта.

Насчет статичнского-динамического исполнения. Тут надо сделать возможность указать при сборке что в статике компилировать, а что в виде подгружаемых модулей.
Скажем драйвер стандартного экрана - сразу к ядру присобачивается, драйвеа мыши, клавиатуры. А вот драйвер какого-нибудь экрана 320х200х256 - он может либо быть встроен в ядро, либо вообще исключен (если у юзера нет такого режима), либо откомпилирован в виде отдельного модуля, подгружаемого по мере надобности.

Еще по поводу RST-JUMP и системных вызовов. Однозначно в ОСЬ должна быть ОДНА точка входа. Причем для вызова ОС использовать надо call.

call #SYSTEM
db num_func
db param1
db param2
...

Тогда во-первых приятно писать, а во-вторых можно использовать call необходимо, чтобы можно было саму ОС запихать в любую часть памяти

[Advertiser]

[Alex/AT]

Все это изврат, если честно. Если у нас будет динамическая линковка ("DLL"), то эти проблемы с релоцируемостью отпадают.

[SfS]

Все это изврат, если честно. Если у нас будет динамическая линковка ("DLL"), то эти проблемы с релоцируемостью отпадают.

Так помоему речь и идет о спецификации на память, чтобы реализовать DLL, Reloctable и т.д.)

[Alex/AT]

А тогда нафига таблицы переходов??? ОС грузит бинарник, попутно по меткам в нем проставляя все адреса. Достаточно простой таблицы адресов для "подсовывания" в бинарник.

[acidrain]

Еще по поводу RST-JUMP и системных вызовов. Однозначно в ОСЬ должна быть ОДНА точка входа. Причем для вызова ОС использовать надо call.

call #SYSTEM
db num_func
db param1
db param2
...

Тогда во-первых приятно писать, а во-вторых можно использовать call необходимо, чтобы можно было саму ОС запихать в любую часть памяти

Если имелся ввиду мой коммент, то я писал о библиотеках (некоторые на пц вариант опсывают их длл-ками), а про вход в ось - он точно должен быть один, как на амиге
И почему отпадают проблемы с релоцируемостью? Если в систему все либлы релоцируемы, а ваша прога с фиксированного адр. должна пускаться, а ее место уже занято под, например, системные переменные - то тогда и вся ось в сад из-за корявого прогерра? В нормальной ос не должно быть прог с фиксированными адр. кроме единственной точки входа в ось. А саму ось, при необходимости мона будет в верхние страницы запхать, ну вдруг кому преспичит? ПЗУ- в сад, на стандартном спеке без переделки возможно теневую страницу озу с 0го адр. выставить? Тогда о чем может быть речь?

[Alex/AT]

Если в систему все либлы релоцируемы, а ваша прога с фиксированного адр. должна пускаться

Не должно такого быть. И точка. А точка входа в ось тоже не обязана быть фиксированной. Можно "на лету" при загрузке подставить релокейшны.

[SfS]

А саму ось, при необходимости мона будет в верхние страницы запхать, ну вдруг кому преспичит? ПЗУ- в сад, на стандартном спеке без переделки возможно теневую страницу озу с 0го адр. выставить? Тогда о чем может быть речь?

Я думаю, что ОС должна мочь собираться и для работы из теневой страницы и для работы из верхней страницы ОЗУ. А если все ограничивать только стандартом 128 - то ничего хорошего не будет.
То есть ОС должна работать и в стандарте и в расширенных компах типа АТМ.

[acidrain]

Я думаю, что ОС должна мочь собираться и для работы из теневой страницы и для работы из верхней страницы ОЗУ. А если все ограничивать только стандартом 128 - то ничего хорошего не будет.
То есть ОС должна работать и в стандарте и в расширенных компах типа АТМ.

Дык, я об том же =)

[acidrain]

Не должно такого быть. И точка. А точка входа в ось тоже не обязана быть фиксированной. Можно "на лету" при загрузке подставить релокейшны.
Alex/AT вне форума Добавить к репутации Alex/AT Пожаловаться на это сообщение

Точно, как на амиге =)
Вообще этот тред стал напоминать нечто вроде "докажи эсиду то, о чем он и говорит, а то этот тупарь (эсид) умничает много говорит то, о чем мы и так знаем" =)
Может более конструктивно будем общаться и вникать в то, что пишет другой человек? =)))

Ничего личного - это у меня сложилось такое впечатление 8)

[fk0]

Цитирую:

В программирование на ассемблере в объектно-ориентированном стиле
особенных сложностей не доставляет. В вызываемый метод-функцию просто
передаётся указатель на объект. А как быть, если имеем дело с виртуальными
функциями? Тут к каждому объекты добавляется ссылка на таблицу адресов
виртуальных функций. Продемонстрирую на примере:

; Создадим объект, на стеке. Для большей наглядности того, что статических
; адресов нигде нет.

ld hl, size_of_object - 2
add hl, sp
ld sp, hl
push hl
ld hl, object_virtual_table
ex (sp), hl
push hl
call object_constructor
pop hl
....

; Теперь используем объект. В данную функцию передаётся указатель на объект
; типа созданного ранее, или унаследованный от него.
; HL = указатель на объект.
function:
push hl
call some_virtual_function
pop hl
call some_non_virtual_function
....

; вызванная функция-метод, общая для всех унаследованных объектов
; просто перенаправляет вызов через таблицу виртуальных функций
some_virtual_function:
ld a, object_function_no * 3
jp call_virtual

; тело виртуальной функции конкретного объекта
some_virtual_function_body:
....
ret

; тело невиртуальной функции
some_non_virtual_function:
...
ret

; таблица виртуальных функций конкретного объекта
object_virtual_table:
jp some_virtual_function_body
object_function_no equ 0
jp some_virtual_function2_body
object_function2_no equ 1
jp some_virtual_function3_body
object_function3_no equ 2
...

; вспомогательная процедура, для вызова через таблицу виртуальных функций
call_virtual:
push hl
add a, (hl)
inc hl
ld h, (hl)
ld l, a
adc a, h
sub l
ld h, a
ex (sp), hl
ret ; 93 такта от some_virtual_function

Я предполагаю, что указатель на объект передаётся всегда в регистре HL,
а в регистре AF никогда и никаких аргументов не передаётся.

Итого получается, что на вызов невиртуальной функции-метода требуется
всего 27 тактов процессора (call + ret), а на вызов виртуальной функции
аж 120 тактов, вместе с первым call и последним ret. И ещё регистр AF
нужен.

Кроме того, см: http://cdwalk.narod.ru/modules.html, http://cdwalk.narod.ru/ide-driver.html.
Предлагается в качестве стандарта, независимо от каких-либо ОС.
В настоящее время планируется COM-подобная (component object model)
система, с немного другой структурой модуля.