Кое-что было сделано (и делается) специально, с взглядом на будующее. Я где-то "слышал", что XP могла запускаться и на 486.

Наоборот. Первое, что делает каждое новое приложение и/или драйвер - требует обновить Windows...

В каком смысле обновить? Или ты на Win 9x зациклился?)
У меня до сих пор XP стоит, и ничего.

Давайте об этом в другом месте. Мы уже коллеге всю тему замусорили.

пример использования итераторов для перебора всех слов во всех словарях:

Не отлаживал, прост полёт мысли

Несколько слов по бектрекингу.
Бектрекинг тут понимается как "идея реализованная в лоб в каждом конкретном случае".
То есть без либ вообще. Взяли и вызвали остаток кода. Всё.
Основные проблемы при использовании бектрекинговых итераторов:
Как прервать итератор?

Примечание от 13.12.2018
Можно в итератор передавать RP@ для сброса в случае необходимости.




К примеру мы нашли нужное значение и наша задача выйти из итератора.
Как это сделать не зная особенностей реализации отдельного итератора?
Рассмотрим 3 варианта:
1)
Создание конвенции о вызовах итераторов.
В простейшем случае при вызове остатка кода второй элемент на стеке возвратов представляет собою указатель для сброса стека возвратов. Т.е. в остатке кода достаточно сделать так:

Недостатки: усложнение написания итераторов, дополнительная нагрузка на программиста ( поддерживает ли итератор соглашение?)
2)
Использование механизма перехвата исключений.
Достаточно всего трёх слов:
CATCH: \ --> / err|0 <--
\ вызвать остаток кода и перехватить исключение, если оно было. При откате положить на стек код исключения.
TO-CATCH \ -- 0
\ Выйти из кода, который был вызван из CATCH или CATCH: без исключений с сохранением ТОЛЬКО стека данных
THROW^ \ <-- err|0
\ На обратном ходу (при откате) снять число со стека данных и перейти на CATCH ( CATCH: ), если код отличен от 0 с очисткой стеков данных и возвратов.
Недостатки: дополнительная нагрузка на стек исключений, запись THROW^ CATCH: ... может сбить с толку.

3)
Дополнительный инструментарий.
Тут останавливаться особо не над чем.
Реализация доп.стека под бектрекинг и операции с ним описаны у Гасаненко, а также реализована в СПФ у ~profit'а.
Кстати, Гасаненко говорил, что можно использовать не стек, а цепочку.
См. "Одностековая реализация бэктрекинга для языка Форт". Кстати, единственная работа, которую легко найти в инете. Всё остальное пришлось пережёвывать из поставки СПФ.
Недостатки: доп. сущность, за которой надо следить. Новый лексикон в который надо "въехать".
Я, к примеру, 2 месяца пытался понять логику PRO И CONT , и меня внезапно осенило на прогулке На самом деле ничего сложного. Непривычно и всё.

Проблема вторая.
Локальные переменные совместно с итераторами.
Условимся, что переменные должны поддерживать многопоточность.
То есть хранение переменных в ШК не подходит.
Хочется, чтобы можно было делать так:
: TEST { a b } ITER: a ! ... ;
Использование конвенций не выглядит тут оптимальным решением.
А вот варианты 2 и 3 выглядят более менее отлично.
Поскольку 3-й вариант описан, сосредоточимся на 2-ом.
Ограничение: должно использоваться слово CATCH:
Так гораздо проще организовать, однако ж не столь очевидно будет применение этого слова для лок.переменных. А это доп. нагрузка на программиста.
Хм, будем думать дальше как сделать логичней и прозрачней.

Постановка проблемы в первой строке подразумевает негодность (1-3) супротив
4) "реализовать [выход] в лоб в каждом конкретном случае".

Пример: http://gudleifr.forum2x2.ru/t31-topic#243.

Не, ну хочется как-то унифицировать без всяких дополнительных стеков и списков ( >L ).

Меня на форуме вот что зацепило:

неявные вызовы PICK использовал токмо Profit да и то в кач-ве теста.

Это вообще как? Причём тут использование DSL и культура фортописания?

В принципе согласен.
Но стековые манипуляторы позволяют написать низкоуровневые слова без использования ассемблера, при этом сущ-но сокращая скорость написания.
Особенности реализации стек-манипуляторов обсуждать не стоит. Т.к. возможны варианты.

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

Я понимаю так: применение FORTH отрицает потребность в DSL. Новый язык пишется под конкретную проблему, а не под некую "предметную область", к которой потом придется сводить "похожие" проблемы.

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

Ну, я за 2 минуты написал на стек.манипуляторе COMPARE, а перетряхивание данных, для WINAPI вообще вырождается.
Насчёт вычислений не понял.
Имеется ввиду внутренняя реализация манипуляторов?

http://gudleifr.forum2x2.ru/t31-topic?p=241

Это плохо - http://gudleifr.forum2x2.ru/t31-topic?p=247

А я обычно за 0 секунд обхожусь без COMPARE .

http://gudleifr.forum2x2.ru/t31-topic?p=241

Причём здесь СТЕКОВЫЙ МАНИПУЛЯТОР?
Какие там нафиг сложные вычисления?

В самих манипуляторах - никаких. Но если нет сложных вычислений со многими переменными, хранимыми на стеке, зачем нужны манипуляторы?


Ни при чем. Он не нужен.

Зачем?
в форте можно работать "без проблем" с 3 верхними элементами стека
3! = 6 вариантов действий
моя реализация поддерживает 5 переменных-регистров 0 1 2 3 4
5! = 120 вариантов действий
Плюс циклы и условия.
Код очень короток в наборе и очень близок к ассемблерному варианту, а то и полностью идентичен.

Ага, только, по сравнению с операциями с 1-2 параметрами, операции с 5 и 6 параметрами практически равновероятны. Я в своей практике встречал такие считанные разы и, обычно, по собственной дурости.