Претендент на TRON

В рамках публикации архивных материалов предлагаем вашему вниманию статью Андрея Зубинского из №3 (221) «Компьютерного Обозрения» от 2 февраля 2000 г. И речь в этой публикации не просто о проекте TRON.

На первый взгляд, геополитическая специфика современного этапа развития компьютинга буквально вынуждает направлять взор читателя в сторону Запада. Такое положение вещей трудно назвать справедливым — ведь попытка объяснения сегодняшних производственных успехов Востока (Японии, Южной Кореи и активно развивающегося Китая) только национальными трудоспособностью и уважением к старшим, по меньшей мере, кажется вульгарной. Те отрасли промышленности, в которых уже традиционно сильны производители Востока, требуют мощной научной и инженерной поддержки, невозможной без умелого, разумного и потому эффективного использования информационных технологий.

Эта восточная информационная культура, практически незаметная в журнальных публикациях, на практике подтверждается и «реактивной» скоростью проектирования новых изделий, и высоким уровнем надежности, потребительских качеств и дизайна. В первую очередь, данное высказывание относится к Стране Восходящего Солнца. Действительно, слова «Япония» и «компьютинг» сразу вызывают ассоциации с названиями крупных корпораций, хорошо знакомых по представленной на нашем рынке продукции. Труднее припомнить, что феномен No 1 массового компьютинга — архитектура IBM PC, на японском рынке не прижилась (ее заменяет PC98), а феномен прошлого года — Linux, пользуется у японцев меньшей популярностью, чем сравнительно малоизвестная ОС NetBSD и уж совсем неизвестная у нас BTRON. Если же на секунду забыть «о главном» (о компьютинге, разумеется), важнейшей характеристикой сегодняшней Японии, с точки зрения автора, является факт более чем 90%-ного вклада очень маленьких фирм (с числом работающих 3–5 человек) в национальную экономику. Факт этот важен и как свидетельство возможности построения здорового капитализма «в отдельно взятой стране», и в контексте статьи — ведь речь пойдет не только (и не столько) о конкретной японской разработке, но и о «другой» модели развития IT.

ОТКРЫТАЯ МОДЕЛЬ ПРОТИВ ОТКРЫТОЙ МОДЕЛИ...

В последние дни перед Новым годом у сторонников и апологетов модели развития «открытого» программного обеспечения (проще говоря — ПО с доступными исходными текстами) появились новые веские доводы «за». Многие крупные компании «вдруг освободили» свои далеко не худшие разработки; одним из самых ярких событий стало появление сайта www.opencascade.org — знаменитая Matra Datavision дала в руки разработчиков бесплатного ПО мощные библиотеки для программирования крупномасштабных систем автоматизированного проектирования, снабженные хорошей документацией. Все это просто замечательно, но... на каждую бочку freeware-меда находится обязательная ложечка какого-нибудь дегтя. В случае с «освобожденным» ПО корпоративного происхождения эти самые «ложечки» вырастают до габаритов весьма вместительных черпаков.

Самый большой «черпак» — разрыв между реальными производственными возможностями массового производителя в условиях «здорового капитализма» (а ведь именно он, по большому счету, и подразумевается открытой моделью ПО) и сложившейся на сегодняшний день моделью «раздутого» ПО. Любой мало-мальски опытный программист прекрасно чувствует ту границу сложности исходного программного материала, отделяющую потенциально трудную модификацию ПО от реально невозможной. За этой границей находятся и «освобожденная» уже более полугода назад Sun JDK 2.0 (Java Development Kit), так до сих пор не портированная даже на родственные Solaris платформы, и основанный на исходных текстах Netscape броузер Mozilla, также до сих пор непригодный к реальному повседневному использованию. Попытки преодолеть этот разрыв не выходя за рамки исходно порочной «дутой» модели приводят только к тому, что вместительность «черпака» растет: направленные на упрощение разработки приложений компонентные модели и middleware на деле оказываются тяжеловесными, трудно осваиваемыми программистами и еще более ориентированными на корпоративную схему проектирования. Продуктивные идеи, заложенные К. Томпсоном и Д. Ричи в ОС Unix и Plan-9, Н. Виртом в Oberon, Ч. Муром в FORTH, сегодня не в фаворе даже во freeware-сообществе.

