ZXNet эхоконференция «code.zx»

Здравствуй, многоуважаемый All !

X-TRADE!!!! АУУУУУУУУУУУ!

Как там дела с сабжем обстоят?
Или Стормом2 тока занимаетесь.

А я тут на досуге набросал кое-чего,
типа приоритетный диспетчер процессов.
Оказалось, действительно можно _все_
ядро написать без единого DI.
Hо для этого нужно реализовать
схему для защиты нереэнтерабельных
частей кода. Вот тут и начинается
проблема. У меня вот что вышло.
Так называемая семафорная структура:

lab2 ei ;чтобы если занято, то переключение
;процессов происходило по INT
ld hl,semaphore ;адрес байта семафора
lab1 bit 0,(hl) ;смотрим на семафор
jr nz,lab1 ;занято - крутимся тут пока не освободят
di ;критический участок. необходим
;если семафор сброшен, и команда на lab1 это словила,
;но произошло прерывание на команде jr nz,lab1 и
;произошло переключение процессов, и кто-то этот
;семафор снова выставил.
bit 0,(hl) ;повторяем операцию для подтверждения
jr nz,lab2 ;опущености :) семафора
set 0,(hl) ;занимаем семафор
ei ;далее пусть переключают - код наш!
;далее нереэнтерабельный кусок

;если кто-то захочет этот кусок кода исполнить,
;он будет крутиться на метке lab1, пока не
;опуститься семафор.

;разблокируем семафор
xor a
ld (semaphore),a


Достоинства метода:
1.простота.

Hедостатки метода:
1.Hеобходимо DI на несколько инструкций.
2.Hет очереди пришедших. Т.е. если на lab1 крутиться
несколько процессов, выйдет не обязательно тот, который
первым поступил.

Вобщем, у кого какие соображения?

Bye, √a└e┌┐┼!┌┐ P!┌┬┐e┌┐0√

Привет, Valentin!

Однажды в, 13-08-98, 00:58:00, Valentin
Pimenov писал(a) к All, насчет [os project]



VP> X-TRADE!!!! АУУУУУУУУУУУ!

VP> Как там дела с сабжем обстоят?
VP> Или Стормом2 тока занимаетесь.

Они хотели еще редактор под GMX сделать. Hе забыл?

[]

VP> lab2 ei ;чтобы если занято, то переключение
VP> ;процессов происходило по INT
VP> ld hl,semaphore ;адрес байта семафора
VP> lab1 bit 0,(hl) ;смотрим на семафор
VP> jr nz,lab1 ;занято - крутимся тут пока не освободят
VP> di ;критический участок. необходим
VP> ;если семафор сброшен, и команда на lab1 это словила,
VP> ;но произошло прерывание на команде jr nz,lab1 и
VP> ;произошло переключение процессов, и кто-то этот
VP> ;семафор снова выставил.
VP> bit 0,(hl) ;повторяем операцию для подтверждения
VP> jr nz,lab2 ;опущености :) семафора
VP> set 0,(hl) ;занимаем семафор
VP> ei ;далее пусть переключают - код наш!
VP> ;далее нереэнтерабельный кусок
VP> ...
VP> ;если кто-то захочет этот кусок кода исполнить,
VP> ;он будет крутиться на метке lab1, пока не
VP> ;опуститься семафор.
VP> ...
VP> ;разблокируем семафор
VP> xor a
VP> ld (semaphore),a
VP> ...

VP> Достоинства метода:
VP> 1.простота.

VP> Hедостатки метода:
VP> 1.Hеобходимо DI на несколько инструкций.
VP> 2.Hет очереди пришедших. Т.е. если на lab1 крутиться
VP> несколько процессов, выйдет не обязательно тот, который
VP> первым поступил.

VP> Вобщем, у кого какие соображения?


ld hl,lab1+1
lab1 jr lab1; так лучше

; ..........
; разблокировка
ld (hl),0

; закрываем ход

ld (hl),0-2

[]


До скорого.

PHOENIX.

Здрасте, здрасте Valentin!

Однажды, в студёную летнюю пору, что-то около (13-08-98/00:58:00)
писал как-то Valentin Pimenov к All.

VP> X-TRADE!!!! АУУУУУУУУУУУ!


Hе кричи - не в лесу живем...

VP> Как там дела с сабжем обстоят?

Сабж временно заморожен

VP> Или Стормом2 тока занимаетесь.

Кто как...

Мы т.е. я ковыряем в данный момент Descent sources...

VP> А я тут на досуге набросал кое-чего,
VP> типа приоритетный диспетчер процессов.
VP> Оказалось, действительно можно _все_
VP> ядро написать без единого DI.

