Automatically merged updates to draft EIP(s) 615

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Greg Colvin 2019-02-25 20:21:07 -07:00 committed by EIP Automerge Bot
parent 5463adcf50
commit c942b7194e
1 changed files with 10 additions and 1 deletions

View File

@ -74,17 +74,21 @@ The two most important uses of `JUMP` and `JUMPI` are static jumps and return ju
Static jumps are provided by
* `JUMPTO jump_target`
* `JUMPIF jump_target`
which are the same as `JUMP` and `JUMPI` except that they jump to an immediate `jump_target` rather than an address on the stack.
To support subroutines, `BEGINSUB`, `JUMPSUB`, and `RETURNSUB` are provided. Brief descriptions follow, and full semantics are given below.
* `BEGINSUB n_args, n_results`
marks the **single** entry to a subroutine. `n_args` items are taken off of the stack at entry to, and `n_results` items are placed on the stack at return from the subroutine. The subroutine ends at the next `BEGINSUB` instruction (or `BEGINDATA`, below) or at the end of the bytecode.
* `JUMPSUB jump_target`
jumps to an immediate subroutine address.
* `RETURNSUB`
returns from the current subroutine to the instruction following the JUMPSUB that entered it.
#### Switches and Virtual Functions
@ -94,11 +98,13 @@ Dynamic jumps are also used for `O(1)` indirection: an address to jump to is sel
Dynamic jumps to a `JUMPDEST` are used to implement `O(1)` jumptables, which are useful for dense switch statements, and are implemented as instructions similar to this one on most CPUs.
* `JUMPV n, jump_targets`
jumps to one of a vector of `n` `JUMPDEST` offsets via a zero-based index on the stack. The vector is stored inline at the `jump_targets` offset after the BEGINDATA bytecode as MSB-first, two's-complement, two-byte positive integers. If the index is greater than or equal to `n - 1` the last (default) offset is used.
Dynamic jumps to a `BEGINSUB` are used to implement `O(1)` virtual functions and callbacks, which take just two pointer dereferences on most CPUs.
* `JUMPSUBV n, jump_targets`
jumps to one of a vector of `n` `BEGINSUB` offsets via a zero-based index on the stack. The vector is stored inline at the `jump_targets` offset after the DATA bytecode, as MSB-first, two's-complement, two-byte positive integers. If the index is greater than or equal to `n - 1` the last (default) offset is used.
#### Variable Access
@ -106,9 +112,11 @@ jumps to one of a vector of `n` `BEGINSUB` offsets via a zero-based index on the
These operations provide convenient access to subroutine parameters and local variables at fixed stack offsets within a subroutine. Otherwise only sixteen variables can be directly addressed.
* `PUTLOCAL n`
Pops the stack to the local variable `n`.
* `GETLOCAL n`
Pushes the local variable `n` onto the stack.
Local variable `n` is the nth stack item below the frame pointer, as defined below.
@ -118,6 +126,7 @@ Local variable `n` is the nth stack item below the frame pointer, as defined bel
There needs to be a way to place unreachable data into the bytecode that will be skipped over and not validated. Indirect jump tables will not be valid code. Initialization code must create runtime code from data that might not be valid code. And unreachable data might prove useful to programs for other purposes.
* `BEGINDATA`
specifies that all of the following bytes to the end of the bytecode are data, and not reachable code.
### Semantics
@ -133,7 +142,7 @@ We will adopt the following conventions to describe the machine state:
* `SP[0]` is where a new item is can be pushed on the stack.
* `SP[1]` is the first item on the stack, which can be popped off the stack.
* The stack grows towards lower addresses.
* The _frame pointer_ `FP` is set to `SP + n_args` at entry to the currently executing subroutine.
* The _frame pointer_ `FP` is set to `SP + n_args` at entry to the currently executing subroutine.
* The _stack items_ between the frame pointer and the current stack pointer are called the _frame_.
* The current number of items in the frame, `FP - SP`, is the _frame size_.