[EPIC] AVM instruction set and wire format are finalized #9059
Labels
Milestone
Comments
dbanks12
changed the title
dbanks12
changed the title
fcarreiro
added a commit
that referenced
this issue
Oct 11, 2024
Make most instructions take offsets as u16. The ones that were not migrated are expected to change or be removed. Yields ~2% bytecode size improvement in public_dispatch. Part of #9059.
fcarreiro
added a commit
that referenced
this issue
Oct 11, 2024
Yields ~5% reduction in bytecode size (public_dispatch). Part of #9059.
iAmMichaelConnor
removed
the
T-tracking
This was referenced Oct 30, 2024
fcarreiro
added a commit
that referenced
this issue
Oct 30, 2024
Contrary to what was expected months ago, we have to support contracts > 65 kB. So we need 32 bit locations in the upcoming move to byte-indexed PCs. This increseases bytecode ~8% in the short term. In the longer term, we might introduce relative jumps with 8 and 16 bit variants. That would likely leave us in an even better place than where we are today. Part of #9059.
fcarreiro
added a commit
that referenced
this issue
Nov 4, 2024
This PR moves the AVM to use byte-indexed PCs * Modifies the transpiler to remap brillig PCs * Modifies the simulator to use byte indexed PCs * Modifies witgen and circuit to use byte indexed PCs Why are we doing this? * Needed for bytecode decomposition in the circuit. * Allow storing other stuff besides code in a contract, and then be able to use it in memory with an opcode "CODECOPY" or similar. --- A note on how PCs are mapped in the transpiler: we do 2 passes. First we translate all instructions and leave brillig location operands as `BRILLIG_LOCATION`. On a second pass, since now we know the structure of the program and the brillig=>AVM pcs, we replace those. There are a few big caveats 1. ~Since the JUMP(I) and INTERNALCALL operands are U16, we cannot jump or call a location bigger than 2^16. This effectively constrains the contract size to 65kB.~ We use 32 bit jumps now. 2. We can do the transformation in (only) 2 passes because we only have 1 variant of JUMP etc. Suppose we had an 8 bit variant, or a 32 bit variant, then we wouldn't know which one to use until the original PC has been mapped, but that itself can change the size of the instructions and trigger a remapping! Solutions? * For (1) I might propose having relative jumps JUMP(I)R with 8 and 16 bit variants, and an absolute JUMP with 32 bits. * For (2) we might just need to remap until there is no change. Part of #9059.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tasks
The text was updated successfully, but these errors were encountered: