context switcher in new OS?

[Alex/AT]

А теперь предлагаю посчитать, сколько такой навернутый планировщик будет "кушать" сам. Не меньше 500-1000 тактов... Расточительно.

[Vitamin]

А теперь предлагаю посчитать, сколько такой навернутый планировщик будет "кушать" сам. Не меньше 500-1000 тактов... Расточительно.

посчитай сколько кушает обычная процедура обработки прерываний. с полным сохранением регистров (как обычно и делается). плюс чето там внутри работает типа музыки. а это все 3-5 тысяч тактов

[GriV]

А теперь предлагаю посчитать, сколько такой навернутый планировщик будет "кушать" сам. Не меньше 500-1000 тактов... Расточительно.

Согласен, но проект то открытый - не понравится так соберёшь своё ядро, которое будет проще и быстрей (зато может более глюкавое ).

И потом, что можно на 500 тактов уместить - я не представляю, разве тока систему обработки прерывания с управлением неизменным списком потоков...

[Alex/AT]

И потом, что можно на 500 тактов уместить - я не представляю, разве тока систему обработки прерывания с управлением неизменным списком потоков...

Последнее (с изменяемым списком потоков!) у меня умещено на 300-400 тактов. Так что вполне нормально.

[GriV]

Последнее (с изменяемым списком потоков!) у меня умещено на 300-400 тактов. Так что вполне нормально.

300-400 тактов? Даёшь ядро на асме аттачем, оно должно быть не очень большим, посмотрю что можно на такое уместить...

[Vitamin]

недавно чета мысля в голову стукнула как можно сделать поддержку семафоров без запрета прерываний достаточно быстрым методом.
главная задача- в один шаг изменить значение запирающей общей ячейки памяти на "занято", получив при этом предыдущее значение. на z80 для этих целей прекрасно подходит команда dec (hl) (dec(ix/iy), inc (hl/ix/iy))

вот примерный код семафора

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

единственная опасность, которую мне удалось рассмотреть, это если 255 процессов последовательно прервут друг друга между точками А и В. прежде чем кинуться считать такую вероятность, посчитайте вероятность простого запуска такого количества процессов %)


http://3os.ru - довольно интересный проект. немного почитал, симпатишно, но одна мысля испортила все настроение. когда почитаете, поймете какая %)

[Advertiser]

[Alex/AT]

300-400 тактов? Даёшь ядро на асме аттачем, оно должно быть не очень большим, посмотрю что можно на такое уместить...

Я же даже тему создавал в "ОСЯХ". RTK называется

P.S. Хочу отметить низкие ресурсные требования данной штуковины. На внутреннее переключение тасков уходит 156-195 тактов. На вызов RTK_TSLICE (отдача времени другим таскам) - 131 такт, на отдачу времени до следующего прерывания - вызов RTK_TIDLE - 164 такта. Итого имеем всего лишь от 287 до 359 тактов на фактическое переключение таска. Если в этот момент происходит отработка критического (синхронизированного) таска - еще 174/138 тактов, но это одноразово. На прерывание уходит тоже всего ничего - 272-296 тактов.

Причем достаточно легко могу адаптировать эту штуковину под количество тасков > 8, без больших потерь во времени выполнения (порядка 40 тактов на 8 тасков).

[Alex/AT]

недавно чета мысля в голову стукнула как можно сделать поддержку семафоров без запрета прерываний достаточно быстрым методом.
главная задача- в один шаг изменить значение запирающей общей ячейки памяти на "занято"

По-моему, можно гораздо проще, классическим способом. Проанализировал, вроде затыков быть не должно. Прошу всех проанализировать:

SEMAPH DB #80

LD HL,SEMAPH
SLA (HL)
JP NC,LOCKED
... do something ...
LD (HL),#80
JP ...

LOCKED ...

[Vitamin]

По-моему, можно гораздо проще, классическим способом. Проанализировал, вроде затыков быть не должно. Прошу всех проанализировать:

ну у меня тоже своего рода классический способ %) хотя у тебя изящней даже получилось %)

[GriV]

2Alex/AT> я знаю что ты делал тему про Real Time Kernel (или как там правильней расшифровывается), однако неясно где исходники сего продукта, потому и спросил.

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

Насчёт указанных алгоритмов, на самом деле такой подход "не канает" по следующим соображениям: если семафор простой (т.е. проверяется только 1 байт), то нет никаких проблем, такие алгоритмы будут работать, однако если семафоры усложнятся (наверняка кстати) то придётся чтото придумывать. А точнее не придумывать а брать готовое. Обычно за семафоры (работу с ними) отвечает система, так вот когда управление переходит на п/п работы с семафорами, то ни один прикладной поток не может прервать работу этой п/п (так называемая критическая секция) - кроме может быть прерывания (int). Т.о. будет решён вопрос со сложными семафорами.