Forth *

Листая одну старую книжку по древнему языку программирования Форт [1], я наткнулся на такой фрагмент, в котором меня заинтересовало слово LAST1

«E pur si muove!»
Галилео Галилей.

1. Предисловие

Настоящая статья является важным шагом на пути к созданию демонстратора системы движков, взаимодействующих в потоке данных на базе встроенного интерпретатора Forth в Elixir. Интерпретатор Forth движков описан в предшествующей статье [1]. В серия статей [2, 3, 4] рассказывалось о рабочих моментах разработки демонстратора.

Данная статья описывает ручную сборку распределенной системы узлов, выполняющих единую задачу вычисления корней квадратного уравнения по предписанию графа обработки данных в потоке. Далее для краткости будем называть такой граф графом обслуживания.

Такую же постановку демонстрационной задачи вычисления корней квадратного уравнения на графе обслуживания я сделал 5 лет тому назад в статье «Анти‑Тьюринг», https://habr.com/ru/articles/593379/.

Тогда это был прообраз системы движков. Настоящей реализации демонстратора принципа обработки данных в потоке на Elixir предшествовала работа по написанию встроенного интерпретатора Forth и широкая систематизация движков, шлюзов, кнопок и тактовых генераторов в составе системы.

Перейдём сразу к делу.

1.       Преамбула

Напомню, что в серии статей на Хабре я описываю вольную реализации демонстратора системы взаимодействующих движков Forth в рамках парадигмы обработки данных в потоке. Последняя статья https://habr.com/ru/articles/1002748/ из этой серии была посвящена реализации прототипов взаимодействующих движков Forth класса тактовых генераторов.

Сегодня моя цель - обсудить две возможные схемы реализации интерпретатора, показанные на заставке.

2.       Исходная точка вопроса

Ход разработки демонстратора системы идет в стиле «два шага вперед, шаг назад». Последний шаг назад, повлекший капитальную модернизацию работающего интерпретатора Forth, был сделан на этой неделе.

Дело в том, что я обратил внимание, что в литературе принципиальные схемы так называемой REPL, мягко выражаясь, не совпадают с действительными соотношениями вещей.

Справка из Википедии: "REPL — форма организации простой интерактивной среды программирования в рамках средств интерфейса командной строки."

Я не стал копировать из Интернета иллюстрации REPL интерпретатора, а для единообразия подготовил свою, соответствующую интерпретатору Forth:

1.      Предыстория

