NedoOS

[SfS]

шоб быстрее было ЖО
дрочить через один вызов это тютю

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

В чём "быстрее"? Всё равно функция задаётся через какой-то регистр. Какая разница - иметь таблицу из 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

Чем поможет размазывание по рестартам - непонятно.

[Advertiser]

[Sayman]

В чём "быстрее"?

быстрее во всём. удобнее, нагляднее, логичнее иметь несколько точек входа в разные уровни API. Например, rst 8 для обращения к BIOS в котором лежат низкоуровневые процедуры и функции. rst 0x10, для вызова dos/bdos. rst 0x18, для обращения к логическим драйверам и т.д. твой вариант тоже интересен, но он значительно медленнее. Сначала делать

call store_context_and_set_system_page
// Сохранили всё, что надо для вызова и включили системную страницу с адреса 0xC000
// считаем, что bc не изменяется при вызове

а потом уже идёт вызов системы. представь. что в программе идёт какая-то загрузка каких-то данных с одновременным выводом информации на экран/терминал. соответственно. чем больше вызовов, тем медленнее будет работать программа, т.к. вызов загромождён не нужными процедурами. А когда у тебя, скажем:

;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

то всё работает в разы быстрее, занимает меньше места, нагляднее и удобнее. тем более, что rst это 1 байт против 3х если использовать всякие call`ы.

256 функций - это таблица из 512 байт.

Надо больше функций? Делаем таблицу больше.

и в результате твоя система превращается в кашу аля недоос, где все уровни смешаны в одну кучу, где при добавлении просто драйвера какой нить флешки, слетает вся система и всё начинает тупить (а то ещё и диск убивать).
ещё и с описанием будет каша аля тазис, в которой ВНЕЗАПНО работа с каталогами затесалась в "уровень" ccp. серия номеров функций без разделения на логические, дос, ioctl и другое, всё в одной куче.
спасибо, лично мне такие системы не интересны.

а ещё повеселил ответ на твой вопрос на тамошнем форуме... но то такое...

[NEO SPECTRUMAN]

В чём "быстрее"? Всё равно функция задаётся через какой-то регистр. Какая разница - иметь таблицу из 8 функций или из 256 ?
На фоне всего остального выигрыш в скорости практический нулевой.

си головного моска?