я незнаю как на орионе, но относительно профи "дальние" вызовы особых проблем не имеют. конечно, есть потеря скорости, однако не критично, особенно если учесть факт наличия турбы. на профи все дрова или их большая часть сидит в 5й странице. особо не замечал каких-либо проблем или тормозов при их вызове. кроме того, дабы избежать потери данных со стека оставшегося в другой странице, никто не мешает переставить стэк в окно, которое не участвует в переключениях страниц. тем более если требуется передать какие либо короткие ответы от функции. несколько байт можно и переставить, разве нет?
а тормознутость юзикса объясняется ещё и тем, что во1х, ты посмотри на библиотечные вызова, тот же fopen, насколько он прожорлив и здоровый. printf и другие. очень много ляпов в системе и лишних условий, которые можно или сократить, упростить или развернуть. а второй юзикс, согласно переписке с автором, большей частью написана с преминением вставок ассемблера. там даже один и тот же файл (программа) занимает меньше места, чем у первого юзикса.
к сожалению не всех.Вызов всех процедур libc через диспетчер (0008h) осуществляется с передачей параметров (и результата) в регистрах
а если говорить непосредственно про библиотечные вызовы, то они диспечер то вобщем и не используют, за редким исключением когда делают вызовы типа открытия файла/потока и подобное. а вот возврат как раз в регистрах:Код:asm(" psect text,class=CODE"); asm(" global __sys__3"); asm(" global _mount"); asm(" signat _mount,12346"); asm("_mount:"); asm(" pop hl"); asm(" ex (sp),hl"); asm(" push hl"); asm(" ld hl,19"); asm(" jp __sys__3"); ... asm("__sys__3:"); asm(" push bc"); /* the third value is already in stack */ asm(" push de"); asm(" push hl"); dosyscall(); ... #define dosyscall() asm(" call " __str1(SYSCADDR)) ... #define SYSCADDR 8 /* System call routine */
* System call structure:
* Arguments passed through stack: unix(#,arg1, arg2, ...)
* Result returned in DE:HL (LSB/MSB form)
* If error found then CY=1 and BC=errno




Ответить с цитированием