Уважаемые "четвертаки"! То, что творится с ФОРТом, больше нельзя терпеть! А то, что творится в области программирования - тем более... Время динозавров типа "С++" или Винды, которая скоро достигнет в инсталляции 1 гектара, в конце концов уйдет. Их должны сменить маленькие и шустрые "млекопитающие". ФОРТ и его аналоги могут и должны породить операционную систему, которая вмещалась бы на одной дискете и при этом не уступала бы той же Винде. Java - только пробный камень, который показал неплохие перспективы. Но отдельные языки проблемы не решат, как не решил их тот же Java. Не решит их ДССП (для строго служебного пользования) и никакая другая МОДИФИКАЦИЯ языка ФОРТ. Версий ФОРТа написано, вероятно, больше, чем байт в Винде. И я грешен, написал около пол-десятка вариантов для разного рода экспериментов. А толку? Нужна новая ОСЬ. Ее можно назвать по аналогии - ФОРТОЧКИ (в пику Окнам), или круче - Fourth OS, Четвертая ОСЬ (почти как четвертое измерение, пятый элемент и т.д.). В соответствии с новыми веяниями (наверное, это от way - путь) она должна быть многозадачной, поддерживать работу в сети многопроцессорных комплексов, систем типа SQL и т.д. Итак, какие преимущества можно ожидать от новой операционной системы? КОМПАКТНОСТЬ Форт-ОС, прежде всего, - интерпретирующая система с байтовым кодом. По сравнению с 16-разрядным машинным кодом она дает 20-кратную экономию занимаемого места, под Windows32 эта величина становится более чем 40-кратной (!!!). В сочетании с использованием кэша получится еще и экономия по времени исполнения, т.к. сокращается обмен с памятью, меньше надо времени на загрузку программ и обмен с дисками. Ситуация станет еще более критической при переходе на 64-разрядные системы. Форт-ОС должна иметь нитевую многозадачность. Словари постоянно висят в ОЗУ, объем отдельных модулей и утилит может быть всего ЕДИНИЦЫ БАЙТ (экономия в сотни и тысячи раз). Запуск новых программ происходит практически мгновенно. Для сравнения - любая программа в UNIX, QNX содержит в себе килобайты библиотек, стандартных сообщений об ошибках и т.д. Вы запустите пол-сотни процессов и в ОЗУ будет болтаться пол-сотни экземпляров совершенно одинаковых кусков кода. Стек в Форт-ОС расходуется очень экономно (128/256/512 байт на каждый процесс), что позволяет запускать на машинах типа PC ХТ несколько тысяч независимых задач, а про современные можно не говорить, это - до миллиона. Словари и процессы контролируются менеджером памяти, который может выгружать содержимое блоков памяти на диск, если ими долго не пользовались, а память нужна для других нужд. Блоки памяти наращиваются только по мере надобности, а если некий кусок не занят, он отдается в общее пользование. БЕЗОПАСНОСТЬ Форт-ОС может разделять стеки данных и адресов возвратов, и отслеживать их границы, тем самым повышая безопасность и надежность работы процессов. Данные работающего процесса при выключении системы сохраняются и снова загружаются при запуске. Программе не нужно заботиться о сохранении своих текущих параметров. Какой-нибудь процесс в таком режиме может работать на протяжении многих лет, пока его не удалят или он сам не завершит работу. УНИВЕРСАЛЬНОСТЬ КОДА Многопроцессорные комплексы в Форт-ОС могут быть совместимы на уровне кодов, и даже на уровне библиотек высокого уровня, хотя бы тех же SQL. В сочетании с компактным кодом это увеличивает скорость распределенных вычислений. Отличается каждый процессор от любого другого только ядром, в котором реализоован эмулятор универсального ФОРТ-процессора. Для этого код и должен быть байтовым (хотя это и не обязательно). Для нового процессора нужна перекомпиляция только ядра, содержащего примитивы системы. Библиотеки остаются неизменными. Сохраняются все наработки программного обеспечения. Быстродействие на существующих процессорах по сравнению с чистым кодом хуже всего на 30-50%. Специализированный процессор позволил бы достичь гораздо большего. Но на самом деле, ФОРТ-программа может обгонять программу, полученную на компиляторе. Так, многие компиляторы С каждую функцию начинают с сохранения в стеке полного набора регистров, а заканчивают - их восстановление. Какая уж тут скорость... Ассемблер - это еще конкурент, но на Ассемблере уже давно никто не пишет. ИСХОДНЫЕ ТЕКСТЫ Исполняемый код Форт-ОС легко может быть декодирован. Исходные тексты не нужны. Это отличный вариант для энтузиастов freeware soft. Имена определений могут храниться отдельно от исполняемых кодов. Это сокращает размер исполняемых словарей. Обращение к именам происходит только при декомпиляции или динамическом связывании. При желании могут быть созданы исполняемые модули без имен, с ограниченным составом определений, предназначенные для узких целей, например - для всраиваемых контроллеров. ГРАФИЧЕСКОЕ ПРОГРАММИРОВАНИЕ. В отличие от того, которое используется в системах типа Visual C, Delphy, и на самом деле представляет всего лишь графический интерфейс текстового редактора, графичесое программирование в Форт-ОС может оказать существенную помощь разработчику. Его можно было бы настроить на язык релейно-контактных схем, регуляторов и т.д. Для этого необходимо дополнительно создать графические описатели определений. Модули могут представляться в виде блочков со входами и выходами, на блоке и входах-выходах можно проставлять их обозначения. Для определений таких как SWAP, DUP, DROP и некоторых других, оперирующих со стеком, достаточно рисунка. Система программирования должна отслеживать размер стека, зная число входов и выходов каждого модуля. Таким образом можно следить за содержимым стека, типами переменных. Можно создавать логические конструкции, которых нет в структурном программировании. Новое окно или меню пригодно для работы сразу после создания. Без такого программирования ФОРТ сложноват в работе, для меня, во всяком случае. Согласитесь, что тяжело помнить конфигурацию входов-выходов всех определений. А что делать, если вы перекачали чью-то библиотеку? Даже если в системе не предусматривать автоматического сравнения типов и параметров, то это легко делать "на глаз" - все нестыковки моментально "вылезут". Тип параметра может задаваться цветом и толщиной линий. В явном виде присутствуют параметры управляющих конструкций, линии и адреса передачи управления и т.д. В соседнем окне можно хранить комментарий к создаваемому определению, общий и построчный. ОБЩАЯ СТРУКТУРА СИСТЕМЫ Каждый словарь при использовании байтового кода может иметь не более 256 определений. Но каждое из определений может быть входом в другой словарь. Одним словом - такая же древовидная структура, как и в файловой системе. Словари начинаются с таблицы адресов и тела кода, где храняться в плотном виде коды всех определений словаря. В таком компактном виде словарь помещается в ОЗУ. Дополнительные описатели: имена, длины, графический образ (ярлычки), типы обработчиков, комментарии и т.д. могут храниться за пределами номера 256, т.к. для исполняемого кода они не должны быть доступны, а для доступа к ним как к файлам можно применять 2-байтный код. Таблица адресов может ограничиться 2-байтными адресами: ФОРТ - не Винда, вряд ли 256 определений займут места больше, чем 64К. Адреса могут отсчитываться от начала сегмента. ПЕРЕМЕЩЕНИЕ И ПЕРЕКОМПИЛЯЦИЯ МОДУЛЕЙ Если определение перемещается из одного словаря в другой, то его номер и адрес меняется. В этом случае используется описатель применений. По этому описателю можно изменить код в применяющем определении. Поскольку сдвиги внутри кода не отражаются на номере, то дальнейшей перекомпиляции не требуется (для следующего "этажа" определений). Такая система позволяет обойтись без характерных для компиляторов make-файлов и значительно сокращает общее время компиляции (доли секунды!), а с ним - общее время разработки любого приложения. Имеет смысл делать перенос ссылки. Например, вы делаете экспериментальный модуль. После отладки он показал лучшие свойства по сравнению с существующим. В этом случае целесообразно старое определение удалить, а его применения переслать на новый модуль. На этом мои предварительные соображения заканчиваются. Сам я, в ближайшем будущем, скорее всего, не смогу заниматься творением ОСИ, хотя - "неисповедимы пути господни". ================== БАХМЕТ Александр.