Второй по величине «черпак» заметить трудно несмотря на «габариты», однако он непременно «выливается» в ту же бочку, что и первый. Качество «меда», понятное дело, от этого не улучшается. Сложность исходных текстов современных программных комплексов (даже сугубо утилитарного назначения) сводит на нет все преимущества открытой модели. Это с одной стороны, и это первый упомянутый «черпак». Другая сторона медали — отсутствие во многих проектах сколь-нибудь определенной и массово-доступной модели проектирования, иначе говоря, отсутствие спецификаций и документаций ПО. Модная сегодня в «iТусовках» (например, slashdot.org) тема программирования «from scratch» (переводить дословно это идиоматическое высказывание автор не видит смысла, а означает оно широко используемый всеми плохими инженерами подход к проектированию, когда спецификации/документация создаются после появления на свет самого изделия) — лучшее подтверждение факта существования второго «черпака». Linux (отмечу, — не ОС, а ядро), развивающуюся именно по схеме «from scratch», временно спасают огромный интеллектуальный потенциал, заложенный в спецификации POSIX, и мощная общедоступная архитектурная база, сформированная историей развития ОС Unix. Хотя сегодня, когда размеры исходных текстов ядра Linux «запрыгнули» в большие десятки мегабайтов, отсутствие механизмов высокоуровневого проектирования (в первую очередь, спецификаций) проявляется и в ежедневно появляющихся «заплатках»-patches, и в том, что разработчики patches — одни и те же люди, и, наконец, постоянно растущими мегабайтами кода...

Автор надеется, что вот так, сравнительно незаметно, уже подвел читателя к пониманию двух открытых моделей ПО: с открытыми исходными текстами и открытыми спецификациями. Linux принадлежит к первой модели, Unix/POSIX, Plan-9, Oberon и FORTH — одновременно к двум (есть и великолепные спецификации систем, есть и открытые реализации). Самый яркий (по мнению автора) пример грандиозного проекта, основанного на открытых спецификациях, хорошо знаком большинству программистов, хотя реально ни на одном компьютере вы не найдете его «чистой» реализации. Речь идет о книгах Д. Кнута «Искусство программирования для ЭВМ» — в них искусство специфицирования доведено до, если так можно выразиться, изысканности.

Подводя краткий итог нашего экскурса в мир «открытого ПО», автор, не скрывая симпатии к модели «открытых спецификаций» и безо всякого желания оправдаться перед читателем за неизбежно связанную с этой симпатией субъективность, хочет напомнить знакомую многим присказку: «Хороший инженер целый год проектирует изделие, нуждающееся в минутной наладке. Плохой инженер за минуту делает изделие, налаживать которое приходится целый год...».

КОМПЬЮТЕРИЗАЦИЯ ПО-ЯПОНСКИ

Автору, к сожалению, неизвестно, какая часть от общего, почти 60-миллиардного количества встроенных (embedded) микропроцессоров (вдумайтесь в эту цифру: на каждого жителя Земли, включая австралийских аборигенов, алеутских эскимосов и пигмеев из дельты Амазонки, приходится в среднем... по 10 микропроцессоров!) находится на территории Японии. Зато представление о характере японского подхода к информационным технологиям можно сравнительно легко получить из графика «распределения информационных усилий» (рис. 1), отражающего тонкую структуру рынка встраиваемых систем этой страны.

Если читатель думает, что встраиваемые системы по-японски — это «игрушки» типа печально известных тамагочи, то здесь его ждет большое разочарование. Речь идет о серьезных программно-аппаратных комплексах, усредненные характеристики которых кратко отражает рис. 2.

Читатели, не по статьям знакомые с программированием «маленьких» встраиваемых систем даже на основе 8-битовых процессоров, прекрасно понимают, насколько сложной должна быть embedded-программа из наиболее массового диапазона размеров (от 256 KB до 1 MB), незнакомых же со спецификой «встраиваемого» мира автор может только попытаться убедить примером хорошо известных телефонных аппаратов с АОН, разработчики которых умудряются «втискивать» в десятки или даже единицы килобайт совершенно безумную функциональность (по крайней мере, всех функций своего АОН пятилетней давности автор до сих пор не знает...).

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

