Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Rebuild interpreter on top of compiler (JIT) #1

Open
bitwalker opened this issue Apr 13, 2020 · 0 comments
Open

RFC: Rebuild interpreter on top of compiler (JIT) #1

bitwalker opened this issue Apr 13, 2020 · 0 comments

Comments

@bitwalker
Copy link
Contributor

When the compiler has finished support for the WebAssembly target, we should reimplement the interpreter functionality on top of it. There are a few major reasons for this:

  • The runtime support needed by the current interpreter differs significantly from that needed by the code generated by the compiler; and that gap will only grow over time.
  • The feature set supported by the interpreter and compiler will differ, and since most resources are focused on the compiler, the interpreter will fall behind. If the interpreter builds on top of the compiler, then they remain at parity with each other, and provides a straightforward way to expose a Lumen playground on the web.
  • As the compiler improves, we will be able to move more and more code out of Rust, and into Erlang source, moving to a semi-bootstrapped, or even fully bootstrapped model down the road. This gets complicated if we have to maintain the current interpreter, since it necessarily requires the Rust APIs. Ideally, we'd eventually move the interpreter into an entirely dynamic Erlang implementation, which would end up much simpler, and would act as the foundation for a REPL.

NOTE: This is a long-term goal, not an immediate focus. That said, we should keep in mind that this is where we want to go, and try and incrementally work towards it as much as we can. If we find that we can't continue to support the interpreter, it would be better to remove it and build the new implementation when we're able, rather than keep it around, due to the burden it imposes. That would necessarily require the compiler to be fully functional, but we're already pretty close to that stage now.

@bitwalker bitwalker transferred this issue from GetFirefly/firefly Aug 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant