Вынос дескриптора функции из узла поля зрения

[Mazdaywik]

Узел поля зрения представляет собой структуру, содержащую ссылки вперёд, назад, тег типа и объединение. Актуальное поле объединения определяется тегом типа. Большинство полей объединения занимают только одно поле, исключение составляют function_info типа refalrts::RefalFunction и swap_info типа refalrts::RefalSwapHead. Первый хранит два поля: указатель на функцию и указатель на её имя (const char*), второй — указатель на следующую голову статического ящика и указатель на имя ящика. Очевидно, в обоих случаях имя используется при печати дампа поля зрения.

Предлагается сделать эти поля указателями на соответствующие объекты. Профит:

• уменьшение размера узла на 20 % (с точки зрения ОЗУ на современных компьютерах это не интересно, но вот на кэш процессора может повлиять),

• устранение костыля return refalrts::FnResult(refalrts::cRecognitionImpossible | (__LINE__ << 8)), необходимого для корректной работы с пустыми функциями,

• упрощение преобразования Простого Рефала в интерпретатор,

• возможность пополнять дескриптор функции (запись refalrts::RefalFunction) дополнительными полями.

  Что же это за поля?

  • Функции, скомпилированные в режиме интерпретации, выглядят совершенно одинаково: определение нескольких константных статических массивов и вызов функции интерпретации в операторе return. Можно указатели на эти массивы помещать в дескриптор, а в поле указателя на функцию разместить функцию-интерпретатор. Интерпретатор будет анализировать терм конкретизации <Callee …>, находя там себя (Callee) и находя в себе указатели на массивы. В целях экономии памяти (чтобы функции, скомпилированные в режиме прямой кодогенерации не имели избыточных дескрипторов) дескриптор интерпретируемой функции можно унаследовать от общего дескриптора.
  • Поле флагов, может использоваться отладчиком, профилировщиком, рантаймом (зачем-нибудь). Более подробные мысли можно найти в Срастить профилировщик с рантаймом Mazdaywik/mrefal#5.
  • По аналогии с функциями режима интерпретации все статические ящики имеют идентичный код, содержат внутри себя статическую переменную для хранения данных. Статическую переменную можно заменить полем дескриптора.
  • В конце концов пустые функции можно реализовать аналогично функциям режима интерпретации и статическим ящикам — имена у всех будут разные, но указатель на функцию может быть один и тот же (в норме он всё равно не вызывается).

Задача реализуема, и даже реализована, лежит в побочной ветви 4words. Влияние на производительность — ничтожное (замедление где-то 0,5 %…1 %), причём его можно списать на большее число шагов рефал-машины.

[Mazdaywik]

Задача выполнена, как и предполагалось. Помимо непосредственно генерации дескрипторов для функций, также сделаны особые дескрипторы для пустых функций, статических ящиков и интерпретируемых функций (как и предполагалось в задании). Быстродействие я не измерял, но даже если оно и упало, снижение с лихвой компенсируется возможностью написать полноценный интерпретатор.

P.S. Первоначальный вариант предполагал, что функции описывают дескриптор refalrts::RefalFunction и его наследники, но для ссылок на функции из других единиц трансляции используется только refalrts::RefalFunction. Такой вариант работал в BCC 5.5, GCC (MinGW), CLang, но не работал в Microsoft Visual C++. Чтобы это исправить (fac62b7), пришлось добавить ещё один уровень косвенности: на каждый создаваемый дескриптор указывает ссылка refalrts::RefalFunction&, такие же ссылки импортируются при помощи $EXTERN. Всё вроде работает.