ИСТОРИЯ TRON

Задачу создания единой метаархитектуры (а столь необходимая современному информационно насыщенному миру «ОС всего» является решением именно такой задачи) — на первый взгляд, необъятную, и неформализуемую, до 1984 г. не ставил перед собой никто. Unix была, остается и, вероятнее всего, останется в будущем системой для программистов, пользовательские системы, сколь бы ни были они совершенны, не могут претендовать на лавровый венок «ОС всего» из-за очевидной узкой направленности (как на целевые платформы, так и на целевые аудитории). В 1984 г. ситуация изменилась (что, увы, осталось незамеченным) — в соответствии с рекомендациями Японской Ассоциации Развития Электронной Промышленности был создан «технический комитет микропроцессорных приложений», возглавленный доктором Токийского Университета Кеном Сакамурой (Ken Sakamura). Новый комитет в этом же году открыл проект под названием TRON — The Real-time Operating system Nucleus, «Ядро системы реального времени».

Итак, обычный проект с достаточно неамбициозным названием уже в 1985 г. дал первые «всходы»: в соответствии со спецификациями, получившими название ITRON/86, корпорация NEC реализовала первое ядро операционной системы, ориентированной на процессоры Intel x86. Такое «стандартное начало» сегодня кажется даже скучным — все неизбежно или начинают с архитектуры Intel, или заканчивают ею. Но, как говорится, «Восток — дело тонкое», и разработчики TRON с 1985 г. больше не вспомнят о доминировании архитектур, отдавая предпочтение доминированию здравого смысла. В 1986 г. под руководством К. Сакамуры создается «Ассоциация TRON Inc.» (TRON Kyogikai), в этом же году к реализации конкретных версий TRON «подключается» Hitachi. Уже во второй половине 1986-го популярность проекта в Японии столь высока, что проводится первый Симпозиум TRON.

1987 г. принес Ассоциации TRON новые успехи — практически одновременно Fujitsu, Mitsubishi Electric и Hitachi анонсируют новые продукты, основанные на спецификациях TRON. Hitachi стала пионером в совершенно новой области, реализовав первый микропроцессор в соответствии с открытыми спецификациями TRON.

В 1988 г. к реализации TRON-процессоров и систем подключилась Toshiba, а в конце года, на очередном симпозиуме TRON, были продемонстрированы первые продукты на основе технологии EnableWare (расширенные спецификации TRON, созданные специально для встроенных систем, ориентированных на людей, лишенных зрения, слуха и т. д.).

1989 г. был полон событиями — концерн Matsushita выпустил массовый персональный компьютер для образования с ПО, основанным на спецификациях BTRON, была опубликована «Концепция интеллектуального здания TRON» и создан концерн с аналогичным названием, Oki Electric реализовала первую операционную систему на основе спецификаций CTRON, Mitshubishi пополнила модельный ряд TRON-совместимых процессоров новым 32-битовым чипом Gmicro/100, вслед за ней семейство Gmicro расширила Fujitsu (Gmicro/300).

В 1990 г. TRON-мир праздновал и выход нового журнала «TRONWARE» (который благодаря концерну Personal Media регулярно выходит по сей день), Oki Electric продолжила совершенствование реализации CTRON, получившей новое название OKITRON-C, и выпустила 32-битовый TRON-процессор O32, Toshiba, освоив производство микропроцессоров, перешла к операционным системам (TR90), Matsushita начала продажи учебного компьютера PanaCAL ET. Впервые знакомство с TRON-продуктами стало доступным широкой публике — прошла первая выставка TRONSHOW (которая впоследствии станет ежегодной).

