Здравствуйте, Gaperton, Вы писали:

G>1-я реализация, которую я делал, была для ZX Spectrum . Ничего особенного — применив непосредственный шитый код (команда — прямая ссылка на ассемблер) я порвал FigForth на 30% (там классика — косвенный шитый код). Просто было любопытно — проект для себя. Не сохранился.
Да, ностальгия...

G>2-я реализация — если так можно назвать — курсовая в универе сделаная за пару дней — SQL Server (спокойно!) реализующий подмножество SQL. Времени было мало (по разгильдяйству), и в качестве рантайма для выполения запросов была за несколько часов (рука уже набита — почти по памяти) реализована простая минимально необходимая форт-машина на С. Подход себя оправдал — дешево, и очень быстро. Проект не сохранился — учебная задача на выброс.
Зато какой опыт!

G>3-я реализация — подсистема выполнения встроенного языка системы CQG (простой язык обработки временных рядов).
Что за язык обработки временных рядов.

DK>>Тут ещё такой прикол: т.к. компиляция в машкод, можно отвлечься от чисто стековой архитектуры и приплести использование других регистров процессора, включая все РОН, регистры MMX, SSE, FPU.
G>Вот этого не надо. Весь бонус для меня в том, что я не использую явно регистры, а генерирую код для стековой машины (это сильно проще). А уж дальше пусть само разрешится.
Я о том, что регистры надо использовать не на уровне задачи, а на уровне подсистемы компиляции. Т.е. те же циклы можно реализовать без стека через регистры, ускорить ООП через использование регистров типа EBX, и т.д.
Естественно, использование регистров не должно накладывать след на прикладную часть.

DK>>Насчёт скорости.
DK>>Т.к. компиляция происходит на лету, указатели можно прошивать в код, ускоряя этим работу.
G>Кстати, а что именно подразумевается под компиляцией в native код? Инлайн слов, определенных на ассемблере, + "прямой" шитый код (вызовы JMP word_address)?
Текст программы компилируется в обычный бинарный код процессора, и не важно, где определено слово, на ассемблере, машкодом в форте или макросами форта.
Т.е. нет каких-то извратных шлюзов как в .NET при использовании pInvoke.
За счёт этого достигается максимально возможная скорость и отпадает нужда в конструировании системы команд вымышленного процессора с последующей его эмуляцией, т.к. реальный процессор и есть наш целевой интерпретатор байт-кода.

G>А как насчет стека — делает ли он честную раскладку по регистрам для арифметики?
Вершина стека в регистре EAX, второй элемент в [ESI].
Т.е. например для сложения мы делаем вот что:

  add eax,[esi]
    sub esi,4

Либо инлайним 3 байта макросом на Форте:

: + $ad0601 3, ;

DK>>В Retroforth есть 2 словаря: forth и macro.
DK>>При компиляции слова, если оно найдено в словаре macro, оно сразу же исполняется.
DK>>Это аналог IMMEDIATE в других фортах.
G>Разница несущественна, ИМХО. Будет слово лежать в отдельном словаре, или ему будет выставлен признак IMMEDIATE — не суть. Хотя словарь дает дополнительную возможность контроля, так наверно лучше.
Нет. Насколько мне известно в этом есть гемор, т.к. на каждом шагу надо сравнивать STATE.

DK>>И фишка в том, что в тех фортах СЛОВО либо IMMEDIATE, либо нет, а в Retroforth могут присутствовать сразу обе
G>версии слова, позволяя одному слову исполняться в диалоговом режиме и инлайниться в код при компиляции.
G>Да, так точно лучше. Похоже, автор глубоко понимает идеологию Форт.
Согласен.

DK>>Моя версия ref и giref также абсолютно свободна.
DK>>Единственное требование — не убирать информацию об авторе.
G>Нивапрос . Надо будет — еще и бабок отстегнем. Впрочем, пока такого проекта не планируется, так что на бабки рассчитывать не надо.
Интересно развитие идей, заложенных в Retroforth и ref в частности.