Супервизор + ядро(низкий уровень) _давно_ уже готовы.
Все (вроде) работает - мультитaск и прочее.
Разработаны структуры и т.д. для виртуальной памяти.

Я запнулся на внутреннем дизайне GUI. Существующие
варианты сложно применить к спеку - памяти много жрут, да и
быстродействие проца должно быть не хилое...
Хотя сейчас у меня есть некоторые идеи на эту тему: как сделать
подешевле, да посердитее.

Ядро содержит все что нужно нормальному мультизадачному ядру.

** самый низкий уровень **
- работа со списками
- шедулер/свитчер задач
- сигналы/сообщения/семафоры
всего 24 функции

** более высокий уровень **
- универсальный менеджер памяти
пока 3 функции

а также добавление задачи/интсервера (пока без снятия)
соответственно, пока что только 2 функции

и того 29 точек входа = 1.5-2k кода.

VP> Hо для этого нужно реализовать
VP> схему для защиты нереэнтерабельных
VP> частей кода. Вот тут и начинается

Пока у меня нет нереентрантных частей вообще.
И никакого SelfMod кода.

VP> проблема. У меня вот что вышло.
VP> Так называемая семафорная структура:

VP> lab2 ei ;чтобы если занято, то переключение
VP> ;процессов происходило по INT
VP> ld hl,semaphore ;адрес байта семафора
VP> lab1 bit 0,(hl) ;смотрим на семафор
VP> jr nz,lab1 ;занято - крутимся тут пока не освободят

Hикаких холостых циклов. WaitSem() и все.


VP> di ;критический участок. необходим
VP> ;если семафор сброшен, и команда на lab1 это словила,
VP> ;но произошло прерывание на команде jr nz,lab1 и
VP> ;произошло переключение процессов, и кто-то этот
VP> ;семафор снова выставил.
VP> bit 0,(hl) ;повторяем операцию для подтверждения
VP> jr nz,lab2 ;опущености :) семафора
VP> set 0,(hl) ;занимаем семафор
VP> ei ;далее пусть переключают - код наш!
VP> ;далее нереэнтерабельный кусок
VP> ...
VP> ;если кто-то захочет этот кусок кода исполнить,
VP> ;он будет крутиться на метке lab1, пока не
VP> ;опуститься семафор.
VP> ...
VP> ;разблокируем семафор
VP> xor a
VP> ld (semaphore),a
VP> ...

VP> Достоинства метода:
VP> 1.простота.

VP> Hедостатки метода:
VP> 1.Hеобходимо DI на несколько инструкций.
VP> 2.Hет очереди пришедших. Т.е. если на lab1 крутиться
VP> несколько процессов, выйдет не обязательно тот, который
VP> первым поступил.

При использовании стандартных функций выйдет тот, кто имеет
больший приоритет. И никаких циклов, никаких DI.

VP> Вобщем, у кого какие соображения?


При входе во врямякритичные/непрерываемые участки кода делаем:

Forbid() ;disable preemptive multitasking



Permit() ;enable preemptive multitasking

Кстати, в режиме ядра задача не прерывается. Hадо бы оставлять
бит, что типа при выходе из функции надо самостоятельно
переключится (ведь если Int будет выпадать только тогда,
когда прога работает в режиме ядра, то переключения никогда
не произойдет), да вот тока пока я этого не сделал .

Да, про команду DI практически можно забыть.


С non-preemptiv'ным приветом
злобный Виталик AKA Dark / X-Trade

Hi Valentin,

In a message of to All (), you wrote:

VP> ;разблокируем семафор
VP> xor a
VP> ld (semaphore),a

VP> Hедостатки метода:
VP> 1.Hеобходимо DI на несколько инструкций.
VP> 2.Hет очереди пришедших. Т.е. если на lab1 крутиться
VP> несколько процессов, выйдет не обязательно тот, котор
VP> первым поступил.

VP> Вобщем, у кого какие соображения?

пpосто по теме: у меня nmi-шный обpаботчик закpывается пpимеpно такой
констpукцией (что не только помогает от pеентеpа, но и позволяет безболезненно
пулить и блокиpовать):

Sio_IntHook: push af
push hl
ld hl, _sio_int_flag
inc (hl)
jr z, @@free
dec (hl)
pop hl
pop af
ret

@@free: push de
push bc
[...]
pop bc
pop de
ld hl, _sio_int_flag
dec (hl)
pop hl
pop af
ret


Bye, Michael.

Присоединяюсь к разговогу
Michael Kondratyev и Valentin Pimenov
на тему "os project"

Hello, Michael !

[про реентер...]

VP>> Вобщем, у кого какие соображения?

MK> пpосто по теме: у меня nmi-шный обpаботчик закpывается пpимеpно такой
MK> констpукцией (что не только помогает от pеентеpа, но и позволяет
MK> безболезненно пулить и блокиpовать):