С 1991 г. TRON движется вперед семимильными шагами — уже в этом году поступают в продажу TRON-ноутбуки и эргономичные TRON-клавиатуры (Personal Media), через год — контроллеры сетевых TRON-интерфейсов (Yamaha), расширяется спектр TRON-совместимых процессоров (Gmicro/500 от Hitachi и TX2 — Toshiba, 1993 г.), появляется первая версия BTRON для IBM PC (Personal Media, 1994 г.), в 1996 г. рождается важнейший проект Токийского Университета «Многоязычный компьютинг» (Multilingual Computing) — новая фаза развития TRON, обеспечивающая системе высочайшую популярность в Японии, Корее и Китае, в этом же году TRON «пересекает» океан, и Sun Microsystems создает реализацию системы для своего embedded-процессора microSPARC II, Seiko выпускает знаменитый в Японии карманный компьютер TiPO (который японцы называют не PDA, а BrainPad). Дальше — больше, и появляются ориентированные на Java спецификации JTRON, а известная компания Metrowerks выпускает свой знаменитый CodeWarrior для BTRON и TiPO.

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

МНОЖЕСТВЕННОЕ ЧИСЛО TRON

Изначально руководитель проекта TRON К. Сакамура понимал, что одной единственной ОС принципиально разные потребности удовлетворить не удастся, и главные направления, разительно отличающиеся по требованиям, — промышленные, коммуникационные и коммерческие применения. Соответственно TRON на сегодняшний день представляет собой семейство спецификаций под названием ITRON (Industrial TRON), CTRON (Communications TRON) и BTRON (Business TRON). Сравнительно недавно перечень спецификаций пополнила JTRON — интеграция Java JDK и ITRON. Наиболее интересными и тщательно проработанными среди них являются ITRON и BTRON, что подтверждается фактическим доминированием ITRON-систем на японском рынке (более 30%) и высоким качеством реализаций BTRON, давно и заслуженно популярных в Японии.

ФИЛОСОФИЯ TRON

Одним из главных достижений проекта TRON можно считать даже не замечательные и свободно доступные спецификации, а, так сказать, расширение нашего восприятия ставших уже привычными компьютерных понятий. В первую очередь, это утверждение касается постоянно употребляемого термина «архитектура». Введенное в обиход Дж. М. Амдалом понятие архитектуры подразумевало спецификации аппаратных средств компьютера, ориентированные на программиста. В терминах TRON под архитектурой понимаются спецификации всех уровней — от архитектуры Амдала до операционной системы и пользовательского интерфейса, причем разработчики строго следят за соблюдением принципа единства этих спецификаций для всех указанных выше подпроектов TRON.

Фундаментальные концепции TRON — философия проекта, настолько важны, что без их краткого рассмотрения материал следующей статьи (продолжения) будет, в некотором роде, неполноценным. Четыре основополагающих принципа, которыми и сегодня руководствуются конструкторы (разработчики TRON не совсем программисты: так, Ассоциация TRON не занимается написанием программ) новых спецификаций, несмотря на глобализм оказались удачной «сверхмоделью».

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

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

Третья концепция, естественно, заключается в приспособленности всех систем, включая BTRON, к работе в режиме «реального времени». По мнению К. Сакамуры, «...сегодняшние компьютеры используются, в основном, в двух режимах — пакетной обработки и разделения времени, что для пользователя компьютера означает ожидание. По мере того как новые поколения компьютерных устройств все настойчивее внедряются в нашу жизнь и оказывают все большее влияние на окружающий мир, такое положение вещей вносит неизбежный дискомфорт. Оптимальный для людей способ общения с компьютером — когда машина ожидает человека или изменений в окружающем мире, также неизбежно подразумевает обработку в реальном времени. Кроме того, системы реального времени прекрасно соответствуют растущим требованиям таких популярных областей применения, как распределенная обработка данных и коммуникации. В связи с этим проект TRON избирает способность будущей системы к работе в реальном времени как единственно пригодную и обеспечивающую проекту высокую живучесть и перспективность...» (перевод не дословный).

