Многозадачность
-----------------
Николай Дворник (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:
