ath писал(а):
Victor__v писал(а):
При целевой компиляции размер Новы ужимается примерно на 2 кб. Эта работа делается препроцессором написанным на форте. Простота заданий подстановок делает препроцессор идеальным вариантом для сборки стабильного форт-кода (т. е. без полиморфизма).
Но для оптимизации кода для приложений он может не подойти из-за того же полиморфизма.
Можете поделиться опытом оптимизации самого транслятора? Мне он крайне интересен из-за низкого быстродействия и скромной памяти моей платформы. Где там резервы, кроме очевидных низкоуровневых подстановок, вроде «1 +» на INC?
Насколько я понимаю, оптимизация транслятора во многом отличается от оптимизации приложения. В частности потому, что слова целевого (компилирующегося для целевой машины) компилятора будут использоваться приложениями. И те же целевые «+», «DUP», «FIND» невозможно, например, полностью убрать в инлайн. Скорее всего, и другие подводные камни есть.
У меня всё что можно убрано в инлайн. Поддержка такого механизма на уровне ядра.
По поводу резервов.
Экономит замена связки "вызов кода, конец определения" на безусловный переход на вызов кода.
Препроцессор вообще изголяется так
на входе
Код:
... WORD ;
на выходе
Код:
... [ ' WORD 3 ] AGAIN [
Однако такая подмена в Нове возможна далеко не для всех слов, пришлось прописывать все возможные адекватные варианты через множество.
Ещё очень специфичная вещь: оптимизация компилирующих слов, которые шаманят непосредственно кодами.
Т.е.
у нас код 0x1 C, 0x2 C, преобразуется в 0x0102 W,
Но сильнее всего экономит оптимизация условий.
тот же DUP IF неплохо усекается.
Ну оптимизации со стеком возвратов (из-за специфики моего форта).
Была ещё оптимизация вида "0 ;" заменить на "jmp FALSE". Но я от неё отказался, хотя экономило нормально.