Кодерам - Многозадачность. Теория.

МНОГОЗАДАЧНОСТЬ. НЕМНОГО ТЕОРИИ

(C) Денис Токарчук

Небольшое вступление

Сколько я ни просил глубокоуважаемого гражданина Killeram'а побыстрее написать статейку с его идеями о реализации многозадачности на Спектруме — все безрезультатно. Сегодня уже 19-е число, время 22:54, а Убийцы Памяти все нет и, к сожалению, не будет. Ну что ж, Коля, сам напросился — читай теперь мою статью со взглядами, которые, как ты сам знаешь, тебе не очень по душе :))).

Да, читатели, дело в том, что у меня более традиционный взгляд на реализацию малореализуемого (!), а у Коляна на этот счет более экзотичное мышление. Один-ноль в мою пользу. Killeram, сравняешь счет?..

Собственно теория...

Не знаю почему, но о такой вещи, как многозадачность, в спектрумовских СМИ предпочитали как-то умалчивать. Оно и не мудрено — более-менее нормальной работы сего, так скажем, удобства при мощностях Спектрума добиться трудно. Это хорошо, если есть 7 мегагерц, кэш и ОЗУ хотя бы 512 килобайт — здесь еще можно чего-то добиться, но, к превеликому сожалению, у нас до сих пор большинство сидит на 128-х Пентагонах с 3.5 мегагерцами, музыкалкой, ну может быть еще и ковоксом.

Но даже при наличии гиперпродвинутого Спектрума с 4-мя метрами ОЗУ, с самой быстрой доработкой турбо и с кэшем на 128 кило, мы стыкаемся с еще большей проблемой — программное обеспечение, а точнее ОС, которая смогла бы обеспечить работу многозадачности... Но это потом, а сейчас рассмотрим варианты "многозадачностей", которые бы смогли воплотиться на Спекки.

"Непараллельная" (кооперативная) многозадачность

Итак, представьте себе кучку программ, к которым можно быстро обращаться через какое-то меню, переносить блоки данных из одной программы в другую, при этом без возникновения конфликтов стандартов. Вот это и есть непараллельная многозадачность — на мой скромный взгляд, наиболее вероятная в реализации на нашем Спекки, но с условием, что память хоть немного расширена.

Кроме того, необходимо писать "переместимые" программы, а здесь не обойтись без языка высокого уровня, так как на ассемблере написать релоцируемую большую программу затруднительно (программа как минимум удесятиряется в сложности). Хотя есть и другой выход — так как прога все равно пассивна при работе другой, можно их "обменивать" между активной и пассивной памятью (буферами) во время активизации той или иной; однако при таком раскладе необходима высокая скорость обмена данными (вот здесь и пригодится кэш, где, как известно, 7 мегагерц (в турбе) полноценны).

"Параллельная" многозадачность

А тут представьте себе такую картину — форматируется дискета, при этом играет музычка, печатает принтер, на мониторе в большом окошке идет мультик, в памяти рассчитывается синус для новой демки (а также выводится формула абсолютного топлива :))) ), при этом вы в маленьком окошечке, чуть ниже окна мультика, что-то программируете в Аластме. И все это одновременно и без тормозов!

Для Спектрума картина абсолютно нереальная (что пытается опровергнуть Killeram). В принципе, как и для того же писюка. Для реализации такого чудесного многозадачного режима необходима как минимум мультипроцессорность. Без аппаратной "поддержки", реализовывая все лишь на программном уровне, выходят уродцы типа Windows, где представлена лишь жалкая и страшная пародия на многозадачность.

"Смешанная" многозадачность

А это некоторый компромисс. Мне это видится следующим образом: пишутся два вида программ (естественно, под специальную ОС) — одни "быстрые", не требующие больших затрат по времени и вмещающиеся в одно прерывание (опрос клавы (само собой), всяческие другие драйвера манипуляторов, AY-музыка, вывод стрелочки, что-то на экране и т.д.). Основная особенность этих программ, назовем их программами первого вида — это то, что они выполняются все время, вне зависимости от того, что вы делаете (можно их назвать еще "фоновыми" программами).

