|
ZX Time #12
27 мая 2003 |
|
Многозадачность ----------------- Николай Дворник (KilleRam/KCS) Общие мысли ------------- Опять я и опять про уже наверно всем надоевшую всем тему многозадачности на SPeCcy. Хочу поделиться c вами новыми наработками в этой сфере. Я рад, что хо- тя бы один человек роздeляeт со мной ee концепцию, а именно - VITAMIN из Coders Academy (прим.ред. - его письмо в конце данного раздела). А поговорить я хочу про диспетчер задач. Во-первых, эта про- грамма должна висеть на прерываниях - это однозначно. Использовать IM1 и IM2 нет смысла, так как для большинства про- грамм они просто необходимы (несмотря на то, что музыку в системе можно повесить как отдельную, фоновую задачу). K тому же если DI, то имеем полное отключение системы. Поэтому использование NMI не- избeжно как и нового таймера для них (например 0.1мсек), но об этом позже. Так же необходимо "прихрeнячиваниe" ре- гистра на #fd для его чтения, так как отслеживание в какой странице находилась программа во время прихода прерывания практически невозможно (теоретически можно, но c некоторыми ограничениями: считывание группы байт в начале работы диспетчера, а потом их поиск, переключая поочередно все страницы. Ясно, что если в какой-то странице (левой) найдена эта группа, то fatal еггог). Диспетчер ----------- Диспетчер-программа обслуживания за- дач. Ее роль - менеджер задач. На данный момент реализованы такие команды: #00, #номер включаемой# - остановка те- кущей, без ee cохронeния, переход на следующую. #01, #номер включаемой# - то же, но c сохранением. #02, #номер задачи# - повесить на фон указаную задачу. #03, #номер задачи# - остановить задачу. #04, #номер задачи# - снять задачу. #05 - снять все задачи. #06 - остановить все. Причем размер диспетчера на данный момент - 101Sбайт. Он использует две ст- раницы :-( памяти (#d1,#d2). Реализована пока кооперативная многозадачность. B одной хранятся сохраненные регистры, состояние прерываний (di, ei, im1, im2), блоками по #20 байт для каждой задачи. Во второй хранится: имена задач, какие страницы (логические). Занимает ee coxpoheue в HIMEM (пока мах-8) и флаг пассивности/активности. B этой же странице храниться таблица сво- бодных страниц памяти (#00 - свободна, #FF - занята) причем выборка такая (пока ломовcкая, делалась для теста): ld de,adress ld hl,#f000 ld c,8 page ld b,0 ро ld а,(hl) ог а inc l djnz ро ld а,l ;номер страницы ld (de),а inc de dec c jp nz,page Просто и реально:-) Кстати, тип прерываний определяется следующим образом: по адресу #0038, в кэше (для экспериментов просто forever) nponucyem программу: ld а,#ff ld (adtab),а ret а в диспетчере после сохранений ре- ructpob, стека и т.д.,просто ставим ei halt di и все :-), если im1 то в adtab - #ff, если im2 - #00. Также диспетчер использует 5 байт ос- новной памяти для резидента (в экране - #4000): in а,(#7b) jp prog Также используется адресное простран- ство #8000-#c000, как промежуточный бу- фер для перекидывания страниц, разумеет- ся, после сохранения DOWN-memory. Контроллер прерываний, таймер ------------------------------- B идеале можно повесить на комп кон- троллер прерываний NMI c полноценным та- ймeром (например, i8053), обьясню зачем. Например, один шаг задачи выполняется меньше (или больше), чем за одно преры- вание NMI (0.1мсек), что приводит к про- cтаиванию других, (торможения этой) за- дач, выход такой: перед запуском програ- ммы диспетчер обнуляет таймер, а в про- грамме (можно только системных, наивыc- ший приоритет), после исполнения одного шага в специальную таблицу записывается значение таймера, и уже в следуюший раз это значение записывается в регистр пе- риода прeрываий перед запуском програм- мы. Ясно, что программа не всегда жрет одно количество тактов, но выигрыш бу- дет. Clipboard ----------- Bce операции по пересылке данных счи- таю целесообразным выполнять через спе- циальнyю программу ядра. Что исключит те маразмы, которые описал DWT выше (не в обиду:-) При этом эта программа сохра- няeт основную память, и использует #6000-#c000 как буфер. Ясно, что clip- board - лишь буфер обмена между задачами данными и его быстродействие не принци- пиально. Локальный буфер должен нахо- диться в адресном поле задачи. Задачи будут иметь единую систему прeрeмeнных. Это типа все.:) - - - Комментарии к статье KilleRam'а: ---------------------------------- Денис Токарчук Начнем c того, что "прихрeнячиваниe" чего-либо на железо Спектрума не нужно. Во-первых, на это вряд ли пойдет пользо- ватель. Во-вторых, как мне кажется, вы- зовет очередную волну несовместимости, что, сами понимаете, нежелательно. Далее. Мне непонятно - для чего нужно определение страницы, которая включена в данный момент?!? По сути, это нужно не для новой системы, а для TRDOS'а. Ведь в новой ОС менеджментом памяти будут зани- матьcя стандартные процедуры, поэтому любое переключение должно быть не "гру- бым", а "через систему", то есть cанкци- онированным. Следствие - активная стра- ница будет всегда известна и содержаться в переменных ОС. О диспетчере задач. Я видел эту прог- рамму в работе и она произвела на меня хоть не шокирующее, но в общем-то, боль- шое впечатление. Работает глючновато, но задачи переключает (кооперативная много- задачность - работали "вместе" ACEO.69, TRMSHOBETA, PKUNZIP, и т.д.). Должен сказать, что 1015 байт - это величина не критичная, так как код еще сыроват и весьма неплохо должен поддаваться опти- мизации. О clipboard'e. Я не буду повторять "те маразмы" (как выразился KilleRam), которые приведены выше. Однако должен заметить, что скорость в этом аспекте ОС хоть и некритична, но здравое использо- вание ресурсов компьютера должно быть максимальным. - - - Ну и в конце сегодняшней "Темы >ОС<" я бы хотел привести отрывок довольно ин- тересного письма от Vitamin'а, каcающи- йcя ОС. V:"...Статья про операционку на спеке в ZXTime#11 заставила поразмышлять на эту тему, что вызвало несколько мыслей по этому поводу. На счет системы c двойной памятью. Достаточно сложная переделка плюс - куда девается ПЗУ? А насчет перехода на дру- гие процессоры... Сомневаюсь. Это и но- вая система команд и новая архитекту- ра..." DWT: Честно скажу - я целиком и пол- ностью согласен c Vitamin'ом. Это дово- льно сложно и реализация такой системы порождает не только "жeлeзячноe" вмeша- тельство, но и кардинальные изменения в структуре и конституции Спектрума, как машины. Мы получаем ни c чем hecobmectu- мый "ужастик"... V:"Прирyчeниe" NMI - не так уж и сложно. Это я вот к чему. Вариант много- задачноcти, где программы содержат толь- ко короткие переходы и она сто раз пере- браcываeтcя по памяти - трата процессор- ного времени..." DWT: На мой взгляд, хватит вмeшивать- ся в железную структуру Спектрума. Как мне кажется, установка новой ОС должна ограничиваться исключительно единствен- ной заменой ПЗУ, без всяких вмешательств в железо. Что касается коротких перехо- дов, то действительно - это бессмысленно да и трудоемко при реализации программ. То есть трата не только процессорного времени, но и человеко-часов. V:"...Лучше просто выделить программе свой участок памяти и пусть она там ра- ботает. Пусть последние 16к выделены под задачи, тогда предпоследние 16к могут выступать в качестве "кучи" ("heap"). То есть область для стека, разных рeзидeн- тов и т.д. Эту область можно выделять блоками по 256 байт. Я тут пытался реа- лизовать многозадачную систему - кое-что получилось. Скриншот можно посмотреть в одном из AlcoNews. Так вот, время, зат- рачиваeмоe на переключение задач при вы- тecняeмой многозадачности, не так уж и велико. По крайней мере, меньше того, что потребуется на пересылку пусть самой небольшой программы. B своей разработке я использовал планировщик на IM2. А вот если реализовать его на NMI, то можно существенно повысить надежность систе- мы - моя реализация не спасает при кри- тических ошибках..." DWT: NMI - бесперспективно. Я уже го- ворил, что железо желательно не трогать, о чем y нас c KilleRam'ом постоянные споры. Я говорю, что мы должны делать ОС под то, что уже реально существует (де- лать ПРОГРАММЫ под железо, а не наобо- рот), а не в очередной раз лезть c паяльником в и без того изуродованный компьютер. Тем более подобная переделка породит несовместимость. Касаемо распре- деления памяти - вероятно, что так, как ты сказал и будет. Только под cформyли- рованнyю тобой "кучу", как мне кажется, 1бкб многовато. V:"...Основные мысли следующие: - сделать таймер, который будет c из- вecтной периодичностью посылать сигнал NMI на процессор (идеал 0.1/1 секунда - можно время точное мерять - при 0.01 большая часть времени будет тратиться на переключение задач, хотя это всего лишь в два раза быстрее стандартных прерыва- ний); - сделать порт, который будет управ- лять работой этого таймера - отключение NMI и период работы таймера (на счет пе- риода можно подумать); - прошить новую ПЗУ вместо 128-го бейсика или сделать загрузку в кэш; - на обработчике NMI будет висеть планировщик задач..." DWT: Первые два пункта и четвертый не комментирую, так как моя точка зрения по этому поводу ясна. А вот третий пункт - это да. Более того - надо, чтобы ОС ра- ботала одинаково как из КЭШа, так и из ПЗУ. V:"- y приложения есть возможность использовать прерывания по своему жела- нию, причем лучше первого рода c прог- раммным вектором; - при прошивке системы в ПЗУ реали- зуется возможность защиты ядра от hecah- кционированного доступа со стороны злоб- ных программ; - возможен прямой доступ к портам ВГ (а может и нет - я точно не знаю, кто спец - просветите)" DWT: Прав, прав. V:"- возможна реализация двух типов вытесняющей многозадачности (нeвытecняю- щая требует особого подхода к написанию программ): выделение кванта времени _каждому_ процессу по очереди, длина ко- торого зависит от приоритета процесса; или более приоритетное приложение просто будет чаще работать..." DWT: Вытесняющая - довольно сложно. Тут KilleRam сделал простенький менеджер задач на im2, переключающий процессы, и создавая тем самым иллюзию параллeльноc- ти работы (использовал какие-то 512б-ин- трyшки, как задачи). Естественно, все ужасно тормозило. И вряд ли y такого ви- да многозадачности есть перспектива на Спектруме, если не лезть, конечно, в же- лезо. V:"...B том варианте, который я пред- лагаю, минимум аппаратной доработки - только таймер и немного логики..." DWT: Должно быть вообще отсутствие аппаратной доработки (на мой взгляд). V:"...Конечно, данный вариант нуж- дается в основательной проработке, так что любые предложения (кроме "а нах%% надо? ..", "что за бред?.." и им подоб- ных :) принимаются и тщательно обсуждаю- тся - ведь операционку сделать - не в бейсик перейти :)..." DWT: Что верно - то верно. Уже пять лет c KilleRam'ом долбимся - а реального толку, кроме как примитивные экспери- ментальные процедурки, нет никакого. V:"...Далее, необходимо определить тип системы - отдельно ядро, отдельно графическая оболочка (как в UNIX) или неразрывная связь (как в Windows). Толь- ко не надо сейчас не глядя соглашаться на первый вариант только потому, что "Виндовс - маздай!". Пeрeлопатив доста- точно много информации по данному вопро- cy, я выяснил, что y каждого метода есть свои достоинства и недостатки. Если кому интересно, могу популярно просветить - авось новые идеи подкинут:)..." DWT: Вообще, конечно, c одной сторо- ны, Unix-способ требует меньше памяти для голого ядра, но "наращивание" этого ядра нeцeнтрализованно может породить очередную волну несовместимости, да и программы, как мне кажется, будут "обвe- шаны" лишним грузом дополнительных драй- bepob, кучей подпрограммок для реализа- ции графической оболочки, и т.д. Однако тут есть выход - вместе c ОС распростра- нять набор стандартных драйверов и про- цедуры для реализации графического (или какого-либо другого) вида интерфейса. Однако это может стать причиной затраты лишних тактов и, как следствие, тормоз- нутость программ и самой ОС. Если ст- роить систему по типу Windows, то этот способ несомненно повлечет за собой бо- льшие затраты памяти, что при размещении ОС в ПЗУ нежелательно. Ведь экономия ROM вызовет изначальную тормознутость многих процедур. Выход? Скрестить два этих спо- соба! То есть, какие-то ну очень шустрые и вряд ли поддающиеся оптимизации по скорости программки-подпрограммки разме- стить в ПЗУ, а все остальное сделать "cьeмным". То есть, элементарный диало- говый режим (касаемо интерфейса) без всяких драйверов и дополнительных проце- дур - изначально, что можно будет "заме- нить" стандартными командами ОС (пропи- cанными, например, в стартовом "пакет- ном" файле (как вариант - start.run)). V:"...Наконец, нужно ориентироваться на другие языки для ОС, не только accem- блер. Можно, например С реализовать. Он наиболее приближен к асму, а статей на эту тему найти не проблема. Заодно ре- шить формат работы процедур..." DWT: Си - вряд ли. Лично я этот язык ненавижу и не вижу (во тавтология!:)) перспективным на Спектруме. Уж очень он "надуман" - для меня он сложнее ассемб- лера (наверное потому что я Си изучил после ассемблера z80). V:"...Как передавать параметры - в регистрах или через стек? Второй вариант более систематизирован, но на ZX, в от- личии от РС, нет такой команды как push <чиcло>, так что c передачей констант могут возникнуть проблемы в виде лишних тактов. А передача в регистрах требует держать в голове не только параметры фу- нкций, но и то, в каких регистрах они хранятся. Также при некорректной переда- че параметров через стек очень вероятны зависоны. Выход - писать макросы, кото- рые будут сами беспокоиться о порядке передачи параметров. Вот пример перехода асма к си: ;функция типа ;void print(byte xpos, byte ypos, ;byte width, byte size, char* техт) ;сначала опишем макросы macro word ;упаковка двух байт в слово dw 256*:1+:0 endm macro print ;вызов процедуры печати db #21 ;ld hl,... word :0,:1 db #01 ;ld bc,... word :2,:3 ld de,:4 push hl push bc push de call print_ ;или endm ;ld а,lib_print_func ;call sys_lib ... ;где-то в системе print_ рор hl ;адрес возврата рор de ;параметры рор bc ех (sp),hl ;куда вернемся ... ;тело процедуры ret ... ;где-то в приложении print 0,0, 100,60, техт ... техт db "Hello, world!",0 Конечно, пример очень условен, но он показывает как можно реализовать переда- чу данных через стек, не заботясь о том, что можно упустить параметр и вся систе- ма улетит в нирвану - ассемблер выдаст ошибку уже при компиляции и вам octahet- ся только ee исправить. Остается только стандартизировать порядок чтения пара- метров и формат выходных данных..." DWT: Интересный пример и пища для ра- змышлeний. Лично я задумывался оcyщecт- вить вызов системных процедур следующим образом. Например, пусть RST#10 y нас обозначает группу I/О-команд, тогда вы- зов процедуры печати ограничивается сле- дующим набором команд ассемблера: rst #10 db 0 ;0-я группа команд - ;группа подпрограмм ;печати на экран db 0 ;0-я команда - ;печать в стандартном ;диалоговом режиме ;(координата зависит ;от положения курсора) db "Hello, world!" ;текст ;сообщения db #ff ;маркер ;конца ;текста Преимущества - не портим регистры, ОС возвращает выполнение программы сразу после конца всех аргументов. Недостат- ки - довольно тормознутая система обра- ботки RST#10. Однако можно предусмотреть в системе альтернативную группу команд, передающей аргументы через регистры, что несколько ускорит процессы. Также недос- татками такой системы общения c ОС можно считать незащищенность от ошибок. V:"Вот, в принципе, и все мои мысли. Готов всесторонне сотрудничать в созда- нии операционки. Статья про интернет навигатор. Идея сама по себе интересная, а мысль о вве- дении собственного формата хранения тек- стов c использованием кодов - только вы- игрыш в скорости и во времени. Я только хочу добавить вот что. Непосредственно вставлять коды в текст пусть даже c по- мощью специальных программ, не всегда удобно. Можно реализовать следующий ва- риант: написание документов по образу и подобию HTML, т.e. со всеми тэгами и т.д., но c последующей КОМПИЛЯЦИЕЙ полу- ченного текста. Также имеет смысл реали- зовать вставку картинок и гиперссылок в виде таблиц, хранящихся отдельно. Намно- го упрощается cyшeниe текста и обработка данных элементов. Также можно реализо- вать хранение картинок в упакованном фо- рмате - я как раз пишу такой плагин к BGE. B нем используется мой метод Bit- Раск, который был специально разработан для VideoStudio. Выигрыш от такого мето- да до 50% в обьеме (плохо сжимаются только конверченые картинки, да и то смотря какие) и проигрыш около 10% по скорости..." DWT: Спасибо, Vitamin, за письмо. KilleRam от него "прибалдел" и в месте, где идет речь об интернет-навигаторе практически во всем c тобой согласился. Но эта тема, как мне кажется, еще дово- льно призрачна. Необходим "плацдарм" для т.н. "интернет-навигатора", то есть ОС, где его можно будет хорошо "uhterpupo- вать". - - - практически во всем c тобой согласился. Но эта тема, как мне кажется, еще дово- льно призрачна. Необходим "плацдарм" для т.н. "интернет-навигатора", то есть ОС, где его можно будет хорошо "uhterpupo- вать". - - - На этом позвольте закончить ceгодняш- нюю дискуссию. Ждем ваших писем c новыми идеями и предложениями. B скором времени (наверное, в следую- щем номере), я постараюсь подготовить некий "итоговый" материал, посвященный ОС, в котором будут собраны, обобщены и заново проанализированы все идеи по этой теме, когда-либо прозвучавшие на страни- цах ZXTime. Собственно, будет изложена концепция новой ОС.
Other articles:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Similar articles:
В этот день... 21 November