Ой, какая же пакость эта ваша заливная... x86. Согласен. Поэтому склоняюсь к оптимизации путём генерации при TURNKEY чего то высокоуровневого (С), а существующий gcc уж точно не хуже меня под x86 код сделает.

Ну и где та Форт-система, которая делает эти преобразования?
Так сказать из форт-кода программы выделяет семантику преобразования информации и из этой семантики формирует оптимальный код для целевой платформы.

насчет оптимизаций. Появилась еще идея о возможности использования практики register renaming в достаточно простой форме.

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

итак, допустим, у нас кэшируется два значения с вершины стека данных в регистрах RA и RB и в начальном состоянии RA - хранит верхний элемент.
и дальше у нас идет команда SWAP и тут обычно идет три пересылки на регистровой архитектуре RA> temp RB>RA temp>RB, а можно просто "переименовать" регистры во время компиляции, то есть SWAP не компилируется, но изменяется специальная переменная, которая заставляет следующий код считать вершиной RB а не RA, то есть это приводит нас к созданию двух альтернативных низкоуровневых определений, для работы со стеком, например, код записать (!) будет RA! и RB!, в зависимости от состояния переменной будет компилироваться нужный, иначе говоря, текст:
OVER !
преобразуется к виду:
push RB
RB!
вместо:
push RB
swap ( RA>temp, RB>RA, temp>RB)
!
возможно, кто-то уже делал подобное.?

У http://theforthsource.com/ случайно нету?



Т. е. ты предлагаешь закешировать больше одной ячейки стека, и делать переименование регистров по стековым манипуляторам? Что ж, это идея которую стоит проверить экспериментально. Умозрение тут ничего не даст, а посмотреть интересно.

Но опять же, более реальным основным способом оптимизации в Open Source форте мне представляется использование какого либо готового backend'а. Либо, как ты предполагал llvm (перспективно) и в конце концов результатом будет llvm-форт, либо C. Тут сама форт система остаётся тем, чем была, а к ней пишутся (а) Компилятор в си. (б, опционально) Что типа загрузчика объектных файлов, сгенерированных Си (чтобы можно было смешивать языки).

И то и другое решение, если его сделать, будут иметь неплохой резонанс.

имхо, я тут согласен с Хищником: не нужно думать о резонансе, нужно думать о полезных и нужных вещах.

Там нет и вряд-ли будет даже что-то отдаленно похожее.

Это конечно да.

Ну если этой полезной вещью будет пользоваться 2 с половиной человека, она просто заглохнет.

И меня, кстати, тоже Хищник кое в чём убедил. В том, что надо планировать токую задачу, которую можно довести до конца. Незаконченной полезной вещью не будут пользоваться даже два с половиной человека.

Если дипломник Эртла (не использовавший раньше Форт) смог осилить работающий прототип компилятора подмножества gForth в Си (на gforth), который обогнал по быстродействию полученных программ все протестированные компиляторы Форта, имевшиеся в 1996, это даёт основание рассчитывать, что такой проект (только компилятора с полноценного форта) я в одиночку потяну.

А вот то, что единственный нативный OpenSource форт-компилятор, использующий что-то умнее простых inlining+peephole — это bigForth, изначально написанный как коммерческий проприетарный продукт внушает совсем другие чувства. Скажем так, опасения.

А что из себя их форт представляет?

Могу привести в качестве примера один use case по кварку. Преимущественный способ его использования - последовательные Evaluate строк, подаваемых модулем, к которому кварк подключен как библиотека. Модуль, разумеется, может захотеть посмотреть на состояние стека после выполнения некоторых действий. Если при этом вершина будет лежать в регистре, это обернется определенными сложностями - вершину стека, и остальной стек придется смотреть по-разному.

Ну и тогда уж, до кучи. Вот мы сейчас смотрим на LLVM с целью написания back-endа для процессорного ядра QuarkR. Он предполагается к изготовлению на "Ангстреме" по технологии 0,13 мкм, работать должно на 200 МГц (собственно, дизайн-центр имеет неплохие контакты в ЮВА, и "Ангстрем" - не единственная доступная foundry). В процессоре 32 бита и 32 симметричных регистра, трехадресные и стековые команды выполняются одновременно, без какого-либо переключения режимов (при старте указатель стека стоит на R31, так что к нему можно получить доступ и стековыми, и не-стековыми командами). Таким образом, вопрос об оптимизации работы со стеком не стоит - Форт поддерживается аппаратно, но и Си ляжет достаточно неплохо. Я отнюдь не призываю "пристроиться в хвост колонны", но вот вам пример российского продукта, под который пока нет средств разработки. Вот табличка с системой команд, можно заметить, что правила описания back-end-а довольно-таки регулярны.

это ж freeforth
;;; . almost SWAP-free thanks to compile-time renaming of the two registers
;;; caching the top two DATAstack cells

замечательно!

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


В Форте тоже можно хорошо задействовать(если понадобится).

И кто-то должен всё это доводить, доводить и доводить... Пока всё это не доведёт его. Вон Михаил свой оптимизатор таки забросил. Любая оптимизирующая кодогенерация (если не использовать чужой промежуточный транслятор, где доводкой занимается кто то другой) включает такой элемент, но peephole из него одного и состоит.



Или определением набора векторных слов, или через оптимизацию. Второй способ ничем, по сути, не отличается от того, что в C/Fortran.

Процедуры конкретных доводок просты: берете и делаете(если надо). Никому, в том числе и Михаилу уже не сильно надо. Уже и так все быстро, все основные
моменты уже выбраны. А если что-то на практике встретится медленное можно и ускорить по случаю и очень оперативно. Так сказать оптимизация по необходимости.
Возьмем форт-систему от MPE (VFX). Там уже сделано нечто подобное тому, что предлагал Ертль. И что она на
порядок быстрее СПФ? Таки нет же. Только чуть.

А вот это совсем плохо - значит в оптимизаторе надо вручную подключать веер peеphole-разрешений кода.