Четвертая концепция — «еще раз глобализм», или достижение «тотально единой унифицированной архитектуры». Опять же, обращаясь к работам Сакамуры: «...унифицированная архитектура создается на всех уровнях — от микропроцессора до приложений. Это дает возможность замыкания обратной связи между разработчиками основанных на TRON продуктов и конструкторами TRON. Так, новые команды могут добавляться в TRON-процессоры при выявлении недостаточной производительности реализаций TRON-ОС, а новые системные вызовы вводиться в спецификации TRONОС в случае обнаружения их необходимости разработчиками приложений. Такая настройка системы на всех уровнях и на всех этапах проектирования позволяет значительно увеличить возможности прикладных программ и является наиболее важной особенностью проекта».

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

Фактически, привычные нам компьютеры медлительны, так как быстродействие метасистем на их основе определяется быстродействием самой медленной подсистемы — человека или коллектива людей. Так было задумано... Соответственно назначение «привычных» операционных систем отражает характер целевых метасистем, а их разработчики концентрируются на управлении информационными ресурсами (обычно файлами и процессами, тонкие различия в названиях ресурсов нам совершенно не важны) и защите этих ресурсов от несанкционированных действий пользователей.

Но есть еще один обширный класс компьютеров, определяемый характером метасистем, составной частью которых они являются. Речь идет также о человеко-машинных (а в некоторых случаях и чисто машинных) метасистемах, высокое быстродействие которых исключает возможности непосредственного управления ими человеком или, тем более, группой людей. В идеале подобные системы должны обнаруживать изменения в своих метасистемах и реагировать на эти изменения без задержки, даже сколь угодно малой. Такая, на первый взгляд, незначительная вариация в определении приводит к разительным отличиям в реализациях. Прежде всего, для решения задачи обнаружения изменений в метасистемах компьютеры второго класса должны быть ориентированы на использование обширного спектра устройств ввода/вывода, не имеющих ничего общего с «традиционными» клавиатурами и манипуляторами. А кроме того, стремящееся в идеале к нулю время задержки реакции сказывается на программной реализации, иногда вынуждая разработчиков вообще избегать применения операционной системы.

ИСКУССТВО СПЕЦИФИЦИРОВАНИЯ ПО-ЯПОНСКИ

Термин «спецификация», столь часто упоминаемый автором в первой части статьи, наконец будет более или менее определен. Специфицирование — обычный этап любого правильно организованного проектного процесса, в том числе и процесса проектирования программного обеспечения. Построение спецификаций — это и ремесло, и наука, и искусство. Ремесленный подход, обеспечивающий добротные результаты, обладает рядом недостатков. Нестандартность, присущая специфицированию, как и любой творческой деятельности, порождает тысячи ремесленных ухищрений, по-умному именуемых формализациями (к слову, даже совсем «нестандартная» спецификация программы все-таки лучше, чем ее полное отсутствие). Наука о спецификациях — штука сложная и далеко не во всех случаях применимая. Ну и, наконец, специфицирование как искусство — достойный предмет отдельного обсуждения, но даже упомянутый в предыдущей статье шедевр этого искусства (Д. Кнут «Искусство программирования для ЭВМ») позволяет определить ряд ремесленных приемов, обязательно необходимых для настоящего мастера.

Важнейший прием — виртуализация. Д. Кнут в полной мере использовал ее возможности, реализовав все алгоритмы для «самой виртуальной машины в мире» под названием MIX. Виртуализация позволяет добиться большей степени абстракции, что, в свою очередь, помогает сконцентрировать внимание разработчиков только на «самом главном». Опять же на примере работ Д. Кнута, целесообразные объекты виртуализации — архитектуры процессоров и языки программирования (более реальные в программном смысле слова проекты, например Unix, Oberon и Forth, также основаны на виртуализованных машинах — языков С, Oberon-2 и стековой машине Forth соответственно). Несмотря на ремесленный характер, искусная виртуализация в обширной галерее существующих программных продуктов сразу заметна наметанному глазу, даже несмотря на «плохую подсветку» пресс-релизами и отсутствие «богатой коммерческой рамы». Дело в том, что виртуализация и эффективность — противоречивые критерии, и многие «абсолютно виртуальные» архитектуры, например Java, страдают «хроническими болезнями» неэффективных реализаций. С другой стороны, «абсолютно виртуальная» Forth-машина настолько эффективно «материализуется» на основе многих реальных аппаратных средств, что превосходит по быстродействию даже «жестко привязанные» к этим аппаратным средствам низкоуровневые специализированные программные системы.

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

