Gforth 1.0

Ну так у МК-хх и мощи таклй не было. А на тему просто посччитать выражение почти и ничем не отличаются. Я до сих пор считаю на чем поидется, или на мк51 или на hp50g, кто первым под руку попадется иу кого батарейка не села. Единственно что у советских калькулятооов цифры хуже видно. Ну и программировать чуть проще, у хьюлетта словарь огромеый, пока нужную функцию найдешь, так ослепнешь.

я просто оставлю это здесь ))

https://github.com/samawati/j1eforth

https://github.com/ThorKn/J1-forth

https://github.com/howerj/forth-cpu

https://github.com/pbing/J1

Ну так префиксная,, она же обратная польская запись тебе зачем? a b + c d + *

На, углубляйся :) — https://exercism.org/tracks/haskell/exercises/forth

Ну... Стек возвратов — это читерство :)

заявлена полная поддержка стандарта Forth 2012;

Учись Си++! Это С - Стабильность.

Ну вот найди где-нибудь HP-50g, на нем и будешь писать. ХПишники зачем-то Форт RPL-м обозвали.

PForth забыл — https://github.com/philburk/pforth

Оно понятно, я его запомнить не могу

Нет, не забыл. Это все проекты где есть хоть какой то смысл в применении именно форта.

Форт тупо не подходит для 64 разрядных «вообще», и для риск, амд64 и арм «в частности».

ps авр я уже не стал упоминать ))))

проекты где есть хоть какой то смысл в применении именно форта.

буквально на днях подумывал добавить в проект не то чтобы совсем уж форт, но high-level форт-подобное.

Cтековую машину для управления внутренностями агента.

Кода в любом случае меньше. Экономия на передаче аргументов ведь. Но вот скорость результата может быть не очень.

Gforth написан на Си и собирается GCC

Что же он свой бутстрап на самом себе не осилил?

Что же он свой бутстрап на самом себе не осилил?

Кроссплатформенность, переносимость и производительность.

Прикрутить (через дсл или виртуалку по сути) язык в котором не разбирается (в большинстве, пока) ни человек, ни llm в качестве конфигуратора вполне себе ход.

Зачем же так сложно?

2 3 4 5 + rot rot + * .  45  ok

И никаких стеков возврата.

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

Но forth это не язык программирования. Это язык метапрограммирования даже больше чем лисп. На лиспе можно вполне писать в стиле питона, вообще не прикасаясь к defmacro. А вот на форте любая попытка выйти за пределы калькулятора составляют больную боль, пока свой DSL не напишешь (потом всё равно будет больно). А на каком уровне язык предметной области напишешь, на таком и будет.

Про шитый код - по-моему, какая-то прохладная былина из времён ассемблерных портянок. Сейчас я не вижу разницы, между скомпилированным фортовым словом и скомпилированной же функцией.

И никаких стеков возврата.

1. Людям сложно держать в голове манипуляции со стеком (ROT, OVER, SWAP и тп) - так проще воспринять код.

2. По-хорошему вместо стека возвратов хороший компилятор поставит значение в регистр CPU - то есть даже не будет чтения/записи в память. Собственно код по итогу будет сильно похож на тот, который получают в других языках (за исключением фишки шитого кода).

Людям сложно держать в голове манипуляции со стеком

Ну, батенька, при таких вводных вы форт не продадите.

Ну, батенька, при таких вводных вы форт не продадите.

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

Про шитый код - по-моему, какая-то прохладная былина из времён ассемблерных портянок. Сейчас я не вижу разницы, между скомпилированным фортовым словом и скомпилированной же функцией.

Шитый код (threaded code) в классическом понимании малоэффективен для современных 64-битных процессоров. На старых 8- и 16-битных архитектурах он обеспечивал идеальный баланс между высокой плотностью кода и простотой реализации. Однако фундаментальные изменения в микроархитектуре современных CPU сделали его слабые стороны критическими.

1. Плохо с предсказанием переходов
2. Недозагрузка конвеера.
3. 64-битные указатели занимают больший объем памяти.

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

Вот как раз не надо кричать и бегать как с Rust-ом каким за людьми и рекламировать берите два Форта по цене одного.

Вот так форт и помер, а раст получил популярность.

Шитый код (threaded code) в классическом понимании малоэффективен для современных 64-битных процессоров.

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

P.S. Означенный gforth умеет так

: calc { a b c d -- x } 
  a b + 
  c d + 
  * ;

но а) емнип не стандарт и б) если 4 числа на стеке вызывают сложности, в форт лучше не лезть.

Кроссплатформенность, переносимость и производительность.