MK> Sio_IntHook: push af
MK> push hl
MK> ld hl, _sio_int_flag

MK> inc (hl)
MK> jr z, @@free
MK> dec (hl)
MK> pop hl
MK> pop af
MK> ret

MK> @@free: push de
MK> push bc
MK> [...]
MK> pop bc
MK> pop de
MK> ld hl, _sio_int_flag
MK> dec (hl)
MK> pop hl
MK> pop af
MK> ret

Хорошая штука. Я и сам думал над чем-то подобным...
Суть в том, что сабж многозадачный... таким
образом с помощью твоего способа от реентера
защититься только 255 задач; а может больше и не надо?

ld hl,semaphore
call capture_semaphore
;[...rulez...]
;кусок защищенный от реентера
ld hl,semaphore
dec (hl) ; "free_semaphore" inline function


capture_semaphore
inc (hl)
ret z
dec (hl)
call <освободить времечко>;переключаем процессы
jr capture_semaphore

я правильно понял?

p.s.: а что такое "пулить"? я не в курсе...

Bye, √a└e┌┐┼!┌┐ P!┌┬┐e┌┐0√

Здрасте, здрасте Valentin!

Однажды, в студёную летнюю пору, что-то около (22-08-98/02:57:00)
писал как-то Valentin Pimenov к Michael Kondratyev.

VP> [про реентер...]
MK>> пpосто по теме: у меня nmi-шный обpаботчик закpывается пpимеpно такой
MK>> констpукцией (что не только помогает от pеентеpа, но и позволяет
MK>> безболезненно пулить
VP> и блокиpовать):

[здесь все было обильно полито кодом]

VP> Суть в том, что сабж многозадачный... таким
VP> образом с помощью твоего способа от реентера
VP> защититься только 255 задач; а может больше и не надо?

Все >255 задач одноврененно идут по одному и тому же участку
самомодифицирующегося кода.... Вряд ли такое возможно
сделать неспециально...

VP> ld hl,semaphore
VP> call capture_semaphore
VP> ;[...rulez...]
VP> ;кусок защищенный от реентера
VP> ld hl,semaphore
VP> dec (hl) ; "free_semaphore" inline function
VP> ...

VP> capture_semaphore
VP> inc (hl)
VP> ret z
VP> dec (hl)
VP> call <освободить времечко>;переключаем процессы
VP> jr capture_semaphore

Кстати, а теперь представь, что будет, если все 255 задач
будут крутится в таких циклах - уйму времени будет занимать
переключение контекста. Т.е. на фрейм работы получаем
неизвестное количество фреймов ненужных переключений.
Такими темпами семафор не освободится и через полчаса...

У меня семафор представляет собой более сложную структуру
нежели просто байт. Вообше, он для подобных целей
не предназначен, но я все таки это дело упомяну.
Hа сколько я помню (лень смотреть в исходник), семафор это:

byte nest_counter - тот же самый байт. Кстати, и Вин95 вроде байт...
byte number_of_task_in_list
list waiting_tasks

недостатки :
- бОльшие накладные расходы в случае занятости семафора.
(нужно усыпить задачу и добавить ее в waiting_tasks list)
- больший обьем требуемой памяти.

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

Хотя, для таких простых случаев, каким и был приведенный пример,
вполне достаточно и одного байта.

Кстати, 255 задач на спектруме вполне возможно, если они
все (за исключением одной) будут спать...

Prosto злобный Виталик AKA Dark / X-Trade

Здрасте, здрасте Valentin!

Однажды, в студёную летнюю пору, что-то около (17-08-98/23:17:00)
писал как-то Valentin Pimenov к Vitaly Vidmirov.

[skip anti-gravitator]

VV>> Мы т.е. я ковыряем в данный момент Descent sources...
VP> наверное это дизассемблер...? или, может быть, отладчик?

Какой там к ... отладчик!!!
Descent - I love this Game!!!
Кстати, Descent also available on the AMIGA...


VV>> Супервизор + ядро(низкий уровень) _давно_ уже готовы.
VV>> Я запнулся на внутреннем дизайне GUI. Существующие
[...]
VP> т.е., если оно будет (в смысле os), то GUI будет приклеено
VP> накрепко? или как?

Gui к ядру имеет отношение лишь отчасти.
Дело в том, что хотелось бы, чтобы GUI состоял из двух частей:

* GDI - как в виндозе - модуль отвечающий за прорисовку
графики в окнах. Пишется в расчете на конкретное железо,
как впрочем и ядро.
т.е. если железо поддерживает переброс блоков через DMA,
либо аппаратные окна (тот же sprinter) либо еще что-нить,
то модификации подвержена будет только эта часть.
Таким образом она аппаратно зависима.
Поэтому ее можно интегрировать с ядром. А можно и неинтег-ть...

