Some questions concerning design

richardhundt / shine

A Shiny Lua Dialect

Other

231 stars 18 forks source link

Some questions concerning design #85

Closed rochus-keller closed 4 years ago

rochus-keller commented 4 years ago

Just came accross your project because of this reference: https://news.ycombinator.com/item?id=21502980 Looks very interesting. May I ask you some questions concerning design decisions?

You wrote "For maximum performance it uses a modified version of the LuaJIT virtual machine"; does this a) mean that the modified version has more performance than the original LuaJIT, or is b) "modified" just meant as additional information? In case of a), are there any measurement results, and is the reason known why it has more performance?
What was the major core benefit you expected in using TvmJIT as a backend compared to the original LuaJIT?
What is the main reason that you don't generate Lua as an intermediate language (or even LuaJIT bytecode directly)?
Unfortunately the original TvmJIT repository doesn't exist anymore, so maybe I could ask you why the original author of TvmJIT considered to fork and modify LuaJIT instead of just implementing an S-expression frontend which translates to Lua source or LuaJIT bytecode?

Thank you.

richardhundt commented 4 years ago

The "maximum performance" does not relate to the modifications, but rather to the LuaJIT ancestry

The main benefit is that TvmJIT allows you to populate the debug bytecode segment with special S-expressions for file and line numbers which map to your language's source. Lua as a compilation target will need a separate source map solution. S-expressions are also natural as an intermediate representation when doing AST transformation.

In earlier projects I was producing LuaJIT bytecode directly. At the time, mine was the only bytecode emitter for LuaJIT (besides LuaJIT itself), and it added a lot of complexity and maintenance overhead. If Lua had directives for specifying #file:line meta-data, and goto (when I started this, LuaJIT only supported Lua 5.1, so encoding arbitrary jumps wasn't really do-able), then it would have been sufficient.

richardhundt commented 4 years ago

I can't really speculate as to why François Perrad deleted the TvmJIT repository. It seems he was proposing it as a back-end for Perl6, which seemed like a reasonable thing to me at the time. Tracking upstream LuaJIT changes and bug fixes was probably time consuming, but I really have no idea why he deleted the repo.

rochus-keller commented 4 years ago

Thank you very much for your response which was very helpful. As far as I understand you there is no specific reason to use TvmJIT besides being able to add the appropriate line numbers to the bytecode binary and unconditional jumps. Emitting bytecode was indeed a little tricky but meanwhile I'm even able to generate register allocations which work (also because of your hint). I will continue to follow this path with an unmodified version of LuaJIT.