ток не очень понимаю какой смысл, локальные переменные это же тоже стек

Кто то из стенфорда реверсинженрул mRNA BioNTech/Pfizer и Moderna. И выложил это на Github =)
https://github.com/NAalytics/Assemblies-of-putative-SARS-CoV2-spike-encoding-mRNA-sequences-for-vaccines-BNT-162b2-and-mRNA-1273/blob/main/Assemblies%20of%20putative%20SARS-CoV2-spike-encoding%20mRNA%20sequences%20for%20vaccines%20BNT-162b2%20and%20mRNA-1273.docx.pdf

как вариант - для фиксированного доступа к локальным переменным, не всегда можно отсчитать от "esp"

Зависит от того какие инструкции есть в машине. У некоторых есть инструкции чтения произвольного элемента со стека. Но это уже не "чистая" стековая машина, а гибридная получается.

Локальные переменные в вм можно где угодно хранить. Стек совершенно не обязательно самое подходящее место. Можно выделять фреймы под локальные переменные функции в куче, а в каком-нибудь связном списке хранить адреса фреймов. Call тогда смотрит сигнатуру функции и скидывает нужное колмчество аргументов со стека в новый фрейм.

А можно, к стати, и через стек возврата передавать. 😉

не понимаю как сделать стековый язык красиво

в данный момент у меня решение как раз такое как выше описано: у меня есть дата-стек, с которым работают все операции, и есть отдельный колстек, на котором лежат стекфреймы, где "стекфрейм" это адрес возврата + ссылка на собственную кучу для локальных переменных, куда идут все аргументы сразу при call

но это выглядит не очень красиво, потому что на каждую функцию собственная куча заводится, почему бы не использовать стек

но стек использовать я так понимаю нельзя, что с ebp/fp, что без него, потому что результат функции тоже возвращается через стек, регистров же нет, нельзя сбрасывать стек до ebp

вот текущее решение - https://gist.github.com/kana-sama/31a7dbcda0d434f0013e4f2227b8c895

return stack я выкинул как ненужный из-за наличия локальной кучи

Во-первых, Вы смотрели как в Forth сделано? Тоже два стека и перекидывание данных между ними. Плюс общая память.
Во-вторых, Вы смотрели как сделано в Factor? 😊

В-третьих, действительно, зачем указатель на фрейм в куче, если можно прямо на стек положить под адресом возврата?

как сделано в forth я видел, я так делал вчера, но сегодня я это разделал обратно

то есть у меня нет ручного return stack, у меня отдельный неуправляемый стек, в который вмка сама пишет неявно по call

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

то есть нужно делать или отдельный ретурн стек как в forth, и требовать чтобы через него возвращался результат только

или делать отдельные кучи, которые не трогают стек

Это зачем? Не понял? Какой лайаут стека-то?

А кроме того, можно и регистр под возвращаемое значение завести.

вот у нас пустой стек: []
мы закинули два аргумента
[1, 2]
мы сделали кол, в стек попал адрес возврата, и frame pointer, текуший стал FP = 4
[1, 2, CP+1, OLDFP]
мы аллоцировали в функции 3 переменных локальных
[1, 2, CP+1, OLDFP, 0, 0, 0]
мы положили на стек результат
[1, 2, CP+1, OLDFP, 0, 0, 0, 42]
мы вычистили все локальные переменные, сбросив все до FP
[1, 2, CP+1, OLDFP]
восстановили FP до OLDFP, вернулись на CP+1
[1, 2]
результат потерялся, аргументы в стеке

регистр завести можно, но тогда это и не очень стековый язык какой-то

Никак. В реальности всё равно придётся стек раскладывать на регистры, а это никак красиво не сделать. Так что тут самое простое - смириться и ограничиться красотой снаружи.

почему add какой-нибудь возвращает результат на стек, а функции в регистр какой-то

есть же разница между языком и его реализацией