А теперь предлагаю посчитать, сколько такой навернутый планировщик будет "кушать" сам. Не меньше 500-1000 тактов... Расточительно.
А теперь предлагаю посчитать, сколько такой навернутый планировщик будет "кушать" сам. Не меньше 500-1000 тактов... Расточительно.
посчитай сколько кушает обычная процедура обработки прерываний. с полным сохранением регистров (как обычно и делается). плюс чето там внутри работает типа музыки. а это все 3-5 тысяч тактовСообщение от Alex/AT
Согласен, но проект то открытый - не понравится так соберёшь своё ядро, которое будет проще и быстрей (зато может более глюкавое ).Сообщение от Alex/AT
И потом, что можно на 500 тактов уместить - я не представляю, разве тока систему обработки прерывания с управлением неизменным списком потоков...
Последнее (с изменяемым списком потоков!) у меня умещено на 300-400 тактов. Так что вполне нормально.И потом, что можно на 500 тактов уместить - я не представляю, разве тока систему обработки прерывания с управлением неизменным списком потоков...
недавно чета мысля в голову стукнула как можно сделать поддержку семафоров без запрета прерываний достаточно быстрым методом.
главная задача- в один шаг изменить значение запирающей общей ячейки памяти на "занято", получив при этом предыдущее значение. на z80 для этих целей прекрасно подходит команда dec (hl) (dec(ix/iy), inc (hl/ix/iy))
вот примерный код семафора
единственная опасность, которую мне удалось рассмотреть, это если 255 процессов последовательно прервут друг друга между точками А и В. прежде чем кинуться считать такую вероятность, посчитайте вероятность простого запуска такого количества процессов %)Код:spinlock db 1 ;1-free, other-busy db 0 ;for owner ... ld ix,spinlock call lock ... ;do smth call unlock ... lock dec (ix) ;A jr z,isfree ;B inc (ix) call sleep jr lock isfree ld a,(pid) ld (ix+1),a ret unlock ld (ix),1 ret
http://3os.ru - довольно интересный проект. немного почитал, симпатишно, но одна мысля испортила все настроение. когда почитаете, поймете какая %)
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Я же даже тему создавал в "ОСЯХ". RTK называетсяСообщение от GriV
Причем достаточно легко могу адаптировать эту штуковину под количество тасков > 8, без больших потерь во времени выполнения (порядка 40 тактов на 8 тасков).P.S. Хочу отметить низкие ресурсные требования данной штуковины. На внутреннее переключение тасков уходит 156-195 тактов. На вызов RTK_TSLICE (отдача времени другим таскам) - 131 такт, на отдачу времени до следующего прерывания - вызов RTK_TIDLE - 164 такта. Итого имеем всего лишь от 287 до 359 тактов на фактическое переключение таска. Если в этот момент происходит отработка критического (синхронизированного) таска - еще 174/138 тактов, но это одноразово. На прерывание уходит тоже всего ничего - 272-296 тактов.
Последний раз редактировалось Alex/AT; 18.06.2005 в 09:24.
По-моему, можно гораздо проще, классическим способом. Проанализировал, вроде затыков быть не должно. Прошу всех проанализировать:недавно чета мысля в голову стукнула как можно сделать поддержку семафоров без запрета прерываний достаточно быстрым методом.
главная задача- в один шаг изменить значение запирающей общей ячейки памяти на "занято"
SEMAPH DB #80
LD HL,SEMAPH
SLA (HL)
JP NC,LOCKED
... do something ...
LD (HL),#80
JP ...
LOCKED ...
ну у меня тоже своего рода классический способ %) хотя у тебя изящней даже получилось %)Сообщение от Alex/AT
2Alex/AT> я знаю что ты делал тему про Real Time Kernel (или как там правильней расшифровывается), однако неясно где исходники сего продукта, потому и спросил.
И ещё, для спектрума система реального времени как таковая не очень нужна, а вот система с кооперативной многозадачностью было бы неплохо иметь...
Насчёт указанных алгоритмов, на самом деле такой подход "не канает" по следующим соображениям: если семафор простой (т.е. проверяется только 1 байт), то нет никаких проблем, такие алгоритмы будут работать, однако если семафоры усложнятся (наверняка кстати) то придётся чтото придумывать. А точнее не придумывать а брать готовое. Обычно за семафоры (работу с ними) отвечает система, так вот когда управление переходит на п/п работы с семафорами, то ни один прикладной поток не может прервать работу этой п/п (так называемая критическая секция) - кроме может быть прерывания (int). Т.о. будет решён вопрос со сложными семафорами.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)