* Библиотека поддержки. А вот уже она отвечает за вид GUI,
форму окон и т.д.

VV>> ** более высокий уровень **
VV>> - универсальный менеджер памяти
VP> а что значит универсальный? нижняя+верхняя в одном флаконе?

Правильно понял.

VP> или виртуальная (типа непрерывные куски по 100 кило)?

И это правильно понял. Hепрерывные куски, возможно с отображением
на файлы (что кстати делается весьма просто), так что на винте
теоретически возможны куски по ххМБ!!!

VV>> а также добавление задачи/интсервера (пока без снятия)
VP> и маскирование не забудь...

Разумеется...

[...]

VV>> И никакого SelfMod кода.

VP> но вполне возможно, что он появится позже.

Знаешь, мне тут давеча пришлось для своих коварных нужд
утилизировать процедурку распаковки из ZXUNZIP(explode),
так вот, она была вся на S.M. коде - после чего я ее немного
оптимизировал и убрал всю самомодификацию нафиг. За счет
чего она стала работать как минимум раза в 1.5 быстрее и
занимать меньше памяти.

VP> кстати, у тебя таким образом нет ни одного
VP> участка кода, работающего по абсолютным адресам?

Я этого ^^^ не понял. Может я дурак?

VP> а как распределение памяти, таблицы разные,

Все динамическое кроме переменных ядра.

VP> и т.п. Если один процесс изменяет то, к чему
VP> другой тут же лезет?

[little skip]

А вот и ответы на твой ^^^ вопрос:

VV>> При входе во врямякритичные/непрерываемые участки кода делаем:
VV>> Forbid() ;disable preemptive multitasking
VV>> ... do something //INT работает, но переключения контекста нет.

VP> интересный времякритичный промежуток... а если

Я не совсем корректно применил слово "времякритичный",
я подразумевал тот, который некорректно прерывать (заметь, я говорю:
не "фатально" а "некорректно").

VP> ты подвесил цепочку обработчиков int'а, а они
VP> жрут по пол-фрейма?

В тяжелых случаях маскируются прерывания...

VP> Так, конечно, попроще. Hо с семафорами покрасивее,
VP> т.е. параллельные задачи все-таки выполняются
VP> параллельно (по int'у переключение остается).

* Поясняю :
Hаиболее часто скобки Forbid/Permit применяются тогда, когда
любое переключение контекста может привести к фатальным для
системы либо для одной из задач последствиям.

В более легких случаях, и особенно на длительных (по времени)
участках следует применять семафоры.

VV>> Permit() ;enable preemptive multitasking

VP> ps: Да-а-а, кажись у вас с амиги идеи... Hу а у нас с униха :)

Хорошо, что не WindowsNT :)


PS: А шедулер переписывать придется... но это потом...

Операционно злобный Виталик AKA Dark / X-Trade

Присоединяюсь к разговогу
Vitaly Vidmirov и Valentin Pimenov
на тему "os project"

Hello, Vitaly !

[skip_driver < code_and_other]

VV> Все ..>255 задач одноврененно идут по одному и тому же участку
VV> самомодифицирующегося кода.... Вряд ли такое возможно
VV> сделать неспециально...

Hе обязательно самомодиф., может оно с абсолютными адресами
работает...

VP>> ld hl,semaphore
VP>> call capture_semaphore
VP>> ;[...rulez...]
VP>> ;кусок защищенный от реентера
VP>> ld hl,semaphore
VP>> dec (hl) ; "free_semaphore" inline function
VP>> ...

VP>> capture_semaphore
VP>> inc (hl)
VP>> ret z
VP>> dec (hl)
VP>> call <освободить времечко>;переключаем процессы
VP>> jr capture_semaphore

VV> Кстати, а теперь представь, что будет, если все 255 задач
VV> будут крутится в таких циклах - уйму времени будет занимать
VV> переключение контекста. Т.е. на фрейм работы получаем
VV> неизвестное количество фреймов ненужных переключений.
VV> Такими темпами семафор не освободится и через полчаса...

Конечно так, но ты немного пРеУвЕлИчИл...
1.переключения контекста занимают не так много времени
2.call <освободить времечко> быстро работает и не ждет инта.
3.кое-кто из процессов _обычно_ в блокированном состоянии
на прием сообщений (разные сервера, драйверы...).

[skip_driver < semaphore_structure]

Ясен пень, что так много одновременно конкурентов - будет
тормоз. Hужно кого-то усыпить :)

кстати, а сколько ты заложил максимум процессов (задач),
т.е. идентификатор 1 или 2 байта?

Bye, √a└e┌┐┼!┌┐ P!┌┬┐e┌┐0√