После такого краткого обсуждения спецификации ITRON (Industrial TRON) К. Сакамуры можно назвать «самой виртуальной реальностью». Во-первых, в отличие от Forth и Java спецификации ITRON не предусматривают виртуализации архитектуры целевого процессора. Учет всех особенностей конкретной архитектуры — дело разработчика реализации. С одной стороны, такой подход весьма привлекателен, так как позволяет добиваться высокой эффективности при одновременном сохранении высокоуровневой совместимости между различными реализациями. С другой — TRON-миру понятие «бинарная совместимость» (столь признанная в мире ПК и позволяющая распространять программное обеспечение в исполняемом, бинарном формате) чуждо. Таким образом, завоевывающая в Японии все большую популярность модель компьютинга с открытыми спецификациями косвенно приводит к росту популярности и модели ПО с открытыми исходными текстами — ведь иная форма распространения программ при такой модели невозможна, а с точки зрения пользователя, при наличии соответствующих инструментальных автоматизированных средств установки/удаления ПО, никакой разницы между бинарным представлением и исходными текстами нет. Автор признается, что эта мысль отсутствует в спецификациях и ITRON, и BTRON, но ее очевидность буквально вынудила привлечь внимание читателя; в спецификациях ITRON просто указано, что «...для встраиваемых приложений роль программ, распространяемых в бинарной форме, очень мала...».

Возвращаясь к нашему обсуждению ремесленных приемов, следует упомянуть и о подходе К. Сакамуры к функциональности спецификаций ITRON. Область применения системы (Industrial TRON) — встраиваемые управляющие вычислители, программное обеспечение которых обычно размещается на немеханических запоминающих устройствах (например, ПЗУ), что объясняется и строгими требованиями к надежности, и тяжелыми условиями эксплуатации embedded-компьютеров, и, наконец, относительно небольшими размерами управляющих программ. В связи с этим в спецификациях ITRON отсутствуют разделы, посвященные файловым системам, — разработчик реализации имеет право не использовать файловой системы вообще, а в случае необходимости — реализовать ее в соответствии со спецификациями BTRON. Зато в части взаимодействия и управления процессами/задачами спецификации ITRON более чем функциональны: они охватывают практически все известные механизмы синхронизации и эффективные методы управления отдельными задачами.

Один из самых важных аспектов спецификаций ITRON — простота освоения и реализации системы. Для достижения этого К. Сакамура использовал знаменитую «восточную хитрость», сформировав очень интересную схему построения имен системных вызовов ITRON. При детальном ознакомлении с документацией, опять же несмотря на ни разу не упоминающуюся в спецификациях «объектную ориентацию» системы, вывод напрашивается сам собой: ITRON — объектно-ориентированная ОС (это еще один удачный пример, подтверждающий тезис об абсолютном отсутствии взаимосвязи между объектно-ориентированным проектированием и ООП). В отличие от ближайшего аналога — спецификаций POSIX, ITRON определяет вызовы ядра ОС не в терминах языка программирования C (хотя они приводятся как пример реализации), а именами абстрактных подпрограмм. Каждое имя образуется в соответствии с простым правилом: наиболее общая форма представления zxxx_yyy включает сокращенное обозначение соответствующего объекта (yyy) ядра ОС, участвующего в операции xxx. Модификатор z расширяет перечень операций, исключая необходимость передачи дополнительной информации системным вызовам. Эта особенность ITRON крайне важна для достижения высокой скорости реакции системы, ведь каждый «лишний» передаваемый ядру ОС параметр требует дополнительного времени.

ОБЪЕКТЫ И ОПЕРАЦИИ ITRON

Для людей, незнакомых с внутренним устройством операционных систем, спецификации ITRON представляют собой отличный учебник, раскрывающий все «тайны» построения современной, компактной и очень удобной (с точки зрения программиста) ОС. Основные объекты — абстракции, необходимые для реализации любой (не только TRON-совместимой) системы, специфицированы очень подробно и непременно сопровождаются «описательной» информацией. Естественно, что в короткой статье невозможно охватить все детали ITRON-спецификаций (размер шести текстовых файлов которых составляет около 850 KB), но автор придерживается мнения, что «курс молодого бойца» по организации ядра современной ОС многим окажется полезным.

