Тут надёжнее будет залезть в документацию к г-форт (джи-форт?), но кому из нас оно надо...

С учётом того, что нейросети могут писать лютый бред

Где ты увидел враньё?


Тебе непонятен термин "глубина стека"?


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


Поясни.

Вот ещё от ИИ

"Краткая анатомия JIT-оптимизатора Gforth

Традиционный Форт работает медленно, потому что он постоянно гоняет данные через оперативную память: берёт число из ОЗУ, кладёт на стек, берет второе, складывает, возвращает в ОЗУ.

JIT-компилятор в Gforth 0.7.9 выполняет динамическую трансляцию Форт-слов в нативные машинные инструкции процессора. При этом он применяет несколько агрессивных стратегий:

1. Регистровое кэширование стека (Везде, не только в циклах)

Процессор работает с регистрами (RAX, RBX) в сотни раз быстрее, чем с ОЗУ. Оптимизатор Gforth переносит вершину стека данных Форта прямо в регистры процессора:
• TOS (Top of Stack — верхний элемент): Почти всегда сидит в регистре RBX].
• NOS (Next on Stack — второй элемент): Садится в регистр R12.

Если вы пишете простое слово : 2+ 2 + ;, оптимизатор не трогает стек в ОЗУ. Он генерирует для CPU одну нативную команду: add rbx, 2 . Это работает со скоростью света!

2. Оптимизация вызовов (Inlining / Подстановка)

Если Форт-слово короткое, оптимизатор полностью стирает сам факт вызова этого слова. Он берет его машинный код и вшивает прямо в место вызова. Это убирает накладные расходы на прыжки по памяти (call / ret).

3. Оптимизация ветвлений (if ... else ... then)
Компилятор анализирует условия и превращает их в инструкции аппаратного предсказания переходов CPU (Conditional Moves, такие как cmov), чтобы процессор не терял такты на пустых остановках конвейера вычислений.
"

Там глубина ровно какая? 2 элемента или 3 элемента?

В принципе, название g<что-то> сразу наводит на ассоциации, что это для Линукса. То есть "как бы стандартный Форт, если у вас Gnome". Уж если за такое взялись, можно было ожидать, что будет проведена какая-то работа для его адаптации под типичные задачи Линукса. За десятки лет. Если этого за такое время не произошло, то вряд ли уже произойдет - тут работает "ловушка потраченных усилий". Что интересно, Эртл уже когда-то выступал на Еврофорте с докладом "тут в Си очень много неоднозначностей, поэтому надо gforth переписать на ассемблере". То есть вроде бы коррекция... вот только 1) сам тезис про уход от Си - как минимум предмет дискуссии 2) бессистемная игра с терминами "производительность, размер, надежность" ни к чему хорошему не приводит. Надо было идти к пользователям (а скорее интеграторам) Линукса и спрашивать, что они хотят видеть в продукте.

Вопрос в контексте.
Если у нас есть некий условный код слова на форте и оптимизатор г-форта всё слово перехреначивает по регистрам, то вопросов нет. Хоть 3 элемента стека кэшируй, хоть 10.

Если же это г-форт по дефолту в режиме исполнения/компиляции кэширует 3 верхних элемента стека... Что могу сказать, месье знает толк в извращениях)

Опять жеж из текста ии не совсем понятно, что она имела ввиду

Идиёт ваш ИИ!
Надо было LEA RBX, [RBX+2]. Памяти занимает столько же, но LEA не трогает регистр флагов!

И да, что-то мне подсказывает, что в компухтере скорость передачи данных чуточку ниже скорости света...

Допустим у нас по коду чистый стек в форт-системе, без кэширования в регистрах.

Код DUP

MOV RDX, [RBP] ; копируем значение из стека в регистр для последующей вставки
LEA RBP, [RBP+CELL] ; увеличиваем глубину стека
MOV [RBP], RDX ; копируем значение на верхушку стека
RET

Код DUP, если вершина стека кэшируется в регистре RAX (например)
LEA RBP, [RBP+CELL]
MOV [RBP], RAX
RET


Код DUP, если 2 верхних элемента стека кэшируются в регистре RAX и RCX (например)
LEA RBP, [RBP+CELL]
MOV [RBP], RCX
MOV RCX, RAX
RET

Как это будет при кэшировании 3 элементов даже не хочу писать, это страшно)

Он не мой, а гугловский

"ФИНАЛЬНЫЙ ТРИУМФ НАД QT", "Безошибочный и Окончательный код", "Ультимативный запуск через экспорт переменных Linux", "Безошибочный и Абсолютно Автономный код", "Безошибочный и Идеальный Форт-код", "Железобетонный запуск через системные флаги CPATH и LIBRARY_PATH", "Кристально чистый и независимый код", "Запуск ультимативного JIT-моста", "Кристально чистый Форт-код на чистом Ассемблере", "Триумфальная проверка восстановленного файла", "Великий триумф нативного ассемблера!", "Великий триумф нативного ассемблера!", " Финальный триумфальный запуск!", "ВЕЛИКАЯ ФИНАЛЬНАЯ ПОБЕДА", - вот такие описания программ этот ИИ давал. Он видимо был ориентирован на подержание интереса пользователя.

Но не смотря на это, благодаря этому ИИ оказалось возможным написать на форте программки работающие с QT и GTK, программу компилирующую форт-программы в автономный исполняемый файл (elf), программу "Множество Мандельброта", "Жизнь" Конвея и утилитку для линукса. .

g не всегда равно Gnome, иногда это GNU. А GNU = "GNU's Not Unix!"

А, почему бы и нет?
Если Форт хоророшо воспринимается человеческим мозгом (или напрочь отвергается не понятными умами), то с ИИ здесь тоже так же.
У меня тоже есть интересные наброски в общении с Gemini по Форт идеям, но уровень решаемых задач с /на Форт ему ещё не поднимал.

P.S. Предполагается ли какая то, к примеру, публикация по такому полученному опыту?
Гугл и возможно его "индусы" прокачивают Форт в его моделях.

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

Если кому будет интересно, то в JIT-компилятре gforth'а локальные переменные, которые объявлены { и }, можно применять только внутри циклов, поскольку будучи использованными вне циклов они корежат стек возвратов.

т.е. там какой то свой способ формирования и работы с локальными переменными?
А, проявляется ли это в коде Форт-систем, к примеру, Win32Forth, SPF4, Vfx Forth, Swift Forth и других Форт системах?