Месяц тому назад я реализовал интерпретатор Forth на Elixir, о чем поведал на Хабре (https://habr.com/ru/articles/985894). Этот гибрид получил составное имя Forth-ibE в честь своих родителей (Forth in-build Elixir).

Следующим шагом разработки стало определение API обмена сообщениями в распределенной команде движков Forth для совместной работы.

У читателя обязательно возникнут вопросы типа зачем и почему. Поэтому сейчас необходимо описать разрешение пары исходных дилемм.

Во–первых, в [1] говорится, что

«наряду с однозадачными существуют и мультизадачные Форт-системы. Они могут работать с произвольным числом задач. Задача может быть либо терминальной, при выполнении которой вся интерактивная мощь Форта передается оператору, сидящему за терминалом, либо управляющей, которая обеспечивает управление аппаратным средством, не имеющим терминала.

Управляющая задача имеет пару стеков и небольшой набор пользовательских переменных. Так как при выполнении управляющей задачи не используется терминал, ей не требуются ни собственный словарь, ни рабочая область, ни буфер входного текста.»

Внешне, формально это похоже на мою задумку команды движков Forth, но понятно, что в [1] описаны движки, размещенные в памяти одного компьютера. В Elixir/Erlang процессы движков Forth получают в распоряжение виртуальные машины BEAM, а следовательно, и узлы.

«Узлы можно запускать как на одном хосте, так и на нескольких. После установления связи между узлами процессы одного узла могут взаимодействовать с процессами других узлов с помощью стандартного механизма обмена сообщениями.»[2]

40 лет тому назад я разработал геометрический язык и написал транслятор чертежей, но бросил разработку на произвол судьбы, так как отчетливо понимал, что по‑хорошему, чтобы транслятор «взлетел», в него нужно встроить интерпретатор простого алгоритмического языка. Честно говоря, я был не готов к этому, и было лень этим заниматься, да и в тот момент я поменял место работы. Все один к одному...

А на днях я закончил разработку интерпретатора Forth (пока без API обёртки), исполнив свой 40-летний долг, после того как мне потребовались числовые движки в узлах ориентированного графа процессов на базе GenServer OTP в Elixir.

Для развития технологии мне требовалось реализовать Forth в объеме, описанном в известном начальном учебнике [1]. Разработанный интерпретатор Forth на языке Elixir получил рабочее название Forth‑ibE, в котором суффикс произносится [айби] и составлен из двух слов: in‑built и Elixir.

На разработку ушло 5 месяцев вместе с первоочередным патентным поиском. Именно с него начались неожиданные интересные эпизоды разработки. Поэтому я решил рассказать не о технических деталях реализации, а о нечто большем: о психологическом когнитивном исследовании в ходе разработки.

Совершать невозможное и раздавать пинки здравому смыслу — в этом и состоит жизнь членов Гуррен-Дана! (C) Камина

Эта статья вступает в техническую полемику со статьей 2015 года за авторством Atakua, подходы из которой я и атакую. Atakua исследует 7 видов интерпретаторов байткода, но делает это без уважения - быстрейшей оказывается двоичная трансляция, которая, по сути, уже не интерпретатор байткода, а форма Ahead-Of-Time компилятора. Эта двоичная трансляция транслирует байткод в машинный код, представляющий собой цепочку вызовов скомпилированных сервисных процедур. Тех самых, что в интерпретаторе байткода отвечают за выполнение каждого опкода.

Но Atakua не выжал из интерпретаторов байткода всю скорость которая возможна. Так что эта статья - туториал: как написать интерпретатор байткода, который может обгонять JIT/AOT-компиляцию по скорости. Интересно? Читайте дальше!

Бенчмарк прилагается. Будет немного хардкора и ни одной сгенерированной нейросетью картинки!

Этой статьей начинаю краткий цикл о трех языках программирования, знакомство с которыми считаю очень важным для любого профессионала в программировании: Форт, Лисп и Оберон.

Сразу оговорюсь, что я не призываю на этих языках разрабатывать, нужны очень веские причины, чтобы принять такое решение. Но знакомство с ними — важная часть профессионального роста.

Но действительно ли это так? И что вообще значит «запустить»?

Ведь все так и делают)

«HAL 4000» – исполняемая программа для Windows размером ровно 4000 байт. Лучшая работа в номинации 4 kb intro фестиваля Chaos Constructions 2017, второе место в чартах портала pouet.net. «HAL 4000» попала в плейлист Best of Demoscene 2017 наряду с работами Farbrausch, Fairlight, Conspiracy, Alcatraz, Byterapers, обсуждалась на вебинаре анимационной студии, демонстрировалась на различных фестивалях.

Необычная история создания этой работы изложена ниже.

Этот обзор посвящен открытому проекту компьютера My4TH по информации от разработчика: Авторский сайт проекта:

My4TH (произносится как "мой четвертый") - это четвертый домашний компьютер без процессора после MyCPU, MyNOR и TraNOR. Автор хотел и построил максимально простой компьютер с дискретным процессором, использующим как можно меньше элементов и компонентов, под управлением операционной системы Forth.

Эта статья является частью серии «Начальная загрузка» , в которой я начинаю с 512-байтного начального источника и пытаюсь загрузить реальную систему.

Эта статья является частью серии «Начальная загрузка» , в которой я начинаю с 512-байтного начального источника и пытаюсь загрузить реальную систему.

Эта статья является частью серии «Начальная загрузка» , в которой я начинаю с 512-байтного начального источника и пытаюсь загрузить реальную систему.

