Forth в OpenComputers

[NEO 541]

25 минут назад, Xytabich сказал:

@NEO кто-то ведь разработал tic, 65el02, опенкомпы, компкрафт и т.п. Если человеку интересно - сделает любое извращение)

Можно и вселенную создать, но какие будут трудозатраты и реально ли вообще создать за человеческую жизнь её?

[Xytabich 257]

@NEO всё зависит от планируемых масштабов и законов этой вселенной)

[Doob Автор темы 2 748]

Если бы все так уныло размышляли, как товарищ NEO, не было бы ни NES эмуляторов, ни JVM с майнкрафтом.

Вообще, вряд-ли что-то бы было. Сидели б на жердочках и хлебали пиво лаптями.

[NEO 541]

20 часов назад, Doob сказал:

.....

Уныло или не уныло, Болтовня ничего не стоит. Покажите мне код. Ради интереса можно закодить интерпретатор, как сказал @eu_tomat

 

P.S тем более странный он.

[Doob Автор темы 2 748]

В процессе. Скоро будет на что посмотреть.

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

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

 

Как будет основной функционал, можно будет думать над интерфейсами к устройствам. Прокинуть древовидное API через память или имитацию прерываний - тот еще квест.

[Zer0Galaxy 2 187]

14 часа назад, Doob сказал:

...

Так это будет нашлепка на OpenOS или самостоятельная Forth-система, стартующая из Eeprom?

[Doob Автор темы 2 748]

Самостоятельная система. Можно было бы сделать, чтобы она грузилась Lua BIOS, как обычная ось.

Если уместить ядро на EEPROM, то там будет только базовый функционал, клавиатура и дисплей. Дополнительные блоки слов, текстовый редактор и драйвера надо будет поставлять отдельно.

[NEO 541]

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

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

[Zer0Galaxy 2 187]

@NEO порог вхождения не больше чем в Луа. Всё дело, с какой стороны входить. Да, согласен, слов порядок странный довольно. Но всё это дело привычки.

Для программирования на Форте разбираться с памятью и регистрами совсем не обязательно. Стек нужен, но что с ним разбираться. Стек он и в Африке стек.

Эх, где мои семнадцать лет? Свой первый компилятор я написал на бэйсике. Было это что-то фортоподобное, хотя о Форте я тогда и слыхом не слыхивал.

[NEO 541]

5 часов назад, Zer0Galaxy сказал:

Эх, где мои семнадцать лет? Свой первый компилятор я написал на бэйсике. Было это что-то фортоподобное, хотя о Форте я тогда и слыхом не слыхивал.

[Doob Автор темы 2 748]

С реализацией беда, прям кошмар-ужас-ужас.

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

 

Сначала пытался все реализовать как деды завещали, но при помощи Lua. Споткнулся на оптимизации. FORTH по идее работает настолько близко к железу, что для него даже ассемблер не нужен, достаточно написать транслятор, а остальное делается самим Фортом (сверху приправляется ассемблерным языком, написанным на Форте, но это по желанию).

Lua в качестве ассемблера не годится, слишком высокоуровневый. Есть фортоподобные поделия, реализованные на языках высокого уровня, но для знакомого с традиционными реализациями, они работают крайне странно и необычно. По факту там только игры со стеком.

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

 

В связи с этим, я начал делать прослойку между Lua и FORTH в виде процессора виртуальной машины. Немного увлекшись реализовал эмулятор DCPU-16. Но для DCPU-16 уже есть FORTH, да и прослойка получается слишком жирная.

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

 

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

 

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

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

 

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

 

Но это еще не все. Понимание недостаточной оптимальности и избыточности заставляет создать еще один вариант, более быстрый и эффективный. Это будет компиляция интересных идей наследников Форта при высокоуровневой реализации, вроде Cat или Joy. Заодно выкинуть весь легаси-мусор, который даже в стандарты засунули.

Получается два Форта:

1.  Традиционный, совместимый, на виртуальном процессоре J1.
2.  Мунспик. Быстрый, удобный, максимально приближенный к реалиям опенкомпов. Совсем не похожий на древний Форт83.

[Doob Автор темы 2 748]

Было бы интересно сократить вызов методов компонентов, а то они слишком много места занимают.

Недавно возникла идея сделать своеобразный конвейер байткода, правда пока кроме вызовов функций ничего не придумал. Зато алгоритм хеширования вроде-бы годный.

 

Вот общая идея:

Есть один токен для записи аргументов и один для вызова.

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

 

А вот алгоритм хеширования:

Берется длина строки, отсекается до 4 бита.

Четные байты сдвигаются на 2 бита влево, нечетные на 7, и ксорятся в фиксированную 10 битную последовательность.

Первый бит последнего символа сдвигается на оставшийся свободный и все это объединяется. Получается хеш на 15 бит.

x = 0
for i = 1, #str do
  b = str:sub(i, i):byte() & 63
  if i % 2 == 0 then
    x = x ~ b << 2
  else
    x = x ~ b << 7
  end
end
result = (#str & 15) | x | ((str:sub(-1, -1):byte() & 1) << 14)

Наверно, можно было это сделать как-то умней, но лень анализировать статистику распределения битов в названиях. Проверил на названиях основных компонентов и их методов, коллизий не обнаружил.

[hohserg 195]

Чем больше битов в хэше, тем меньше вероятность коллизии.

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

[prop 19]

Под ОС сделали 6502-архитектуру, если интересно.

Github

Изменено 31 июля, 2021 пользователем prop

[Doob Автор темы 2 748]

Да, рабочая штука. Еще MIPS и DCPU-16 попадались, но один удалили, другой не собирается.