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√