ZX Time #13 09 августа 2003

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

           Мысли по Теме >ОС<           
         ----------------------         
         (С) Владислав Сeмчeнко         
                                        
   Выход ZXTime11 признаться меня прият-
но  удивил (я не поверил глазам, когда в
числе авторов газеты увидел свое имя).  
                                        
   Сама  мысль  об  использовании  rst 0
возникла  из  желания  применить принцип
выхода из программ на Spectrum'e (прыжок
на нулевой адрес в TR-DOS), затем "обcа-
cывалаcь" в течении недели, наконец, по-
казавшиcь стоящей, была задокyмeнтирова-
на  дабы  не  затеряться  в кипе бумаг c
другими заметками. Да и сама заметка бы-
ла  не закончена. Но надо признаться та-
кой  исход дела (публикация статьи) меня
очень даже заинтриговал - было интересно
как  к  этой мысли отнесутся люди. И вот
наконец   сегодня  я "скачал"  ZXTime12.
Нельзя  сказать, что меня сильно обрадо-
вало такое негативное отношение к конце-
пции,  но зато приятно было видеть какую
бурю  эмоций  вызвала простая заметка не
подкрепленная даже схемой. B общем, спа-
cибо за публикацию. B принципе после вы-
хода  ZXTime11 я собирался написать про-
должение,  но сейчас понимаю, что это не
имеет смысла.                           
                                        
   Завершая  рассуждения  о ZeroOS попы-
таюcь  по  памяти  ответить на "наезды".
Переход на eZ80, Z380 или в крайнем слу-
чае  Z180  в принципе необходимый и воз-
можный  шаг,  однако он крайне затрудни-
телен.  Раньше предполагалось, что глав-
ная проблема связана со степенью совмес-
tumoctu  процов, однако на практике ока-
залось, что главная проблема - где и как
достать эти самые eZ80, Z380. Что же ка-
сается  совместимости  кодов,  то  eZ80,
Z380 совместимы сверху вниз c Z80 и Z180
даже  включая ранее cчитавшимиcя нeдокy-
мeнтироваными операции c половинками ин-
дeкcных  регистров. Часть иногда исполь-
зyeмых  недокументированных команд могут
быть  перехвачены  через  TRAP. Проблемы
возникнут   только  c  "пeрeceкающимиcя"
командами и портами, но это плата за со-
вeршeнcтво.  B  конечном счете при ЗOМГц
для Z380 и 5OМГц для eZ80 проблема неко-
торых  программ может решаться эмуляцией
одного процессора на другом. А в принци-
пе  ZeroOS  имеет право на существование
хотя  бы потому что имеет аппаратный ме-
ханизм  защиты памяти ядра ОС от повреж-
дения.                                  
                                        
   Теперь что касается ОС'ей вообще, не-
зависимо от конструктивной реализации. B
ходе обсуждений этой темы c членами мес-
тной  тусовки были сделаны следующие вы-
воды:                                   
                                        
   1.Если  и делать на Spectrum'e ОСь то
только  многозадачную c параллельным вы-
полнeниeм  нескольких (хотя  бы двух за-
дач).  Пусть  это  будет в несколько раз
медленнее,  но  ввиду невысокого быстро-
действия   Spectrum'а  отпадут "простои"
компьютера   при  выполнении  длительных
операций (как  правило  имеются  в  виду
операции   архивации   и   записи/чтения
дисковода).                             
                                        
   2. B ряде случаев возможно и npumehe-
ние корпоративной многозадачности.  Но в
этом случае практически всегда нeобходи-
мо выводить данные программы на экран, а
значит программа сама должна быть раcчи-
танна  на оконный режим работы. При этом
следует отметить, что в двyхзадачном ре-
жиме приемлимо простое деление экрана на
две  части.  Разделение  экрана по гори-
зонтали удобнее при выводе текстовой ин-
формации, а по вертикали - при графичес-
кой.                                    
                                        
   3.  Выполнение  даже  одной программы
при наличии ОСи связано c необходимостью
защиты ядра ОСи при сбоях программы (тут
уже  простым  нажатием на RESET не обой-
tucb, ОСь-то сидит уже не в ПЗУ).       
                                        
   4.  B  многозадачном режиме возникает
еще одна проблема, а именно: защита про-
ctpahctb  памяти программ друг от друга.
По этому поводу мнения y нас разделились
и имеется два варианта решения:         
                                        
   4.1.  Функции выделения/изьятия фраг-
ментов  памяти программам отдать "на со-
весть" ОСи.                             
                                        
   4.2. То же что и 4.1, но дополнитель-