Программы второго вида — это громоздкие программы, написанные для выполнения какой-либо большой и сложной задачи, но которые в любое время можно прекратить (как раз при помощи "фоновой" программы, которая, сидя в прерывании, может несложными манипуляциями быстро перехватить управление).

Плюсы такой реализации многозадачности налицо — мы получаем массу удобств: быстрый переход на любую из активизированных (инсталлированных) программ второго вида (основных), возможность включать в состав "фоновых" программ собственноручно написанные (например, вывод на экране времени, вращение логотипа фирмы и др.).

Однако есть и минусы. Самый основной, на мой взгляд — это появление высокой зависимости программ от ОС, что, как известно, не было особо присуще Спектруму — ведь наши программисты гонятся за скоростью и у них нет в привычках зависеть от ОС, что немудрено при низких тактовых характеристиках Z80, а написанные ОС'овские процедуры не могут похвастаться высокими скоростями... Но если писать ОС взвешенно и вдумчиво, то вполне можно обойти и эти "острые углы"...

Я (DWT) беру за точку отправления в поисках компромиссов именно последний вид многозадачности. Поговорим теперь об ОС.

Ее, естественно, придется написать новую. Лучше, чтобы она (или ее часть) была зашита в ПЗУ. Старую же ОС и ДОС (BASIC48 + TR-DOS) придется оставить, а BASIC128 заменить на новую систему. Да что я об этом пишу — уже написано с десяток прошивок в BASIC128 (GLUK, PEOS и т.д.), и программы почти никогда не ощущают отсутствия 128-го Бейсика, что и нам на руку.

Новая ОС (многозадачная ОС — далее будем сокращенно называть ее МОС) должна быть гибкой, небольшой по объему и с максимумом возможностей. Очень хорошо, если будет Setup — либо выносной (на внешнем накопителе — диске), либо зашитый в ПЗУ (тогда производитель должен под каждого конкретного пользователя подгонять Setup, где будут обозначаться "неопознаваемые" устройства — Covox, SoundDrive и, возможно, память).

Если выбран второй способ, то производитель ОС получит некую гарантию "окупаемости" своего продукта, ведь сетапную информацию можно каким-то образом закодировать с номером пользователя и затем, выпуская обслуживающие программы (которые, как известно — самые необходимые), проверять эту информацию и в случае "нестыковок" посылать незарегистрированного пользователя к такой-то матери :). Естественно, это не разрешит проблемы пиратства во всеохватывающей ее супермасштабности, но хоть на какое-то время охладит пыл хакеров-рукодельников.

Гибкость МОС должна заключаться в возможности "отключения" компонентов системы, вплоть до опроса клавиатуры и обращений к диску. Это необходимо для "подгонки" системы под программы, дабы всем было удобно. Но при этом появляется опасность мощного потока вирусов, которые смогут полностью контролировать систему (они станут о-о-очень умными, ведь тогда уже не будет диктата TR-DOS'а и BASIC48).

Кроме того, как мне кажется, необходимо "вшить" в ПЗУ'шку компилятор языка — однако ни Бейсика, ни Си, ни Паскаля, а нового (у меня и на этот счет есть свои мысли), который бы был оптимален, подогнан под особенности железа (Спекки). И необязательно, чтобы этот компилятор читал целые команды (это замедляет его работу), а воспринимал специальный код (допустим, команда PRINT = #00,#00,...TEXT...,#00). А редактор такого языка (который, естественно, будет внешним) будет заниматься также компилированием, но в этот специальный код. Опять же, необходима возможность "отключения" и "замены" компонентов языка (команд) и присвоения им новых качеств. Вся эта кутерьма необходима для написания релоцируемых программ и драйверов (для многозадачности, естественно)...

(Продолжение, возможно, последует...)

Можно писать на счет МОС очень долго, но зачем, если эти идеи не реализуются, а если и появятся, то не будут востребованы? :(. В общем, если вам интересно, то можете писать в адрес редакции и выражать свои мысли по поводу новой МОС. Может, кто из программистов и заинтересуется (Killeram, ау-ау-ау!!!).