Automatically merged updates to draft EIP(s) 2315 (#2523)

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

EIPS/eip-2315.md

@@ -11,16 +11,23 @@ created: 2019-10-17
 
 ## Abstract
 
-This proposal introduces two opcodes to support subroutines:  `JUMPSUB` and `RETURNSUB`.
+This proposal introduces three opcodes to support subroutines:  `BEGINSUB`, `JUMPSUB` and `RETURNSUB`.
 
 ## Motivation
 
-The EVM does not provide subroutines as a primitive.  Instead, calls must be synthesized by fetching and pushing the current program counter on the data stack and jumping to the subroutine address; returns must be synthesized by getting the return address to the top of stack and jumping back to it.
+The EVM does not provide subroutines as a primitive.  Instead, calls can be synthesized by fetching and pushing the current program counter on the data stack and jumping to the subroutine address; returns can be synthesized by contriving to get the return address back to the top of stack and jumping back to it.  Complex calling conventions are then needed to use the same stack for computation and control flow.  Code becomes harder to read and write, and tools may need to pattern-match the conventions to identify the use of subroutines.  Complex calling conventions like these can be avoided using memory, but regardless, it costs a lot of gas.
+
+Having opcodes to directly support subroutines can eliminate this complexity and cost, just as for other machines and interpreters going back at least 60 years.
+
+In the Appendix we show example solc output for a simple program that uses over three times as much gas just calling and returning from subroutines as comparable code using these opcodes.
 
 ## Specification
 
+##### `BEGINSUB`
+Marks the entry point to a subroutine.
+
 ##### `JUMPSUB`
-Jumps to the address on top of the stack, which must be the offset of a `JUMPDEST`.
+Jumps to the destination address on top of the stack, which must be the offset of a `BEGINSUB`.
 
 ##### `RETURNSUB`
 Returns to the most recently executed `JUMPSUB` and advances to the following instruction.
@@ -74,7 +81,7 @@ The above code should terminate after 8 steps with an empty stack.  The above co
 
 No clients have implemented this proposal as of yet, but there are Draft PRs on the [evmone](https://github.com/ethereum/evmone/pull/229) and [geth](https://github.com/ethereum/go-ethereum/pull/20619) interpreters.
 
-The new operators proposed here are demonstrated by the following pseudocode, which in seven lines adds a return stack and cases for `JUMPSUB` and `RETURNSUB` to a simple loop-and-switch interpreter.
+The new operators proposed here are demonstrated by the following pseudocode, which adds a return stack and cases for `BEGINSUB`, `JUMPSUB` and `RETURNSUB` to a simple loop-and-switch interpreter.
 ```
 bytecode[code_size]
 data_stack[1024] = { }
@@ -84,10 +91,13 @@ while PC < code_size {
    opcode = bytecode[PC]
    switch opcode {
    ...
+   case BEGINSUB:
+   
    case JUMPSUB:
       push(return_stack, PC)
       PC = pop(data_stack)
       continue
+
    case RETURNSUB:
       PC = pop(return_stack)
    }
@@ -98,14 +108,79 @@ Execution of EVM bytecode begins with one value on the return stack—the size o
 
 ### Costs and Codes
 
-We suggest the cost of `JUMPSUB` should be _low_, and `RETURNSUB` should be _verylow_. 
+We suggest that the cost of `BEGINSUB` be _base_, `JUMPSUB` be _low_, and `RETURNSUB` be _verylow_. 
  Measurement will tell.  We suggest the following opcodes:
+
 ```
+0xb2 BEGINSUB
 0xb3 JUMPSUB
 0xb7 RETURNSUB
 ```
 ## Security Considerations
 
-Program flow analysis frameworks will need to be updated to allow for a new type of branch -`JUMPSUB` - and new type of branching - `RETURNSUB` - which will cause a jump to a destination which is a `JUMPSUB`, not a `JUMPDEST`. 
+Program flow analysis frameworks will need to be updated to allow for a new type of branch - `JUMPSUB` - and new type of branching - `RETURNSUB` - which will cause a jump to a destination which is a `JUMPSUB`, not a `JUMPDEST`.
+
+## Appendix: Comparative costs.
+
+```
+contract fun {
+    function test(uint x, uint y) public returns (uint) {
+        return test_mul(2,3);
+    }
+    function test_mul(uint x, uint y) public returns (uint) {
+        return multiply(x,y);
+    }
+    function multiply(uint x, uint y) public returns (uint) {
+        return x * y;
+    }
+}
+
+```
+Here is solc 0.6.3 assembly code with labeled destinations.
+```
+   TEST:
+     0x00
+     RTN
+     0x02
+     0x03
+     TEST_MUL
+     jump
+   TEST_MUL:
+     0x00
+     RTN
+     dup4
+     dup4
+     MULTIPLY
+     jump
+   RTN:
+     swap4
+     swap3
+     pop
+     pop
+     pop
+     jump
+   MULTIPLY:   
+     mul
+     swap1
+     jump
+```
+solc does a good job with the multiply() function, which is a leaf.  Non-leaf functions are more awkward to get out of.  Calling `fun.test()` will cost _118 gas_, plus 5 for the `mul`.
+
+  This is the same code written using `jumpsub` and `returnsub`.  Calling `fun.test()` will cost _34 gas_ (plus 5).
+```
+   TEST:
+     0x02
+     0x03
+     TEST_MUL
+     jumpsub
+     returnsub
+   TEST_MUL:
+     MULTIPLY
+     jumpsub
+     returnsub
+   MULTIPLY:
+     mul
+     returnsub
+```
 
 **Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).**