@Elemir: *programming *forth *оптимизацияЗахотелось мне поговорить про Forth. Один из наиболее частых аргументов против Forth'а — невозможность оптимизации на современных полурегистровых машинах (в amd64 16 регистров общего назначения, а в ia64 целых 128!). Вторым аргументом является неизбежность побочных эффектов (работы с стеком). Я попытаюсь объяснить, как отчасти избавится от этих недостатков.
В качестве базы я возьму rx core — ядро RetroForth до 9'ой версий включительно. Низкоуровневых слов в rx core всего 31 штука. В rx core (как и в большинстве классических фортов) используется два стека (первый называется stack, второй — return stack) и хип. Также замечу, что из 31'ого слова только 5 работают с return stack'ом (при этом они не работают с хипом) и только 4 работают с хипом.
Рассмотрим следующее выражение в обратной польской записи «2 3 4 +». Если рассматривать его как работу со стеком, то оно не берёт ничего, и кладёт в стек 2 числа. Т.е. его можно рассматривать как функцию от 0 параметров, возвращающую пару значений. Аналогично форт-выражение «dup *» это функция от 1 параметра с единичным возвратом. Теперь важно заметить, что все стандартные слова, кроме if-семейства и then, можно описать в таком виде (значит и их композицию тоже). Единственным тонким местом является выражение «if бла бла бла then». Если бла бла бла изменяет размер стека, то теряется детерминированность результатирующего слова и его уже не выразить не прибегая к стеку.
Ну и наконец пример. В rx core выражение «dup *» откомпилируется во что-то такое (rx core держит верхушку стека в eax, использует esi как указатель стека):
mov [esi-4], eax
lea esi, [esi-4]
mul dword [esi]
add esi, 4
В оптимизирующем компиляторе же (параметры лежат в eax, ecx, edx, возврат там же):
call dup ( если dup inline, то mov ecx, eax )
imul eax, ecx
P.S. Сразу извиняюсь за корявости