В обычном Форте минимум 3 стека - возвратов, данных и куча(кодофайл), куда добавляются откомпилированные слова и части списка словаря.
Еще для x86 бывает отдельный стек для чисел с плавающей запятой - можно использовать аппаратный на сопроцессоре.

Вообще это напрямую противоречит тому простому факту, что я преимущественно работаю как раз с embedded И если я считаю, что в софт-процессор на базе Форта вовсе необязательно тащить весь зоопарк компромиссов, придуманных в ANS, то имею на это какие-то основания.

Смотрим мировую статистику. Использование 16-битных процессоров медленно, но стабильно падает, поскольку 32-разрядные уже достаточно дешевы, и при этом не заставляют эмулировать привычные программистам 32 разряда на 16. Размер собственно ядра на сегодня довольно мал. А если надо получить совсем уж дешевое решение, используется 8-битный контроллер. Ему часто хватает места только на базовые функции, и даже если там будет Форт, то в силу экономии памяти это опять же не должен быть полный набор фантазий еврокомитетчиков.

а тут, собственно, обсуждение в контексте видения форта для реализации в железе? или таки чисто софт?

Кодофайл как стек? Хм, об этом я не задумывался.
float-стек вообще стараюсь не рассматривать. 8 ячеек всего и обращение к нему где-то десять тактов.
Мол, в форте под х86 имеется два стека и float
Да и вообще ну его нафиг
Но всё ж пользуюсь им. удобно иметь под рукой доп.стек потока управления.
Люблю я, знаете ли, из begin ... again goto строить

Вообще говоря, так аппаратно организован сопроцессор. 8 ячеек - это его регистры, и стековая запись операций является в x86 (тогда уж, если говорить о сопроцессоре, в x87), наиболее естественной и близкой к аппаратуре записью операций.

Знаю.
Но факт фактом 8 ячеек и 10 тактов.
Ну, 8 ячеек? А где же фортеровская широта души
Стеком всё ж удобней пользоваться чем 8 регистрами в нём. Это ж надо ещё запомнить в какой регистр что положил.
То, что регистры организованы в стек, правильно. Удобней goto строить

Ну не знаю. У меня к Форту было в свое время абсолютное требование поддержки плавающей точки на сопроцессоре. Ну просто абсолютное в силу того, что расчетов на нем делал много. Во-первых, глубина стека вполне достаточная для организации даже сложных вычислений. Просто надо вовремя выполнять операции, а не накапливать числа. Во-вторых, как бы ни странно это могло выглядеть, Форт оказался не медленнее, а где-то и быстрее C++, Delphi и подобных компиляторов. Потому что F+ F- F* F/ - это прямые ссылки на команды сопроцессора, и в Форте можно организовывать циклы со счетчиком, вычисляющие следующий адрес простым инкрементом индекса, а другие компиляторы еще могут вставить сложное вычисление адреса с использованием смещений. Поэтому вопрос эффективности Форта при работе с плавающей точкой я для себя закрыл давно. Он вполне эффективен и очень тесно примыкает к эффективности ассемблера.

Сопроцессор для того и сопроцессор чтобы на нём вычислять зн. с плавающей точкой. Не забудем об MMX
Лично мне вычисления сопроцессора не нужны. По крайней мере, пока.

Да, форт вообще во всём эффективен. Иначе создаём на форте с вкраплениями асма нужный DSL, и решаем поставленную задачу

Это, надо сказать, довольно общая формулировка. Она уязвима тем, что так сторонник любого языка может сказать "а выучите мой язык и напишите на нем нужный DSL". Вопросов два - насколько просто писать на этом языке DSL и какой именно круг задач удобно решать таким образом. А так уж очень легко получается - "код пока плохой, но вы все равно пишите, потому что вы же можете сначала написать генератор хорошего кода, а потом решить вашу задачу". Гм, а почему тогда не выбросить промежуточный элемент и не начать писать сразу хороший код? Вот в ответе на этот вопрос и кроется организационная причина использования Форта.

Да наверное, и так, и так?

Ну и на форте код может быть и хорошим и плохим.
Мы-то хорошие
Так-то подумаем. почему на форте можно написать любой DSL?
Простой парсер.
Простой синтаксис
Мгновенный доступ к ассемблеру ( подразумевается [ 0xe9 c, 10 c, .... ] )
Возможность переопределения всего и вся.
Код относительно легко разбить на потоки ( в некоторых языках это проблематично )
Отсутствие типизации
Возможность строить абстракции.
На ЛИСПе тоже так можно. Стек, однако, машине ближе

У меня сложилось твердое впечатление, что еврокомитетчики не столько фантазировали, сколько приводили к общему знаменателю уже существующие Форты. И как раз это у них получилось хорошо. Я вот тут портанул на Win-32 классический FIG-Forth, потом переделал его в Forth-79. И очень стало ясно откуда у чего ноги росли. То есть чем было некоторое свойство Форт изначально и почему и во что оно превратилось в ANSI. Точнее много чего стало ясно, но не все конечно.

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

З.Ы. Помню тут обсуждался стандарт Русского Форта. Но как только я обратил внимание, что
2 /
и
2/
это разные деления и создатели стандарта не могут сей момент упустить, как это поставило в тупик. А комитетчики из ANSI такие тупики разруливали. Только народ их работу что-то не оценил.

Тут ведь все просто. Хотите 2/ ? Хотим ! Ну так и получите FM/REM и SM/MOD

Или еще. Словарь FORTH содержит словарь XXX, а словарь XXX содержит словарь YYY. Будет ли при просмотре YYY просматриваться также и его родитель XXX ?
А я слепил в своем Форте (FIG), что будет и очень просто и красиво слепил. А вот я слепил, что не будет ибо до такой красоты не додумался. А я, наоборот, добавил слово CHAIN которым можно сцеплять любые словари как хош по своему усмотрению. Можно даже с дуру в кольцо их сцепить.
Ну так и заполучите
ONLY FORTH
ALSO SHIT
и рулите словарями как кому в голову взбредает. По идее все должны быть довольны.

Oberon07 Report: 17 страниц
Scheme R5RS: 50 страниц
Lua 5.1 Reference Manual: 112 страниц
...
ANS Forth: 210 страниц ?!

Потом, сколько можно возиться с FIG-ом? Посмотрели бы уже на нестандартный cmFORTH Мура, благо исходный текст есть в сети.