Итак, основные объекты ITRON. Их немного — всего двадцать, сгруппированных в три весьма условные категории: ресурсы, задачи и взаимодействия. Под ресурсами понимаются абстракции низкоуровневых элементов любого микропроцессора, необходимые для выполнения задач (на процессорном уровне — подпрограмм), к ним относятся понятия собственно процессора (cpu, здесь и далее в скобках приводятся соответствующие имена из спецификаций ITRON), памяти (mpl, mpf, blk, blf), прерываний (int).

Задачи (tsk) в терминах TRON определяют программные единицы, способные выполняться «одновременно» (естественно, что последовательный характер современных микропроцессоров не допускает действительно одновременного выполнения нескольких задач, поэтому ITRON, как и большинство существующих ОС, предусматривает имитацию одновременного выполнения нескольких задач, предоставляя каждой из них короткий отрезок времени, именуемый квантом). Соответственно программы в TRON — более высокий уровень абстракции, объединяющий логически целостную, с точки зрения программиста и пользователя, группу задач. Мультизадачность TRON, естественно, требует развитых механизмов, определяющих очередность выполнения отдельных задач на одном (или нескольких) физических процессорах. Эти механизмы, обычно именуемые «планировщиком задач» (task scheduler), в ITRON основаны на так называемых приоритетах — неотъемлемых атрибутах всех задач системы. Приоритетный алгоритм управления задачами TRON предельно прост, но его эффективность подтверждена как теоретическими исследованиями, так и опытом эксплуатации ОС реального времени: при предоставлении кванта времени task sheduler выбирает для выполнения задачу с максимальным приоритетом и выполняет ее до тех пор, пока по каким-либо соображениям или ее приоритет не уменьшится, или не увеличится приоритет какой-нибудь другой задачи. Подобное решение разительно отличается от принятого в более привычных мультизадачных ОС (иначе именуемых системами с разделением времени, TSS, Time Sharing System) — в них система стремится к достижению равномерности выделения квантов процессорного времени всем задачам. Очевидно, что алгоритм планировщика задач требует некоторой дополнительной информации о каждой задаче. В TRON эта информация называется TCB (Task Control Block — блок управления задачей) и содержит данные о ее состоянии, уровне приоритета и начальном адресе в памяти. Еще одна особенность TCB связана с так называемой необходимостью «сохранения контекста» при переключении между задачами: операционная система, выделяющая один-единственный физический процессор многим задачам, должна заботиться о сохранении «образа» (или контекста) процессора — регистров общего назначения, счетчика команд и указателя стека, чтобы обеспечить возможность продолжения выполнения приостановленной задачи. Память «контекста процессора» также входит в состав TCB и реализуется просто необходимым количеством ячеек оперативной памяти (иначе говоря — отображением программно-доступных задаче элементов архитектуры процессора на соответствующую область ОЗУ).

Взаимодействия — важнейшая абстракция, жизненно необходимая мультизадачной системе, тем более системе реального времени. «Общение» задач исключительно с помощью ядра ОС, несомненно, возможно, но такой подход может быть недопустим из-за соображений быстродействия системы. TRON предлагает разработчикам самый обширный выбор в способах взаимодействия — от привычных семафоров (sem), флагов событий (flg) и сообщений (msg) до более экзотичных механизмов рандеву (rdv) и разделяемой памяти.

В части операций TRON прекрасно согласуется с принятой в Unix идеологией «основных четырех вызовов» (open, close, read, write — открыть, закрыть, читать, писать). К чести К. Сакамуры, Unix-идеология в TRON нашла даже более «обильную почву», по крайней мере, аналогичные Unix-вызовам TRON-операции «создать/удалить» (cre/del) и «читать/писать» (get/ set) применимы практически ко всем объектам ОС. Расширение множества операций всего до шестнадцати позволило сформировать очень «функционально насыщенную» спецификацию, абсолютно достаточную для нужд практически любых приложений (в том числе и ориентированных на сетевые применения), при этом простота реализации системы позволяет некоторым шутникам утверждать, что «...начинающие программисты обязательно пишут свою версию TRON. Причем делают это в 9 лет...».