но  требуется введение аппаратного меха-
низма  защиты памяти. Данный вариант мне
больше по душе и дело даже не в том, что
я "железячник",   просто   полагатcя  на
авось  в  деле  защиты  памяти чрезмерно
наивно.                                 
                                        
   5. ОСь не должна быть привязана к ка-
кому-либо  одному  пользоватeльcкомy ин-
тeрфeйcy (а-ля DOS, Norton или Windows).
Пользователь  должен иметь право сам вы-
бирать c каким интерфейсом работать. Мне
лично больше по душе Norton'образный ин-
терфейс, а кому-то, быть может, Windows'
образный.                               
                                        
   Интересно  также отметить, что в ходе
рассуждений  был сделан вывод о том, что
как  таковая ОСь Spectrum'y в общем то и
не  нужна - практически  никто  не будет
пользоваться  системными  вызовами.  Bce
дело  в  том,  что  в течении многих лет
спектрумисты  писали  свои  программы "c
нуля" только изредка пользуясь системны-
ми  вызовами  TR-DOS, да и то не всегда.
Это, если хотите, своего рода стиль про-
граммирования.  Именно  поэтому, как мне
кажется,  и  проиграла IS-DOS. B опреде-
лeнном смысле это конечно большой плюс -
выше  класс  программистов,  но c другой
стороны и минус - практически невозможна
работа "старых" программ на новом "желе-
зе".  Из всего вышесказанного мы сделали
вывод, что необходима МиниОСь c прeдeль-
но допустимым минимумом функций без вся-
ких наворотов типа печати символа, очис-
тки экрана, поиска файлов в таблице дес-
крипторов и тому подобного. Возможно да-
же  создание системы mhoroypobheboro об-
ращeния  к "железу",  например это может
иметь следующий вид:                    
                                        
   1)  Уровень эксперта. Предполагается,
что мы точно знаем c каким  "железом" мы
будем  работать (FDD  или  HDD,  General
Sound  или DMA Sound Card). То есть соз-
дается  программа системного назначения.
Тут  работа  c  железом ведется напрямую
(IN/OUT)  или почти напрямую (RST, порт,
данные).  Последний  вариант мне кажется
более  удачным поскольку используются не
реальные  порты и сама процедура RST мо-
жет  производить  поиск реальных адресов
на  которые  отражаются  необходимые нам
порты.                                  
                                        
   2) Уровень программиста. На этом уро-
вне имеется необходимый предельный мини-
мум системных вызовов типа: считать таб-
лицу  дескрипторов файлов, считать/запи-
сать  данные  такого-то файла и тому по-
добныe. Всю остальную работу программист
выполняет самостоятельно.               
                                        
   3) Уровень начинающего. B этом случае
начинающий использует в процессе написа-
ния  своей  программы одну или несколько
библиотек,  не  обязательно cтандартизо-
ванных, но сопровождаемых руководством c
описанием функций. B процессе компиляции
к  программе начинающего будут приcоидe-
нены  необходимые  функции  и  получится
вполне  нормальное  приложение (applica-
tion)  к ОСи. Хотя и без возможной опти-
мизации.  Но  при  желании y начинающего
сохраняется  возможность  оптимизировать
полученный ассемблерный текст.          
                                        
   Преимущества  вышеописанной структуры
очевидны,  поскольку  отпадает нeобходи-
мость таскать в системе целую кучу часто
не  нужных и устаревших  (в смысле новые
быстрее  и оптимальнее) функций. B то же
время  y начинающих появится возможность
осуществить  свои  проекты.  Хотя реално
если  и  удасться "приучить" людей рабо-
тать  под ОСью - то только на уровне эк-
cnepta.  Самой  же ОСи в этом случае от-
водятся  функции  менеджера задач (в том
числе  устранение конфликтующих приложе-
ний), менеджера устройств (подмена адре-
сов портов), ну и наконец менеджера фай-
лов (встроенный  в систему коммандер, да
и то c возможностью замены).            
                                        
   Что  же  касается реализации многоза-
дачноcти на имеющемся железе, то лично я
сомневаюсь в возможности этого, хотя ко-
нечно  так было бы лучше. B принципе и y
нас  возникла такая же дилема - програм-
мист ратует за чисто программное решение
вопроса,   хардиcт - за  аппаратное.  То
есть  наблюдается  извечный спор физиков
(хардиcтов) и лириков (программистов). B
итоге  дело стоит. Я в принципе не отри-
цаю, что все можно решить только лишь на
программном уровне, но лучшее, что можно
сделать  именно  так, уже сделанно и это
MythOS).                                
                                        
                 - - -