Лесолёд

Достаточно спорное утверждение

Немного подлечил транслятор basic-в-esoteric forth.
http://totalvacuum.ru/UB/ubasic.zip
Раньше в нем были ровно те же ограничения, что и в целевой платформе (ef \ esoteric forth \): не умел компилировать 2/3/...-разрядные числа и переменные с именами c/b/h/s/x/o/g, т.к. эти имена были задействованы в библиотеке ввода-вывода. Теперь понимает и длинные числа и переменные a-z. А еще двухсимвольные операторы сравнения <= <> >= добавились в дополнение к односимвольным < = >. И операторы poke/push/pop, а также функция peek. Компилируется теперь под win, а не под dos. Но транслятор до сих пор так и весит в районе 100 строк, а в скомпилированном виде - 3 с хвостиком Kb.
Оно выглядит смешно и даже "игрушечно", но легко транслирует простые тесты или, например, калькуляторный тест с ферзями отсюда: https://www.hpmuseum.org/cgi-bin/articles.cgi?read=700 А вообще тут главное идея: трансляция с языка высокого уровня в форт-подобное представление - это просто.

А дальше еще смешнее.
Зашил интерпретатор в Форт-процессор в ПЛИС, частоту поставил 1.5MHz, тест с ферзями выполняется за 2:11. Если сравнивать с соседями по турнирной таблице отсюда https://www.hpmuseum.org/cgi-bin/articles.cgi?read=700 (рассматривал только те, которые на бейсике и для которых в этом же документе указана частота процессора), то мой подопечный смотрится вполне достойноПри этом сам бейсик скомпилирован самодельным транслятором Си, качество кода на выходе которого оставляет желать лучшего. Но главное, что текст программы в моем случае пока хранится в неизменном текстовом виде, в то время как в ретро-бейсиках для экономии места и увеличения скорости традиционно выполняется "предварительная компиляция": команды языка кодируются одним байтом, числа и адреса прыжков переводятся в двоичный вид и т.д. Т.е. сейчас каждый раз для интерпретируемого слова выполняется сравнение строк (вместо многократно более быстрого сравнения чисел), при каждом прыжке заново производится поиск метки (снова сравнение строк!) в тексте программы (вместо того, чтобы один раз при запуске вычислить адрес перехода и дальше прыгать по этому адресу), а числа каждый раз набиваются поразрядно домножением текущего значения на 10 и добавлением очередного разряда (вместо того, чтобы однократно перегнать число из текстового представления в двоичное). И боюсь даже представить, как сильно вырастет скорость, если переписать интерпретатор BASIC на Форте/ассемблере и/или реализовать предварительную компиляцию.


ссылка на изображение

ссылка на изображение

