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

Ideas for the bytecode #1385

undingen opened this issue Oct 8, 2016 · 1 comment

Ideas for the bytecode #1385

undingen opened this issue Oct 8, 2016 · 1 comment


Copy link

@undingen undingen commented Oct 8, 2016

Some of this things depend on the bytecode becoming emitted directly into an array #1384 which is unfortunately not ready yet and I'm going on holiday for the next 3 weeks but I will finish it afterwards.
But here are a few additional ideas if someone has time and fells like some of this is fun :-)

  • remove all pointers to CFGBlock inside the opcode with a index into the cfg->blocks array
  • remove the BST_Invoke opcode and instead use a bit in the type field to represent that the current instruction is a invoke (I have a proof of concept for this here: undingen@1bf4e28). If this bit is set it means that directly after the operand of the instruction 2 pointer to CFGBlocks* (or better indices of the block in the blocks array in the cfg) follow. (done in #1391)
  • use a bit in the opcode to specify 1 byte operands. Idea would be to set this bit if all vregs and other operands which are normally 4 byte long fit into 1byte and then use 1byte instead of 4 for them. (this can be tricky to implement because currently we just use the C struct layout). If we did not remove the line number inside the instruction by that time we should also use it for specifying 2byte line numbers instead of 4. I think this would save a lot of memory 😄
  • serialize the bytecode to pyc which should improve startup time. The constants could probably just be pickled (I think this change has very high impact 😄 )
  • rearrange the BST FOREACH_TYPE enum so that operations which have the same size in memory (same num of operands etc..) have a sequential number. This will help the compiler generating better code for iterating over the instructions in the bytecode. Similarly it would be nice if we could rearrange the block terminator types (Branch, Jump, Invoke, Return, Raise, Assert) so that a is_terminator check only requires us to check for a single bit in the opcode)
  • find a better way to represent line numbers (currently 4 byte inside every instruction). Either do something like cpython does or at least use the 1byte opcode bit to also mean use 16bit linenumber instead of 32.
  • remove the InternedString it's just a wrapper around a interned python string
@undingen undingen added the idea label Oct 8, 2016
Copy link

@kmod kmod commented Oct 19, 2016

  • Don't have parent nodes need a reference to their child nodes. They only need some metadata and the code object, but we still keep a reference to the full child BST object. (done in 581cebc)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.