Можно еше так

Подробности найдете здесь: https://github.com/lua/lua
В первую очередь, файлы lparser.c, lcode.c и lvm.c

Ну т.е. У них переменные это не виртуальные регистры того же llvm, которые и надо отобразить на реальные (понимаю, что реальных здесь нет, это просто слоты в вм)?

Но это же 256 регистров на функцию — там же стек локальный, а не глобальный, как я помню?

Да, это было и в процитированных мной комментариях к коду.

Т.е. общее количество виртуальных регистров будет 256*количество функций в программе (и библиотеках).

А у них есть бенчи в сравнении с v8, к примеру?

Там все проще. Эти регистры — просто слоты в стеке. То есть в реальности есть стек и "регистровое окно" для эффективной работы с этим стеком.
Проблема в отсутствие спиллинга может возникнуть в неочевидных для пользователя сообщениях "function or expression needs too many registers".

luajit все еще самый быстрый, насколько я знаю

Помогите с проекциями футамуры разобраться) точнее с возможностью применения на практике..
допустим есть int - интерпретатор языка L, допустим сделанный на f#.
Тогда согласно 1й проекции
spec(int,p) = intp
Получается что специализатор spec также должен быть на f# и фактически уметь манипулировать f# ast и выдавать также программу на f# (прям генерить исходник на f#?), которая и будет специализацией интерпретатора int для программы p на языке L. Я все верно понял?
2. основная непонятка, допустим есть функция на f# reduce которая умеет по части входных данных редуцировать программу 'p' (которая передается в виде ast). Дак вот эта функция (как я понимаю) по сути является специализатором, ведь она "специализирует" входную программу p по частично известным данным. Верно? Если данные известны все, то программа (выражение - p) редуцируется до константы, то есть по сути специализатор является и интерпретатором!? И вот непонятно эта функция reduce както применима для 1й проекции? Вроде как по сути она и делает спец версию программы р (как раз то о чем 1я проекция футамуры), но где тут spec , int??

Есть. И там, как я понимаю, реально по байту отводится на индекс регистра.

Там похоже надо как-то по другому разрабатывать чтобы учитывать этот факт или ос/процессор мапит стек например на часть этих регистров, чтобы было быстрее.

зачем, у тебя есть 256 супер быстрых штук, зачем их замедлять внешней памятью

блоковый префетч туда конечно неплохо бы делать

Наоборот разместить стек на них, а не во внешней памяти

если регистр можно использовать в качестве индекса регистра при операции, то вполне возможно

иначе придется самомодифицируемый код городить

но тут уже 9 бит на регистр выходит )

Если я правильно понял идею, так и делается. Хотя и есть часть того, что сидит в памяти по-нормальному. Но тут хочу уточнить, что операций push/pop я там не видел, только call/ret.