Update EIP-2315: reopen #9431 (eip-2315)

EIPS/eip-2315.md

@@ -8,7 +8,7 @@
 type: Standards Track
 category: Core
 created: 2019-10-17
 requires: 3540, 3670, 4200
 withdrawal-reason: This proposal has been superseded by the EOF proposals.
 ---
 
@@ -21,14 +21,14 @@
 * `RJUMPSUB relative_offset` -- relative jump to subroutine
 * `RETURNSUB` -- return to `PC` after most recent `RJUMPSUB`.
 
 It depends on the two new opcodes proposed by [EIP-4200](./eip-4200.md) to support static jumps:
 
 * `RJUMP relative_offset` — relative jump to `PC + relative_offset`
 * `RJUMPI relative_offset` — conditional relative jump
 
 It deprecates `JUMP` and `JUMPI`, allowing valid code to support streaming, one-pass, and other near-linear compilers.
 
 In concert with [EIP-3540](./eip-3540.md) and [EIP-3670](./eip-3670.md) it ensures, at initialization time, that valid code will not execute invalid instructions or jump to invalid locations, will not underflow stack, will maintain consistent numbers of inputs and outputs for subroutines, and will have bounded stack height in the absence of recursion.
 
 This is among the simplest possible proposals that meets these requirements.
 
@@ -113,7 +113,7 @@
    * The `RJUMP`, `RJUMPI`, or `RJUMPSUB` instructions MUST NOT address immediate data or addresses outside of their code section.
 * The stacks MUST be valid:
    * The number of items on the `data stack` MUST always be positive.
    * The number of items on the `return stack `MUST always be positive.
 * The data stack MUST be consistently aligned:
    * The data stack height is
      * the absolute difference between the current `stack pointer` and the `stack pointer` on entry to the current subroutine.
@@ -132,7 +132,7 @@
 
 The constraints on valid code cover all of the exceptional halting states that we can validate and allow code to be validated and compiled in time and space quasi-linear in the size of the code.
 
 The `RJUMP`, `RJUMPI` and `RJUMPSUB` instructions take their *relative_offset* as immediate arguments, which cannot change at runtime.  Having constant destinations for all jumps means that all jump destinations can be validated at initialization time, not runtime.  Dynamic jumps can branch to any destination in the code, so exploitable quadratic "path explosions" are possible when traversing the control flow graph. Deprecating `JUMP` and `JUMPI` prevents this.
 
 Requiring a consistently aligned `data stack`
 
@@ -148,9 +148,9 @@
 
 There are a few major designs for a subroutine facility, two of which are considered here.  The others are mostly not appropriate for the EVM, such as the Wheeler Jump -- self-modifying code that writes return addresses into called subroutines.
 
 *1. Keep return addresses on a dedicated return stack.* Turing's design is often used by stack machines, including those for Forth, Java, Wasm, and others.  The data stack is used for computation, with a dedicated stack for return addresses.  A single instruction suffices to call, and another to return from a routine.
 
 *2. Keep return addresses on the data stack.*  This design is often used by register machines, including those from CDC, IBM, DEC, Intel, and ARM.  The registers are used primarily for computation, and the stack maintains call frames for return addresses, arguments, and local variables.  On the EVM there are no registers for computation, so using the stack for both purposes can cause the sort of inefficiencies we see below.  Pascal p-code does use this design, but as part of a complex calling convention with dedicated registers.
 
 #### We prefer the dedicated return stack.
 
@@ -171,7 +171,7 @@
 Consider these examples of a fairly minimal subroutine, including the code to call it.
 
 Subroutine call, using `RJUMPSUB`:
 ```
 SQUARE:
     dup1            ; 3 gas
     mul             ; 5 gas
@@ -180,11 +180,11 @@
 CALL_SQUARE:
     push 0x02       ; 3 gas
     rjumpsub SQUARE ; 5 gas
 ```
 _Total gas: 19_
 
 Subroutine call, using `JUMP`:
 ```
 SQUARE:
     jumpdest        ; 1 gas
     swap1           ; 3 gas
@@ -201,7 +201,7 @@
     jump            ; 8 gas
 RTN_CALL:
     jumpdest        ; 1 gas
 ```
 _Total: 41 gas_.
 
 Using `RJUMPSUB` versus `JUMP` saves _41 - 19 = 22 gas_ — a _54%_ improvement.
@@ -211,7 +211,7 @@
 Of course in cases like this one we can optimize the tail call, so that the return from `SQUARE` actually returns from `TEST_SQUARE`.
 
 Tail call optimization, using `RJUMPSUB` and `RETURNSUB`:
 ```SQUARE:
     dup1            ; 3 gas
     mul             ; 5 gas
     returnsub       ; 3 gas
@@ -219,7 +219,7 @@
 CALL_SQUARE:
     push 0x02       ; 3 gas
     rjump SQUARE    ; 3 gas
 ```
 _Total: 17 gas_
 
 
@@ -347,7 +347,7 @@
 
 ** Note: this function is known to be incomplete and incorrect. **
 
-For simplicity's sake we assume that all jumpdest analysis and prior validation has been done, including EIP-3540, EIP-3670, and EIP-4200, so EOF headers and sections are well-formed, and there are no invalid instructions or jumps.  In practice, all passes of validation can be folded into a single loop no recursion.
+For simplicity's sake we assume that all jumpdest analysis and prior validation has been done, including [EIP-3540](./eip-3540.md), [EIP-3670](./eip-3670.md), and [EIP-4200](./eip-4200.md), so EOF headers and sections are well-formed, and there are no invalid instructions or jumps.  In practice, all passes of validation can be folded into a single loop no recursion.
 
 We also assume some helper functions.
 * `is_valid(opcode)` returns true iff opcode is valid.