ZX Time #12 27 мая 2003

Программирование

ОС - ОС для Спектрума: Многозадачноcть, Диcпeтчeр, Kонтроллeр прeрываний и таймeр, Сliрbоаrd.

            Многозадачность             
           -----------------            
     Николай Дворник (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.  Собственно, будет изложена
концепция новой ОС.