Оптимизатор, заметки на полях
Переписал проверку нахождения инлайн-слова в разбираемом коде.
Каждый раз для проверки создаётся функция в хипе (там вызов параметрического слова и указатель на инлайн-код). После проверки функция самоудаляется. Если же слово >OPT обрубило проверочную трассу раньше, то выделенная память под функции также освобождается силами >OPT.
Дабы легче было пользоваться проверкой на развёртку, INLINE-COMPILE, в ядре было переписано.
Слово дополнительно просит функцию компилирования. И если поставить NOOP, то получим длину инлайн-слова.
Касательно проверочной трассы.
Трасса может быть большой. И каждый раз писать что-то вроде ['] >R >INLINE? ['] DUP >INLINE? NUMBER не есть хорошо.
Поэтому строим абстракцию.
Что-то вроде
: TRACE{
0
BEGIN
PASRE-NAME
2DUP S" }TRACE" COMPARE WHILE
['] ENTITY-VOCS >param @ SFIND-IN-VOC
IF
NIP LIT,
ELSE
SFIND
IF
SWAP &INLINE AND IF LIT, ['] >INLINE? COMPILE, ELSE -2003 THROW THEN
ELSE -2003 THROW THEN
THEN
1+
REPEAT
2DROP
LIT, \ n
;
Но случаи могут быть и интересней. К примеру, #оптимизация повторяющихся оптимизаций.
Хоть #LISP садись пиши. Хотя вариант интересный. В плане абстракций Лисп хорош.
Код будет забавным: проверка форт-кода на соответствие шаблона на Лиспе, который написан на форте.
Но это ещё одну фундаментальную вещь продумывать.
А это ж всё-таки глазковая оптимизация. Хотя инструментарий в виде таблицы предкомпиляции есть. Можно потом #натив в псевдокод (на этот раз не в форт-код, а в некий вымышленный асм) и снова в натив.
И тут уже настоящая оптимизация возможна по скорости, размеру, использованию стеков и регистров.
Дополнительно:
Чтобы разгрузить #ассемблер в оптимизаторе, вызываемые ассемблирующие слова можно немного "съоптимизировать". Если установлено, что ассемблирующие слово жрёт 2 параметра и они всегда одинаковы, то оно вызывается 1 раз, а полученный код от него в последующих вызовах компилируется через S,
Пока это делается вручную, думаю над автоматическим использованием.
Таким образом в оптимизаторе будет меньше вызовов и скорость оптимизатора должна увеличиться.
Каждый раз для проверки создаётся функция в хипе (там вызов параметрического слова и указатель на инлайн-код). После проверки функция самоудаляется. Если же слово >OPT обрубило проверочную трассу раньше, то выделенная память под функции также освобождается силами >OPT.
Дабы легче было пользоваться проверкой на развёртку, INLINE-COMPILE, в ядре было переписано.
Слово дополнительно просит функцию компилирования. И если поставить NOOP, то получим длину инлайн-слова.
Касательно проверочной трассы.
Трасса может быть большой. И каждый раз писать что-то вроде ['] >R >INLINE? ['] DUP >INLINE? NUMBER не есть хорошо.
Поэтому строим абстракцию.
Что-то вроде
: TRACE{
0
BEGIN
PASRE-NAME
2DUP S" }TRACE" COMPARE WHILE
['] ENTITY-VOCS >param @ SFIND-IN-VOC
IF
NIP LIT,
ELSE
SFIND
IF
SWAP &INLINE AND IF LIT, ['] >INLINE? COMPILE, ELSE -2003 THROW THEN
ELSE -2003 THROW THEN
THEN
1+
REPEAT
2DROP
LIT, \ n
;
Но случаи могут быть и интересней. К примеру, #оптимизация повторяющихся оптимизаций.
Хоть #LISP садись пиши. Хотя вариант интересный. В плане абстракций Лисп хорош.
Код будет забавным: проверка форт-кода на соответствие шаблона на Лиспе, который написан на форте.
Но это ещё одну фундаментальную вещь продумывать.
А это ж всё-таки глазковая оптимизация. Хотя инструментарий в виде таблицы предкомпиляции есть. Можно потом #натив в псевдокод (на этот раз не в форт-код, а в некий вымышленный асм) и снова в натив.
И тут уже настоящая оптимизация возможна по скорости, размеру, использованию стеков и регистров.
Дополнительно:
Чтобы разгрузить #ассемблер в оптимизаторе, вызываемые ассемблирующие слова можно немного "съоптимизировать". Если установлено, что ассемблирующие слово жрёт 2 параметра и они всегда одинаковы, то оно вызывается 1 раз, а полученный код от него в последующих вызовах компилируется через S,
Пока это делается вручную, думаю над автоматическим использованием.
Таким образом в оптимизаторе будет меньше вызовов и скорость оптимизатора должна увеличиться.