Для системных вызовов достаточно одного.
Смысл их размазывать по всем рестартам?
Вид для печати
В чём "быстрее"? Всё равно функция задаётся через какой-то регистр. Какая разница - иметь таблицу из 8 функций или из 256 ?
На фоне всего остального выигрыш в скорости практический нулевой.
256 функций - это таблица из 512 байт. Если её в отдельной странице сделать (а ОС в любом случае в отдельной странице) - то никаких проблем. Грубо говоря, любой системный вызов это нечто вроде:
Надо больше функций? Делаем таблицу больше. Примерно так.
Чем поможет размазывание по рестартам - непонятно.Код:;// гдето в коде ПО bc - номер системного вызова. Остальные регисты - параметры (или стек, не важно)
ld bc,#os_call_number
rst 8
.................
;// Системный рестарт (для примера RST8)
org 0x0008
// Вход
RST8_entry:
call store_context_and_set_system_page
// Сохранили всё, что надо для вызова и включили системную страницу с адреса 0xC000
// считаем, что bc не изменяется при вызове
// Вычисляем адрес обработчика системной функции
ld hl,#0xC000
add hl,bc
ld c,(hl)
inc hl
ld b,(hl)
push bc
ret // Переходим на обработчик
// Выход
RST8_exit:
call restore_context_and_set_progpage
ret
быстрее во всём. удобнее, нагляднее, логичнее иметь несколько точек входа в разные уровни API. Например, rst 8 для обращения к BIOS в котором лежат низкоуровневые процедуры и функции. rst 0x10, для вызова dos/bdos. rst 0x18, для обращения к логическим драйверам и т.д. твой вариант тоже интересен, но он значительно медленнее. Сначала делать
а потом уже идёт вызов системы. представь. что в программе идёт какая-то загрузка каких-то данных с одновременным выводом информации на экран/терминал. соответственно. чем больше вызовов, тем медленнее будет работать программа, т.к. вызов загромождён не нужными процедурами. А когда у тебя, скажем:Цитата:
call store_context_and_set_system_page
// Сохранили всё, что надо для вызова и включили системную страницу с адреса 0xC000
// считаем, что bc не изменяется при вызове
то всё работает в разы быстрее, занимает меньше места, нагляднее и удобнее. тем более, что rst это 1 байт против 3х если использовать всякие call`ы.Код:;RST 10h
jp sys ; вектор ДОС-а
...
;-------------------------------------------------
; ДОС-овый вектор
;-------------------------------------------------
sys: push hl
ld l,c ; номер команды
ld h,sys_tbl / 256 ; 0200h..02FFh массив мл.байтов адресов
ld c,(hl) ; загр. мл.байт адреса
inc h ; 0300h..03FFh массив ст.байтов адресов
ld h,(hl) ; загр. ст.байт адреса
ld l,c ; готовый адрес
ex (sp),hl ; в стек и
ret
Цитата:
256 функций - это таблица из 512 байт.
и в результате твоя система превращается в кашу аля недоос, где все уровни смешаны в одну кучу, где при добавлении просто драйвера какой нить флешки, слетает вся система и всё начинает тупить (а то ещё и диск убивать).Цитата:
Надо больше функций? Делаем таблицу больше.
ещё и с описанием будет каша аля тазис, в которой ВНЕЗАПНО работа с каталогами затесалась в "уровень" ccp. серия номеров функций без разделения на логические, дос, ioctl и другое, всё в одной куче.
спасибо, лично мне такие системы не интересны.
а ещё повеселил ответ на твой вопрос на тамошнем форуме... но то такое...
В MS-DOS почти все API через int 21h, в Linux - системные вызовы через int 80h. И ничего, работает.
да, если не считать того, что ms-dos и тем более Linux это x86, где любая команда выполняется быстрее, чем на нашем зетнике и памяти чуть побольше. сравнивать не стоит. тут даже какая-нить ссаная атмега8 будет быстрее, чем z80. а вы ещё всё повешать в одну кучу желаете. да и лукавите вы слегка, ведь всё, что касается ioctl, резидентов и прочего подобного, в MS-DOS убрано в другие INT. например, в INT 25h, INT 2Fh.
про линукс речи вообще нет. система с совершенно иной идеологией, написанная на сях. К слову сказать, в uzix и fuzix используется аналогичная метода вызова. ну и что, ка к оно там, быстро всё работает на z80? не видно толп пользователей что-то и тонн софта.
оно медленно работает из-за всего, мало того, что там си, так ещё и диспетчер медленный.
я там выше привёл рабочий пример. оно работает быстрее, чем вариант от Sfs. при этом есть такие моменты:
1. человек который пилит систему не путается в модулях/уровнях системы. например, можно спокойно добавить новый, скажем, isa-cf читалки. даже если что-то косячнул в нём, остальные драйвера не слетают и система будет продолжать работать.
2. у пользователя не будет в голове каша при чтении мануалов. он читает раздел посвящённый bdos, к примеру и понимает, что к этим функциям обращается через rst 0x10. а если ему по какой-то причине нужно напрямую сектора читать (например, пишет fdisk), то для этого он может использовать rst 8. соответственно берёт в руки мануал на биос и изучает его. и никакой путаницы нет. и главное, диспетчер быстро отправляет на нужную функцию, т.к. оптимизация. табличка со списком функций лежит на кратном 256 адресе. процедура вызова очень короткая. ваши придирки к пачке rst не ясны, очевидно же, что с целью оптимизации места и тактов. при этом суть и логика не теряется.
к сожалению к недооси это всё слабо относится, т.к. там как раз всё свалено в одну кучу, чего делать не стоит.
дык а я и не поклонник сабжа ;)
Так о чём и речь.
Если бы надо было всего 8 вызовов - то рестартов бы хватило. А так - на каждый рестарт в итоге СВОЯ таблица. Скорости это не прибавляет. Зато всё мешает в кучу.
- - - Добавлено - - -
Нет, рациональный подход. Вызовов много. Памяти тоже не 48к (мы ж про АТМ и EVO говорим). ЧТо мешает иметь таблицу, например в 2К величиной и там хранить до 1024 адресов функций?
Это полюбому быстрее, чем извращения с мильёнами рестартов.
Но самое главное, добавить новый вызов - элементарно, не трогая остальных.