Мысли по Теме >ОС<
----------------------
(С) Владислав С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).
- - -
Other articles:
