Для системных вызовов достаточно одного.Цитата:
Сообщение от NEO SPECTRUMAN
Смысл их размазывать по всем рестартам?
Вид для печати
Для системных вызовов достаточно одного.Цитата:
Сообщение от NEO SPECTRUMAN
Смысл их размазывать по всем рестартам?
шоб быстрее было ЖОЦитата:
Сообщение от SfS
дрочить через один вызов это тютю
ладно если бы ты сказал что точка входа плавающая и выдаются для программы в произвольно необходимом месте
тогда это было может быть и актуально
а так ось прибита к первым n байтам гвоздями...
В чём "быстрее"? Всё равно функция задаётся через какой-то регистр. Какая разница - иметь таблицу из 8 функций или из 256 ?Цитата:
Сообщение от NEO SPECTRUMAN
На фоне всего остального выигрыш в скорости практический нулевой.
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, для обращения к логическим драйверам и т.д. твой вариант тоже интересен, но он значительно медленнее. Сначала делатьЦитата:
Сообщение от SfS
а потом уже идёт вызов системы. представь. что в программе идёт какая-то загрузка каких-то данных с одновременным выводом информации на экран/терминал. соответственно. чем больше вызовов, тем медленнее будет работать программа, т.к. вызов загромождён не нужными процедурами. А когда у тебя, скажем:Цитата:
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.Цитата:
Сообщение от marinovsoft
про линукс речи вообще нет. система с совершенно иной идеологией, написанная на сях. К слову сказать, в uzix и fuzix используется аналогичная метода вызова. ну и что, ка к оно там, быстро всё работает на z80? не видно толп пользователей что-то и тонн софта.
А оно медленно работает именно из-за того, что мало количество точек входа ?Цитата:
Сообщение от Sayman
То же самое можно сказать и о NedoOS.Цитата:
Сообщение от Sayman
си головного моска?Цитата:
Сообщение от SfS
оно медленно работает из-за всего, мало того, что там си, так ещё и диспетчер медленный.Цитата:
Сообщение от marinovsoft
я там выше привёл рабочий пример. оно работает быстрее, чем вариант от Sfs. при этом есть такие моменты:
1. человек который пилит систему не путается в модулях/уровнях системы. например, можно спокойно добавить новый, скажем, isa-cf читалки. даже если что-то косячнул в нём, остальные драйвера не слетают и система будет продолжать работать.
2. у пользователя не будет в голове каша при чтении мануалов. он читает раздел посвящённый bdos, к примеру и понимает, что к этим функциям обращается через rst 0x10. а если ему по какой-то причине нужно напрямую сектора читать (например, пишет fdisk), то для этого он может использовать rst 8. соответственно берёт в руки мануал на биос и изучает его. и никакой путаницы нет. и главное, диспетчер быстро отправляет на нужную функцию, т.к. оптимизация. табличка со списком функций лежит на кратном 256 адресе. процедура вызова очень короткая. ваши придирки к пачке rst не ясны, очевидно же, что с целью оптимизации места и тактов. при этом суть и логика не теряется.
к сожалению к недооси это всё слабо относится, т.к. там как раз всё свалено в одну кучу, чего делать не стоит.
дык а я и не поклонник сабжа ;)Цитата:
Сообщение от marinovsoft
Так о чём и речь.Цитата:
Сообщение от marinovsoft
Если бы надо было всего 8 вызовов - то рестартов бы хватило. А так - на каждый рестарт в итоге СВОЯ таблица. Скорости это не прибавляет. Зато всё мешает в кучу.
- - - Добавлено - - -
Нет, рациональный подход. Вызовов много. Памяти тоже не 48к (мы ж про АТМ и EVO говорим). ЧТо мешает иметь таблицу, например в 2К величиной и там хранить до 1024 адресов функций?Цитата:
Сообщение от NEO SPECTRUMAN
Это полюбому быстрее, чем извращения с мильёнами рестартов.
Но самое главное, добавить новый вызов - элементарно, не трогая остальных.
можно так оптимизировать что и прибваитЦитата:
Сообщение от SfS
СВОЯ таблица может быть сокращенной и не адресовать все 64К адресного пространства
и работать она будет быстрее
пример вообще без таблицы
rst_10
ld h,$20
ld l,a
jp (hl)
так понятно почему нужны все рсты?
- - - Добавлено - - -
сто пудова сяпаскалист :)Цитата:
Сообщение от SfS
ШТА?Цитата:
Это полюбому быстрее
Код: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
store_context_and_set_system_page:
push:push:push
или ещё как аргументы кидаем, регистры сохраняем
ret
такты считать будем или как?Код:;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
;возврат в процесс по ret, без всяких call чего то там
Цитата:
на каждый рестарт в итоге СВОЯ таблица.
в контексте затрат по памяти нет разницы - будет это 2 таблицы рестартов или 1, но сразу на 512 адресов (или 1024 или ещё там как).Цитата:
ЧТо мешает иметь таблицу, например в 2К величиной и там хранить до 1024 адресов функций?
и ты предлагаешь делать очередной тазис/издос. в котором всё засунуто в одну кучу. и bdos и драва и ioctl и остальное и пофиг на всё.
даже в старой cp/m есть разделение на уровни. есть bdos, есть bios, есть ccp. и попробуй там через call 5 к bios`у обратиться)))
:v2_dizzy_facepalm:Цитата:
Сообщение от Sayman
и этот товарищь мне что то рассказывал про *****код?
Ты привёл по факту то же, что и я, но БЕЗ сохранения контекста задачи. Вопросов нет - контекст можно сохранять-восстанавливать и внутри вызова где-то. Но главное - это делать придётся обязательно. Многозадачные ОС по-другому не работают.Цитата:
Сообщение от Sayman
А с одним ресетом они с чего слетят?Цитата:
Сообщение от Sayman
Ну это уж совсем какаято чушь.Цитата:
Сообщение от Sayman
Элементарно же. Никакой программист не станет писать константы числами.
Скажем
// Уровень FS
#define FS_OPEN 0x10
#define FS_CLOSE 0x11
#define FS_READ 0x12
#define FS_WRITE 0x13
#define FS_FCNTL 0x14
// Уровень устройства
#define SD_READ_SECTS 0x100
#define SD_WRITE_SECTS 0x101
И какая разница - разнесено это по рестартам или нет? Всё понятно.
БИОС и БДОС это CP/M-ная чушь. Строго говоря и DOS и CP/M это не ОС, а запускалки прог с драйвером диска.Управления памятью нет, задач нет, драйверов нет как таковых по сути...
- - - Добавлено - - -
Нет, не будем. Потому что у тебя НЕТ сохранения и восстановления контекста задачи. А раз есть задача, то её контекст надо сохранять и восстанавливать при системных вызовах.Цитата:
Сообщение от Sayman
Мы ж не об абстрактном вызове говорим, а об ОС.
это у тебя сильно неправильное понемание понятия ОСЦитата:
Сообщение от SfS
а драйвера там как часть самой ос
программы же не пишут там на прямую в видео память и не опрашивают клавиатуру
все абстрагировано от прямого обращения к железу
что там тебе не понравилось? в каком месте ты *****код увидел?Цитата:
Сообщение от NEO SPECTRUMAN
а почему они должны обязательно быть?Цитата:
Сообщение от SfS
оно происходит из того времен когда не лишней памяти не многозадачности не было
Это ошибка большинства - оптимизировать до укакашки несущественную мелочь, но при этом использовать готовые библиотеки той же FAT, которые едят в 1000 раз больше времени, чем что твой код, что мой. Вопрос - зачем? Ну дадут все эти извращения 1% скорости. А то и меньше. И? Зато системность - в хлам.Цитата:
Сообщение от NEO SPECTRUMAN
Да, я и Сяпаскалист и джаваскриптист и ASM48ист и Z80ASMист...Цитата:
Сообщение от NEO SPECTRUMAN
Ты ж пойми простую вещь. Я не играю тут в конкурс "как за меньше тактов вызвать подпрограмму". Это глупо просто, считать такты вызова системного вызова без учёта времени переключения контекста, времени работы драйвера и прочего.
В теории оптимизации программ прекрасно сказано, что сначала надо понять - на что тратит основную часть времени программа, а потом эту часть и оптимизировать.
А тут ситуация - "ой я 16 тактов сэкономил! я крут". А то, что потом потратил в другом месте 160000 тактов - забыл..
- - - Добавлено - - -
Потому что мы говорим опять же не про абстрактную ОСь в вакууме, а про NedoOS, где это всё предусмотрено каком-то виде, да?:)Цитата:
Сообщение от NEO SPECTRUMAN
Если хочется померяться размером тактов - то пожалуйста без меня. Я не крутой кодер. Мне интересно именно построение ОС, причём правильное её построение. То есть уровни драйверов, управления памятью, переключения задач. Но не оптимизация ради оптимизации.
конечно если у тебя процедура "нахерачить содержимое 3К буфера" на экран то время вызова роли и правда играть не будет (но в этот буфер нужно еще предварительно что то накедать а это двойная работа)Цитата:
Сообщение от SfS
но если процедура "напечатать 1 символ на экран" то эти твои 16 тактов умножаются на 100500
и выигрыш уже достаточно ощутимый
В ДОС так и было часто - писали напрямую в видеопамять и даже опрашивали клавиатуру) Особенно в играх. Да и в CP/M тоже...Цитата:
Сообщение от NEO SPECTRUMAN
я знаюЦитата:
Сообщение от SfS
система же не предоставляла того чего хотелось аффтару
а если и предоставляла то в крайне извращенной и тормозной форме
не пригодной для использования во времена медленных машин
Это вопрос уже к тому, кто пишет прикладное ПО. Или он будет по одному каждый символ на экран пихать или сразу строками по 768 символов)Цитата:
Сообщение от NEO SPECTRUMAN
И вне зависимости от всего - проблема "сохранить контекст при вызове и восстановить его при выходе" - никуда для многозадачной ОС не денется.
Ну вызовешь ты системный вызов сверхбыстро. А внутри вызова опять - сохранить контекст, вызвать процедуру печати, восстановить контекст... То есть то же самое.
щас тоже опрашивают через ЖЦитата:
Сообщение от SfS
в обход того что настроил под себя пользователь
и рисуют окошки средствами *****х Qt
на которых системные настройки и всякие там Accessibility не распространяются
и пользователь потом вспоминают эти *****е кросплатформенности на которые ему вообще насрать...
То есть проблема в непрдуманности предоставления ресурсов по сути.Цитата:
Сообщение от NEO SPECTRUMAN
В настоящее время, например, уже есть такая продуманность. И по памяти. И по экрану.
Например, предоставление экрана как фреймбуфера определённого формата. Скажем, пользователь говорит - хочу стандартный экран спека. Система - да ради бога, вот тебе страница номер такая-то, пиши в неё. И всё.
ты еще забыл про вставить 5 nop-ов а чтоб было...Цитата:
Сообщение от SfS
- - - Добавлено - - -
а скажем пользователь говоритЦитата:
Сообщение от SfS
хачу экран АТМ
а у него экран профи
и тут начинается
или нужно пользователя послать
или нужно конвертер чужого экрана
а их нужно
ATM 320x200 > 6912
ATM 640x200 > 6912
profi 512xXЗ > 6912
16c > 6912
ATM 320x200 > profi 512xXЗ
ATM 640x200 > profi 512xXЗ
16c > profi 512xXЗ
ATM 320x200 > 16c
ATM 640x200 > 16c
profi 512xXЗ > 16c
итд
А ТУТ ВНЕЗАПНО оказывается что эти экраны местами жестко прибиты к некоторым страницам
а в этих страницах уже что то лежит и нужно перемещать...
а видео режимов гораздо больше
и количество работы овер чем дофига
или нужно полное абстрагирование от железа и тормоза
и тогда пользователь говорит
"хачу экран 6912"
а ему говорят "а нехрена пишите в 32 битный линейный буфер который на 128К занимает 150% всей памяти"
а наша ОС через 7 000 000t возможно отобразит его содержимое на экран...
вот по этому ОС для старых компов и не нужна
а нужен драйвер диска изапускалка программ которые сами пишут в железо
- - - Добавлено - - -
а так я тоже хочу ОС
чтоб одни и те же программы запускались и на спектруме и на специалисте и на *****м мсх-е
и чтоб была адаптация видео буфера под имеющийся видео режим
и чтоб плавающие точки входа (а не только возможность запускать на одном только АТМ)
и чтоб был jit рекомпилер для запуска ненативного кода
и чтоб это работало на минимально конфигурации на РК86 с 32к рамы и матафоном...
...но все хотелки не поместятсо же никуда...
а ну да
никто ж не будет под оно писать
тк оно все будет дико медленно
а люди хотят мультиколоров!
на сегодняшний день CP/M и его клоны пока единственные адекватные системы для z80 и рядом стоящих процессоров (вроде 6502 и иже с ними). массовей систем для подобных процессоров пока никто не придумал. будешь первым?Цитата:
Сообщение от SfS
пускалка это tr-dos, которая по сути своей есть расширение для бейсика. про дос:Цитата:
Строго говоря и DOS и CP/M это не ОС, а запускалки прог с драйвером диска.
так что дос умеет управлять памятью (это если про ms-dos говорить). про cp/m: реализаций этой системы вагон и малая телега. среди разных клонов есть и такие, где есть управление памятью. примером является profi-dos/pq-dos для Profi.Цитата:
DOS управляет памятью с помощью блоков MCB (Memory Control Block). Память разбивается на блоки; каждому блоку предшествует MCB, в котором записаны характеристики блока памяти. Для каждой вновь запускаемой программы DOS создает определенное количество блоков MCB. При освобождении памяти или при выполнении запросов на получение дополнительной памяти DOS также использует блоки MCB, проверяя при этом правильность их содержимого.
причём тут константы? я разве про это говорил? почитай мануал на издос. много ли ты там поймёшь? особенно когда "номера" функций гуляют по разным "модулям" и уровням. глаза сразу кровоточат, а в голове возникает каша.Цитата:
Никакой программист не станет писать константы числами.
а что если мне плевать на многозадачную ОС и у меня простая ДОС?Цитата:
Многозадачные ОС по-другому не работают.
я не являюсь поклонником сабжа и меня самого жутко бесит вкаряченный fatfs. он медленный и не поворотливый и сожрал там почти 16кб памяти (байт 500 примерно осталось свободно).Цитата:
но при этом использовать готовые библиотеки той же FAT, которые едят в 1000 раз больше времени
и вот теперь давай считать:
ты предлагаешь всё свалить в одну кучу. как разделять вызовы между bdos (а он 100% должен быть, т.к. отвечает за работу с файлами, каталогами, парсинг строк, переменные окружения, бла бла, много чего там сидит (не конкретно в сабже, я вообще)) и, скажем, логическими драйверами? пишу я fdisk с форматилкой. мне надо делать разбор переданных аргументов (функционал bdos), мне надо прочитать 0й сектор с винта (bios), мне надо делать вывод на экран, мне надо делать ещё 512 разных манипуляций. при этом имей в виду, что вывод на экран тут будет самым прожорливым, т.к. местами придётся буквально побайтно делать вывод некоторых элементов. и вот есть две системы - твоя и ещё какая-то. но в твоей сисстеме ты не стал заморачиваться на производительности и всё свалил в кучу. а в другой наоборот автор озаботился об 1% оптимизации. как думаешь, где будет приятнее работать, в твоей оси или где то ещё? ответ очевиден.
в сабже та же проблемма - рестартов много, но они используются глупо, не рационально. когда начинаешь читать файло с каким-то разбором, парсингом, то приходится часто обращаться к системе за очередной порцией данных. и как всё это будет тупить, когда А - у тебя fatfs, Б - у тебя ничего не оптимизированно, длинные вызова которые не умеют различать куда идёт вызов (точнее умеют, но делают это дольше, чем если бы были на отдельном рестарте). кстати, ты сам там жаловался на монолитность, но сам же за неё топишь.
вот сам под такую систему и программируй, а я буду делать вывод графики на прямую, без всяких посредников в виде буфера. а переключать режим я буду через системный вызов.Цитата:
Например, предоставление экрана как фреймбуфера определённого формата.
Не знаю про нопы, а про то, что никуда от сохранения-восстановления всех регистров при переключении задач не деться - это знаю точно.Цитата:
Сообщение от NEO SPECTRUMAN
Экран спека - есть везде и он стандарт. Экран текстовый есть не везде. Графические экраны разные.Цитата:
Сообщение от NEO SPECTRUMAN
Поэтому экран спека - всегда есть. Остальные экраны - на уровне фреймбуффера. Ты запросил одно, но выдать тебе могут и не то, что ты запросил. Но это уж уровень драйвера экрана.
Сохранение-восстановление экранов тоже вещь от которой никуда не деться.
И это всё проблемы куда более серьёзные и интересные, чем потратил ты 100 или 200 тактов на вызов.
на прошлой неделе шутки ради провёл тест между тремя системами на предмет копирования файлов - Nedoos, pq-dos, Estex (Спринтер). задача довольно тривиальная. частота применения у всех разная.
файл размером в 4096 кб. сабж выполнил копирование дольше всех. более того, в процессе копирования командер не мог обновить информацию о статусе операции. там вообще с этим всё плохо.
при этом все трое находились в одинаковых условиях: 1. тест на эмуляторах, у всех одинаковые настройки "инта" (типа частота проца), файл один и тот же, файловая система fat16 везде.
Это где это? Количество рестартов никакого отношения к модульности не имеет.Цитата:
Сообщение от Sayman
Как и качество документации.
Так фреймбуффер это и есть прямой доступ к видеопамяти по сути. Просто ты должен знать какие страницы тебе система выделила. Это могут быть и не страницы реального экрана. При активизации задачи - страницы копируются на реальный экран.Цитата:
Сообщение от Sayman
задачи переключаются как раз достаточно редкоЦитата:
Сообщение от SfS
а вот системных вызовов происходит тонны
почему он есть везде?Цитата:
Сообщение от SfS
ОС как раз для разных машин
и экран спека есть только на спеке
те экраны еще больше чем экран спектрумаЦитата:
Сообщение от SfS
и с ними даже если работать на прямую тежяло не ползать
про серьезность и интересность написания адаптера на случай если такого нет в железе
я написал выше
это для каждого существующего поддерживаемого видеорежима нужен конвертер видео буфера каждого существующего видеорежима
и ОСь должна тянуть тонну драйверов для подобного (не обязательно только для экрана)
которые не то что в память
могут на дискету не влезсть...
А какая из них многозадачная?)Цитата:
Сообщение от Sayman
NedoOS сырая ещё, как ни курти. Но - работает. А значит ребята делают хорошее дело.
- - - Добавлено - - -
И внутри любого из них может щёлкнуть задача. Ну или запрещать переключение внутри вызовов. А вызовы могут быть и медленными.Цитата:
Сообщение от NEO SPECTRUMAN
Для разных Спектрум-совместимых машин. Что не маловажно.Цитата:
Сообщение от NEO SPECTRUMAN
те экраны еще больше чем экран спектрума
и с ними даже если работать на прямую тежяло не ползать
Зачем? Нет видеорежима - нет и мультиков))Цитата:
Сообщение от NEO SPECTRUMAN
И зачем чему-то на дискету непременно влазить?
та которая с окошками и панельками :)Цитата:
Сообщение от SfS
https://upload.wikimedia.org/wikiped...Symbos-cpc.png
какая может быть многозадачность
когда задачи переключаются ручками при помощи nmi?
с таким же успехом можно к любому спектурму прикрутить многозадачность
и сохранять запущенную задачу на диск
и иметь бесконечно количество "запущенных" задачь
они же "запущенны" только лежат на диске :v2_lol:
можно будет даже выключить комп а потом востановить "свернутую" задачу
это будет многозадачностью?
- - - Добавлено - - -
а если убрать зачемЦитата:
Сообщение от SfS
и получается "ОС для спектрума"
по факту "ОС для АТМ"
по факту "не ОС" а запускалка тк какая нахрен ОС когда она только на АТМ?
Так насколько я понимаю, в NedoOS задачи по кругу переключаются по INTу.Цитата:
Сообщение от NEO SPECTRUMAN
то я немножко не туда :v2_dizzy_tired2:Цитата:
Сообщение от SfS
то не нативные трдосные процессы только через нми...
многозадачная там как раз недоось. ну как понять многозадачная - переключать процессы толком ты всё ровно не могешь, но зато есть утилита proc, она покажет тебе все процессы.Цитата:
Сообщение от SfS
на этом многозадачность закончилась и началась обычная дос. и как сказал Нео, большая часть вызовов системы происходит в текущем процессе, а остальные висят фоном (без фокуса скорей всего даже в консоль не отправят символ).Цитата:
переключение визуальных задач (то есть тех, которые вызывали CMD_SETGFX)
она не просто сырая, она всё ещё на стадии альфа (т.е. активная стадия разработки и проработки), но при этом её уже кинули в паблик с намёком - давайте, кодьте все под неё, она уже готова. но если учесть, что от билда к билду в системе "что-то" меняется так, что старый софт перестаёт там работать, то в паблике такой системе делать ещё пока не чего.Цитата:
как ни курти.
- - - Добавлено - - -
именно так. только не совсем по инту. кодер должен сам отдавать системе квант времени через вызов yeld. т.е. как говорит алоний, делать ei:halt в недооси возбраняется всячески. только ei:yeld. не сделаешь елд. получишьш пачку глюков и тормозов (вплоть до зависания, что уже было в одной из сборок в их wizcfg).Цитата:
Сообщение от NEO SPECTRUMAN
- - - Добавлено - - -
даже там вызовы не через одну дырку реализованы.Цитата:
Сообщение от NEO SPECTRUMAN
ну а как по другому когда нет хврдварного таймера с прерываниями?Цитата:
Сообщение от Sayman
а 50Гц сильно медленно
Так все известные ОС с вытесняющей многозадачностью имеют аналог Yeld(). Не нужно время задаче - отдай другой.Цитата:
Сообщение от NEO SPECTRUMAN
В Linux таймер 100Гц. Всего в 2 раза быстрее)
только не ясно а как это должно привести к глюкам?Цитата:
Сообщение от Sayman
это та же ситуация что и когда запущенный процесс не успел выполнить все за фрейм
и обработчик прерываний приостанавливает оно и переключает на другую задачу если она есть
ни к чему другому кроме как просеранию тактов это не должно приводить
- - - Добавлено - - -
не ну если система сама все время опрашивает клаву, мышоЦитата:
Сообщение от SfS
и посылает факт события программе то можот и до
а вот если опрос инициализируется самой программой то это уже тормоза и инертность...
тк 50Гц УЖЕ маловато
а если еще и будут пропуски...
в придачу все это еще накладывается на инертность эмулятора...
а потом в долбанных менюшках хрен попадешь по нужному пункту...
вопрос не о том. что аппаратные прерывания, а о том, что условие является обязательным, а не рекомендуемым. если почитать описание на тот же Симбос, то там это указано в контексте рекомендации.Цитата:
Сообщение от NEO SPECTRUMAN
обязательным то обязательнымЦитата:
Сообщение от Sayman
не есно как его не выполнение может вызвать что либо еще кроме тормозов