Основным циклом программы сделать цикл из RASLFunction::run()

[Mazdaywik]

Изначально Простой Рефал предполагался как компилируемый язык. Каждая функция Рефала компилировалась в аналогичную функцию C++. Семантика рефал-машины реализовывалась непосредственно: в цикле выбиралась очередная функция из поля зрения и вызывалась. Собственно, этот цикл был основным.

Сейчас взят курс на интерпретацию (#48). Уже реализован RASL, реализованы структуры времени выполнения (дескрипторы функций, #46), осталось реализовать двоичное представление и динамический загрузчик (собственно, #48). И теперь при выполнении интерпретируемого кода имеют место два цикла: цикл выбора следующей функции и цикл выполнения инструкций RASL.

Наблюдение: если успешно завершилась функция, написанная на RASL’е (refalrts::RASLFunction::run()), то следующая функция, скорее всего, тоже будет написана на RASL’е. Очевидно почему: в RASL обычно компилируются сразу несколько единиц трансляции (например, сейчас — за раз компилируется srefc, srmake и lexgen, за исключением библиотек srlib, компилируемых отдельно), либо, даже если только одна, то она содержит несколько функций, которые могут вызывать друг друга. Следствие: вместо завершения RASLFunction::run() можно извлекать со стека следующую функцию, и если она тоже написана на RASL’е, перезагружать переменные (указатели на интерпретируемый код и константы) и продолжать выполнение.

Слабое место здесь — проверка следующей функции, ибо нужно убедиться, что в поле node->function_info->ptr находится именно указатель на &RASLFunction::run. Но можно изменить представление функций таким образом, чтобы избегать данной проверки. Для этого в refalrts::RefalFunction поле ptr с указателем на функцию заменить на указатель на интерпретируемый код. Таким образом, все функции можно будет считать интерпретируемыми:

• RASLFunction — уже интерпретируемые, уйдёт избыточное поле ptr, добавится новый опкод, перегружающий поля констант (см. ниже),
• нативные функции — появится новый подтип NativeFunction, имеющий дополнительное поле ptr, RASL этой функции будет содержать единственную команду — вызвать себя как нативную,
• RefalSwap — RASL статического ящика также будет содержать единственную команду «обменять»,
• RefalEmptyFunction — RASL содержит единственную команду — refalrts::icFail.

Пояснения тут требует функция RASLFunction. RefalFunction не содержит полей констант, они есть только в наследнике RASLFunction. В текущей реализации RASLFunction::run() в начале извлекаются константы из дескриптора функции, затем происходит выполнение RASL’а. Если будет единый цикл для всей программы, то при переходе к следующей функции на RASL’е потребуется перезагрузка этих полей. Для этого имеет смысл ввести специальную команду, подгружающую новые значения констант из дескриптора.

В качестве оптимизации команду перезагрузки можно не добавлять функциям, которые не содержат констант, либо ввести частные команды оптимизации, которые перезагружают только часть полей (только функции, только идентификаторы). Последнее имеет смысл, поскольку, например, гигантские целые используются крайне редко, строки — тоже нечасто. Другая оптимизация: генерировать единые таблицы констант на единицу трансляции, не перезагружать константы в тех локальных функциях, которые вызываются только непосредственно. Но это частности, которые можно сделать позже.

К слову, при таком подходе обретает смысл задача #47 — для статических ящиков использовать не цельную команду, а последовательность команд RASL’а.

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

Можно заметить, что ожидаемый результат напоминает архитектуру РЕФАЛа-5. Там аналогично главный цикл программы — цикл выполнения команд RASL’а, для вызова встроенных (≈нативных) функций существует специалный опкод, функции завершаются опкодом, выполняющим переход к следующему шагу. В данном случае это не «слизывание», а результат конвергенции: схожие задачи приводят к схожим решениям.