TRON НЕ ПО-ЯПОНСКИ

Когда эта статья задумывалась автором, основным вопросом, казавшимся очень трудным (и ответ на который сейчас, по ее завершении, все еще ему неочевиден), был: кому она предназначена? Действительно, с точки зрения неспециалиста, TRON кажется совершенно неинтересной системой, а факт ее существования — всего лишь сообщением о «еще одной ОС». Кроме того, автору не встречались русскоязычные публикации, посвященные проекту TRON, что само по себе свидетельствует об отсутствии интереса к японским разработкам. Но... Хотим мы того или не хотим, мир массового компьютинга сегодня находится на грани серьезных преобразований. Об этом свидетельствует и общемировая тенденция угрозы номинальному доминированию массовых ПК архитектуры IBM PC со стороны растущего с реактивной скоростью рынка популярных малогабаритных вычислительных устройств, поражающих «процессорной пестротой» (здесь царят и ARM, и MIPS, и microSPARC). В пользу этого говорит и замедление «умирания» отечественной промышленности, за которым неизбежно должен последовать пусть не бурный, но хоть какой-нибудь рост, что опять же неизбежно вызовет изменение в структуре внутреннего рынка вычислительной техники: растущая промышленность потребует большого количества встраиваемых систем. Стоимость же большинства коммерческих западных реализаций ОС реального времени — «главного товара» embedded-рынка, позволяет уверенно говорить об их бесперспективности на массовом, но «бедном» рынке. В качестве же подтверждающего факта (а не предположения) автор хочет обратить внимание читателя на наших более благополучных «собратьев по несчастью» — страны бывшего «соцлагеря». Количество компаний, специализирующихся на embedded-разработках в Чехии, Словакии и Венгрии, буквально поражает воображение, а предлагаемый ими спектр продукции собственного (!) производства включает и одноплатные индустриальные компьютеры, и ОС реального времени, и встраиваемые реализации микроWeb-технологии, и т. д.

TRON, несмотря на малую известность, представляет собой прекрасную «стартовую платформу» как для молодых и агрессивных компаний, стремящихся занять свое место на embedded-рынке (вспомните о либеральности лицензирования системы и отсутствии необходимости в отчислениях кому бы то ни было), так и для специалистов-индивидуалов и, например, просто студентов, углубленно изучающих современные информационные технологии. С другой стороны, растущая популярность BTRON в Японии подсказывает и возможный, весьма интересный путь развития национальных информационных инфраструктур, ничего общего с изоляционизмом не имеющий. Кроме того, некая присущая TRON-спецификациям «аморфность» позволяет уверенно говорить о перспективности создания на основе TRON странных, но очень интересных и простых реализацийгибридов, восполняющих недостатки уже существующих систем. В первую очередь, это относится к ОС Oberon-3, одна из самых существенных частей которой (ядро ОС), несмотря на «свободность» всей системы в целом, распространяется с существенными ограничениями (ядро Oberon-3 является основой коммерческих систем реального времени). TRON-спецификации дают в руки разработчиков новых реализаций Oberon недостающий элемент (к слову, качество которого даже выше, чем у исходной Oberon-3).

TRON В СЕТИ

Информационных ресурсов, доступных русскоязычному читателю, к сожалению, не существует (или они настолько «глубоко» спрятаны в Сети, что автор не смог их отыскать). Несколько лучше обстоит дело для знающих английский язык — на сайте можно найти и «свежие» спецификации ITRON, и образцовую реализацию системы для процессоров Motorola 680×0 на языках C и Assembler 68k под названием ItIs (к сожалению, с японскими комментариями). Лучше всех себя почувствуют те, кто знает японский, — для них «открыты» спецификации и BTRON, и сетевой TRON-подсистемы, включая TCP/IP стек, и, наконец, свободные и коммерческие реализации BTRON.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365