Да, указатели на функции теперь тоже работают. Проще всего транслировать в классический Форт (['] для взятия адреса и EXECUTE для вызова). Например, такой кодтранслируется ви выводитПримерно так же просто получается под мои Форт-процессоры, т.к. там этот порядок вызова подпрограмм вполне естественный и к тому же единственный: сначала кладем в стек адрес, а потом выполняем команду call. Еще сделал под x86 (с ассемблерными вставками), а для других целевых платформ пока не делал.

Так что не будет преувеличением, если скажу, что готов минималистичный транслятор Си, который с учетом исходных самоограничений (отсутствие float, битовых полей и объявлений в стиле K&R) соответствует стандарту C89. Сверх того, реализованы вещи, которые появились лишь в более поздних стандартах (inline, двоичные числа, объявление переменных в любом месте блока). Поддерживаются функции с переменным числом параметров, но в этой части допущены некоторые вольности и имеются отличия от стандартов. Да, есть несколько различий в версиях под разные целевые платформы. Так, например, continue и goto не завезли под forth32/forth64/irbis, а указатели на функции пока работают только в моих forth-процессорах, x86 и в классическом Форте. Ну и несколько косметических недоделок/шероховатостей есть, но формально первый этап успешно завершен. Так что дальше в планах причесывать код (там сейчас лютый трэш), допиливать недоделки, добивать препроцессор (на одних #include и #define далеко не уедешь) и, наверное, float. Битовые поля и старый стиль K&R ни разу не пригодились, отряд не заметил потери таких бойцов. А вот float иногда хочется. Покой нам только снится

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

Зажировка - увеличение разрядности команд процессора и количества одновременно выполняемых инструкций с целью повышения быстродействия

А в Мануле нет возможности делать call/jmp по вычисленному адресу (в стеке)? Хотя, наверное, такое можно провернуть через >r и ret

Если уж вводить термины, то такие вкусненькие


Есть, это в целом несложно.

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

Ох, чувствую, что в процессе реализации float самой сложной частью станет перевод из текстового представления в двоичное...

Собрался на досуге поковырять float и призадумался. Какой формат выбрать?
Если процессор 32-битный, то тут ничего выдумывать не надо, берем обычный 32-битный float IEEE 754. Он будет занимать одну ячейку в стеке, удобно.
А вот если транслируем из Си в 16-битный Форт или под 16-битный процессор, то тут уже могут быть варианты. Тут float может занимать либо одну ячейку в стеке, либо две. Если рассматривать 16-битный float, альтернативы такие:bfloat16 получается отрезанием 16 бит от мантиссы в обычном 32-битном float, в результате диапазон возможных значений остается примерно тем же (до 3x10^38), а вот точность падает до 2-3 десятичных знаков. Этот формат вроде в каких-то Гуглах и прочих Нвидиях используется для машинного обучения. IEEE 754 float половинной точности чуть поточнее, но покрывает числа лишь в диапазоне +/- 65504. Впрочем, может и не смертельно для 16-битных процессоров?

Ну а если все же брать 2 16-битных ячейки стека для float, то автоматически напрашивается стандартный 32-битный float IEEE 754. Вот только в самодельном 16-битном процессоре вычисления с плавающей запятой придется делать программно, а в таком случае удобнее, если мантисса и порядок будут весить по 16 бит.

Наконец, можно тупо сделать fixed point, в котором целая и дробная часть весят по 16 бит.

Есть еще аргумент в пользу двух 16-битных ячеек для float: в Си float считается более "широким" типом, чем long int, т.е. long приводится к float, если они одновременно встретились в выражении. У меня пока long - это синоним int, но в отдаленной перспективе все же планирую сделать трансляцию long в фортовские числа двойной длины. Тогда и float желательно иметь достаточно широким. Впрочем, можно оставить и одну ячейку на float, но тогда стандартный IEEE 754 half-precision 16-bit float точно не подходит, а остается либо вариант с bfloat16, либо какой-то промежуточный (достаточно на 1 бит увеличить экспоненту в float половинной точности, чтобы покрыть область возможных значений long)

Кстати, exponent можно трактовать не как 2^(exp-bias), а, например, как 10 в такой-то степени, тогда на мантиссу больше останется. Правда тут уже другие моменты начинают вылезать, но тем не менее...

Ну а вообще интересно, как реализуют float посетители форума в своих Фортах/процессорах.

По опыту работы с x86, где у сопроцессора свой аппаратный стек, он как-то и в Фортах делался отдельно. Так что как минимум 32 разряда (который single precision), ну и перевод из одного формата в другой явный. 16-разрядные архитектуры как-то уже уходят, потому что их ниша быстро схлопнулась. 8-разрядные - просто маленькие по всем параметрам (размер, цена, энергопотребление), а 32 уже привычно, и не так много места и занимает.

Отнюдь. Еще потрепыхаюсь со своими самодельными Форт-процессорами. Да и Брус-16 еще попилим

Что касается float, то начну все же с float размером в одну ячейку стека: в 32-битных будет IEEE 754, а в 16-битных - bfloat16 или что-то похожее. Так просто проще, т.к. у меня Си делается одновременно сразу под несколько платформ разной разрядности. Ну а когда задышит, подумаю над переходом на 2 ячейки там, где необходимо. Ну и да, отдельного стека под float у меня точно не будет.

Если только для уже запущенных проектов. В целом тенденция снижения доли 16-разрядных МК наметилась уже довольно давно, потому что рост размеров ядра при переходе с 16 на 32 оказался не так заметен. Вот в старых ПЛИС возможно, но Spartan-3E уже очень-очень старая вещь. Даже Spartan-6 в принципе уже можно откладывать совсем далеко. А если 32-разрядное ядро с какими-то контроллерами укладывается в 1-2 тыс. ячеек, то уже Tang Nano 4K достаточен для его размещения. Тут вопрос в том, что помнить про 64к и границы в -32768..+32767 уже как-то непривычно, и непонятно, где оно "рванет". С bfloat16 может быть та же история. Тут и double уже кое-где начинает выдавать сюрпризы, а с короткой мантиссой эффекты нормализации могут стать совсем неприятными. Так что возникает толстенький вопрос - для каких задач это сыграет?


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

Запущенных в хорошем смысле этого слова или в плохом?

Тут основной посыл не в том, что везде будет 16-битно и ущербно. А в том, что для всех платформ будет одинаково (одна ячейка стека на float) вне зависимости от разрядности. И да, где-то (для 32-битных процессоров) этого будет вполне достаточно, а для процессоров попроще (8/16 бит) будут определенные ограничения.
Еще момент, что основным клиентом этого транслятора Си будут мои Форт-процессоры, а в них традиционно всего по 16 инструкций в системе команд, т.е. резерва под отдельные команды для работы с отдельным стеком float просто нет. В том числе и поэтому отдельного стека под float не планируется.

В космическом!



Если входной язык везде Си, то это в целом интересно. Вопрос только с точки зрения ПЛИС - где там получается именно 16 бит и нет места для 32. Но опять же, в приоритете практические решения. Если где-то нужно, и при этом можно сделать с приемлемыми затратами, то почему нет. Для 16 разрядов тоже есть раскладка float на мантиссу и порядок.