status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-23 12:18:16 +00:00
Code Issues Projects Releases Wiki Activity

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

Browse Source 
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 2020-02-20 12:15:10 -07:00 committed by GitHub
parent f26f2409ff
commit 42eb4bb1e4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
EIPS/eip-2315.md
View File

@ -17,7 +17,7 @@ This proposal introduces three opcodes to support subroutines: `BEGINSUB`, `JUM
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.
Having opcodes to directly support subroutines can eliminate this complexity and cost, just as for other physical and virtual machines going back at least 50 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.
@ -49,7 +49,7 @@ offset step opcode stack stack
0 0 PUSH1 3 [] []
1 1 JUMPSUB [3] [1]
2 4 STOP [] [1]
3 2 JUMPDEST [] [1]
3 2 BEGINSUB [] [1]
4 3 RETURNSUB [] []
```
The above code should terminate after 4 steps with an empty stack.
@ -58,7 +58,7 @@ The above code should terminate after 4 steps with an empty stack.
offset step opcode stack stack
0 0 PUSH1 2 [] []
1 1 JUMPSUB [2] [1]
2 2 JUMPDEST [] [1]
2 2 BEGINSUB [] [1]
3 3 RETURNSUB [] []
```
The above code should terminate after 4 steps with an empty stack.
@ -68,11 +68,11 @@ offset step opcode stack stack
0 0 PUSH1 3 [] []
1 1 JUMPSUB [3] [1]
2 8 STOP [] []
3 2 JUMPDEST [] [1]
3 2 BEGINSUB [] [1]
4 3 PUSH1 7 [] [1]
5 4 JUMPSUB [7] [1,5]
6 7 RETURNSUB [] [1]
7 5 JUMPDEST [] [1]
7 5 BEGINSUB [] [1]
8 6 RETURNSUB [] [1]
```
The above code should terminate after 8 steps with an empty stack. The above code should terminate after 8 steps with an empty stack.
@ -118,7 +118,7 @@ We suggest that the cost of `BEGINSUB` be _base_, `JUMPSUB` be _low_, and `RETUR
```
## 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` - which will cause a jump to a destination which is a `BEGINSUB`, not a `JUMPDEST`.
## Appendix: Comparative costs.