То есть Си может быть написан сам на себе и разворачиваться в кросс-платформенный комплекс. А GForth почему-то этих свойств лишён.

А GForth почему-то этих свойств лишён.

Это ваша фантазия, причём злая. Люди упростили себе жизнь, получив бесплатно порт на все архитектуры, где работает gcc. Т.е. практически вообще на все архитектуры с которыми есть шанс столкнуться. Можно ли было обойтись без этого и под каждую архитектуру написать своё ядро форта на целевом ассемблере? Можно, но зачем?

Прямо сейчас пишу на форте для микроконтроллера RP2040, правда не на этом, а на zeptoforth. Программы компилируются прямо на микроконтроллере. Особенно веселит отладка. В интернете есть история про взорвавшийся шаттл из за пропущенной запятой, скорее всего там был форт. Программирую для развлечения - как хобби, а не за деньги ( а то сейчас набегут профессионалы со своими paduk’ами).

Позже хочу попробовать использовать библиотеку raylib вместе с gforth (всё по заветам мистера tsoding), прошлая попытка не увенчалась успехом, так как на gforth 0.7.3 было не очень с вызовом сторонних библиотек не из системных директорий.

Он использует gcc как бэкэнд компилятора или же просто им собирается? Почему бы не написать на самом Форте?

шитость - даже без фортовости - это просто красиво - как можно из балерин и полян собрать виртуалку вот прям вот.

Он использует gcc как бэкэнд компилятора или же просто им собирается? Почему бы не написать на самом Форте?

Насколько разобрался большинство кода там на Forth. Но само ядро включает виртуальную машину vmgen, которая использует в качестве базы Си-код. Для понимания важно также понять, что там несколько «фортов»:

1. Классический шитый(threaded) Forth: запускается как gforth, который используется для отладки

2. есть gforth-fast - как раз тут многие наработки и оптимизации родом из GCC используются для организации работы суперинструкций и кэширования стека.

Идея должна здесь описываться:

«A Portable Forth Engine» (M. Anton Ertl, 1993): Статья, заложившая основы архитектуры Gforth и описывающая, как сделать эффективный Forth-движок на переносимом ANSI C с использованием расширений компилятора GCC (таких как labels-as-values для эффективного шитого кода).

Почему бы не написать на самом Форте?

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

шитость - даже без фортовости - это просто красиво

Пользуясь случаем рекомендую Let over Lambda/Lisp Moving Forth Moving Lisp.

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

запускается, если есть кросс компилятор и архитектура процессора поддерживается в твоём compiler backend, язык С эту проблему особым образом никак не решает

запускается, если есть кросс компилятор

Его, наверное, нужно сначала сделать, да? Сами подумайте, откуда он возьмётся. Так что перед gforth’ом стоит выбор: взять готовый gcc или пилить свой велосипед. А теперь попробуйте сформулировать в явном виде, какие преимущества есть у второго подхода.

Цэ, выродив из себя PostgreSQL, перестаёт быть Цэ и становится PostgreSQL.

Forth, выродив из себя Паскаль, оным Паскалём прирастает.

Именно в этом разница, а не в том, что он стековый или обратный польский.

Он такой же опасный, как Си

Почитайте как-нить «Вверх дном» Жюля нашего Верна. Узнаете, какие дорогие опасности таят в себе безобидные на вид бумажка и карандаш ;)

Ну а, поскольку, если не использовать инфраструктуру компилятора gcc, то кодогенератор для компилятора Форта под новую архитектуру придётся писать самим (ну если там не байткод интерпретируется), то вот это утверждение несколько оптимистично:

Люди упростили себе жизнь, получив бесплатно порт на все архитектуры

Ну или gForth всё-таки использует gcc не только для компиляции самого себя, но и програм на Форте?

это утверждение несколько оптимистично:

самую малость. Большую часть работы делает gcc

wc -l engine/*  
...
15232 total

благодаря чему для поддержки архитектуры достаточно

 find  arch/amd64 -name "*.fs" ! -name "test*" ! -name "*examples*" | xargs wc -l                                                                                                          au-prod_cloud_os_au
  734 arch/amd64/asm.fs
   36 arch/amd64/android/starta.fs
  625 arch/amd64/disasm.fs
 1395 total

Чем вы, спрашивается, недовольны?

Ну или gForth всё-таки использует gcc не только для компиляции самого себя, но и програм на Форте?

Нет, для работы gforth не нужен gcc.

выглядит будто компилятор для этого можно за вечерок написать

В 90х - это было массовой историей. Все, кто познали forth в достаточном объеме, писали свой транслятор.