Эта небольшая электронная книга предназначена для того, чтобы научить вас языку программирования под названием Forth. Форт — это язык, непохожий на большинство других. Он не функциональный и не объектно-ориентированный, в нем нет проверки типов и практически отсутствует синтаксис. Он был написан в 70-х годах, но до сих пор используется для некоторых приложений .

Зачем учить такой странный язык? Каждый новый язык программирования, который Вы изучаете, помогает Вам думать о проблемах по-новому. Форт очень прост в освоении, но он требует от Вас мыслить не так, как Вы привыкли. Это делает его идеальным языком для расширения ваших горизонтов кодирования.

Эта книга включает в себя простую реализацию Forth, которую я написал на JavaScript. Она ни в коем случае не совершенна, и ей не хватает многих функций, которые вы ожидаете от настоящей системы Forth. Это просто для того, чтобы дать вам простой способ опробовать примеры. (Если Вы эксперт по Forth, пожалуйста, поделитесь здесь и сделайте его лучше!)
...

Эта статья является частью серии «Начальная загрузка» , в которой я начинаю с 512-байтного начального источника и пытаюсь загрузить реальную систему.

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

Часть положений не имеет ссылок на литературу., в силу не полной разработанности темы. И еще потому, что это довольно общеизвестные факты, которые легко найти. А так же потому, что упор сделан на то что неизвестно широким массам общественности.

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

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

Оригинал текста Июнь 10, 2021 - 38 минут чтения

Программное обеспечение полно своих зависимостей, если смотреть достаточно глубоко. Компиляторы, написанные на языке, на котором они компилируются, - самый очевидный, но не единственный пример. Чтобы скомпилировать ядро, нам нужно работающее ядро. Линкеры, системы сборки, оболочки. Даже текстовые редакторы, если вы хотите писать код, а не просто загружать его. Как разорвать этот цикл?1 С тех пор как проблема начальной загрузки впервые привлекла мое внимание, я стал интересоваться этой уникальной областью программной инженерии. Не из страха, что кто-то попытается реализовать атаку на доверие, а просто как интересный вызов.

11 лет назад vanjos72 описал на Reddit то, что он называет мысленным экспериментом: что если бы вас заперли в комнате с IBM PC, на котором нет операционной системы? Какое минимальное количество программного обеспечения вам понадобилось бы для начала, чтобы вернуться к комфортной работе?

Так получилось, что в последнее время у меня появилось много свободного времени, поэтому я решил сделать это больше, чем просто мысленный эксперимент. Увы, мой компьютер не был оснащен переключателями на передней панели, поэтому некоторые программы должны уже присутствовать на компьютере ...

Самым минимальным вариантом может быть простая программа, которая принимает ввод с клавиатуры, а затем переходит на нее. Поскольку подпрограммы ввода с клавиатуры в BIOS реализуют escape-коды alt+numpad, вам даже не нужно писать код преобразования базы.2Более того, циклу даже не нужно условие завершения а просто пишите в буфер обратно, пока не столкнетесь с существующим кодом и не перезапишете точку перехода. Такой подход занимает всего 14 байт.

Форт и сейчас известен, главным образом, среди разработки встроенных систем, как что-то вроде необычайного высокоуровневого ассемблера, например, для микроконтроллеров - AmForth и Mecrisp. Однако, когда-то давным давно был известен в другой ипостаси - как язык программирования научных приложений.

Форт был выбран в качестве средства, с помощью которого объясняются детали программной реализации систем, основанных на знаниях, по следующим причинам: во-первых, транслятор с этого языка имеется практически на всех типах микрокомпьютеров, во-вторых, он достаточно дешевый, и, наконец, имеет много общего с языками искусственного интеллекта, в частности с Лиспом.

Таунсенд К., Фохт Д. ПРОЕКТИРОВАНИЕ И ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ЭКСПЕРТНЫХ СИСТЕМ НА ПЕРСОНАЛЬНЫХ ЭВМ. М.: Финансы и статистика, 1990.