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

Generate Bytecode #167

Closed
jasonwilliams opened this issue Oct 17, 2019 · 11 comments · Fixed by #860
Closed

Generate Bytecode #167

jasonwilliams opened this issue Oct 17, 2019 · 11 comments · Fixed by #860
Labels
E-Hard Hard difficulty problem enhancement New feature or request

Comments

@jasonwilliams
Copy link
Member

Issue here to keep track of.
At some point generating bytecode would be needed.

Example from Rapidus:
https://github.com/maekawatoshiki/rapidus/blob/new-gen/src/bytecode_gen.rs#L474-L558

Spidermonkey:
https://dxr.mozilla.org/mozilla-central/source/js/src/vm/Opcodes.h

V8:
https://github.com/v8/v8/blob/master/src/compiler/opcodes.h

@IovoslavIovchev
Copy link
Contributor

Has any work been done on this?

@jasonwilliams
Copy link
Member Author

@IovoslavIovchev Nope not yet

@Razican Razican added the enhancement New feature or request label Apr 3, 2020
@Razican
Copy link
Member

Razican commented May 19, 2020

This will require a fundamental change on how the interpreter works, but it would be very useful to cache bytecode in the future, and to implement an optimization pass (or multiple optimization passes). Some overview on how V8 does this can be found here: https://v8.dev/blog/ignition-interpreter

@jasonwilliams
Copy link
Member Author

My guess is a new interpreter would be created along side the current one which reads the AST and generates bytecode, there would most likely be a switch for a while ‘—bytecode’

Design doc for ignition
https://docs.google.com/document/d/11T2CRex9hXxoJwbYqVQ32yIPMh0uouUZLdyrtmMoL44/mobilebasic#h.z0c1oogsbnnq

@jasonwilliams
Copy link
Member Author

Do we want to come up with a set of instructions that would work for us, that would get the ball rolling

@IovoslavIovchev
Copy link
Contributor

@jasonwilliams are there any ideas for the VM design/any work done? Are we aiming for a register-based VM? I reckon we need to have some idea what the VM is going to be like before we come up with the instruction set.

@jasonwilliams
Copy link
Member Author

jasonwilliams commented Jun 4, 2020

Are we aiming for a register-based VM?

Yes i would imagine it being similar to the V8 VM with registers and an accumulator

@jasonwilliams
Copy link
Member Author

jasonwilliams commented Jun 6, 2020

Will attempt to base of Jason’s example here:
jorendorff@266319f#diff-8a4e02ddeeda9cccf194eab4892b1c1cR162-R167

There is an issue here though.
Operations on Values have been promoted to the Value level, so the stack needs to either use Values (which isn’t efficient because it will point to the heap for everything) or each instruction will need to box to a Value do the operation then come back down.

For now we will need to do the former, but in future we may have to refactor Values again, so that they’re not so coupled with the Gc.

Similar to the Executable trait we will need a CodeGen trait that each node implements

@IovoslavIovchev
Copy link
Contributor

There is currently a POC branch, with the aim to explore the different options we have.

The current implementation is based on the aforementioned example.

@jasonwilliams
Copy link
Member Author

jasonwilliams commented Jun 7, 2020

#461 POC from @IovoslavIovchev
I've:

  1. Moved instructions into their own file
  2. Implemented Default for Realm (so that VM can implement Default)
  3. Looked into accumulators
  4. Implemented CodeGen for Node

@jasonwilliams jasonwilliams added the E-Hard Hard difficulty problem label Sep 30, 2020
@Razican
Copy link
Member

Razican commented Jan 2, 2021

Is this really closed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-Hard Hard difficulty problem enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants