mirror of
https://github.com/status-im/EIPs.git
synced 2025-02-23 20:28:21 +00:00
Update eip-2315.md (#4216)
This commit is contained in:
parent
f682474309
commit
4b7ee74617
@ -81,7 +81,7 @@ SQUARE:
|
||||
|
||||
Total: 50 gas
|
||||
```
|
||||
Using `JUMPSUB` saves **_50 - 24 = 26_** gas versus using `JUMP` – a 52% performance improvement.
|
||||
Using `JUMPSUB` saves *50 - 24 = 26* gas versus using `JUMP` -- a *52%* performance improvement.
|
||||
|
||||
#### **Tail Call Optimization**
|
||||
|
||||
@ -117,9 +117,9 @@ SQUARE:
|
||||
swap1 ; 3 gas
|
||||
jump ; 8 gas
|
||||
|
||||
Total: 35 gas
|
||||
Total: 33 gas
|
||||
```
|
||||
Using `JUMPSUB` versus `JUMP` saves **_35 - 19 = 16_** gas – a 46% performance improvement.
|
||||
Using `JUMPSUB` versus `JUMP` saves *33 - 19 = 14* gas -- a *42%* performance improvement.
|
||||
|
||||
So we can see that these instructions provide a simpler and more efficient subroutine mechanism than dynamic jumps.
|
||||
|
||||
@ -154,7 +154,7 @@ SQUARE:
|
||||
|
||||
Total: 24 gas
|
||||
```
|
||||
Using `RETURNSUB` versus `JUMP` saves **_24 - 16 = 8_** gas – a 33% performance improvement.
|
||||
Using `RETURNSUB` versus `JUMP` saves _24 - 16 = 8_ gas -- a *33%* performance improvement.
|
||||
|
||||
We can also consider the alternative subroutine call, using a version of `JUMPSUB` that pushes its return address on the stack.
|
||||
```
|
||||
@ -172,9 +172,7 @@ SQUARE:
|
||||
swap1 ; 3 gas
|
||||
returnsub ; 3 gas
|
||||
```
|
||||
Total 31 gas, compared to 24 gas for the return stack version.
|
||||
|
||||
_Note that this specification is entirely semantic. It constrains only data usage and control flow and imposes no syntax on code beyond being a sequence of bytes to be executed._
|
||||
Total *31* gas, compared to *24* gas for the return stack version.
|
||||
|
||||
## Specification
|
||||
|
||||
@ -258,6 +256,8 @@ The Yellow Paper has the `stack pointer` (`SP`) pointing just past the top item
|
||||
|
||||
Taken together, these rules allow for code to be (in-)validated by traversing the control-flow graph, following each edge only once.
|
||||
|
||||
_Note that this specification is entirely semantic. It constrains only data usage and control flow and imposes no syntax on code beyond being a sequence of bytes to be executed._
|
||||
|
||||
## Rationale
|
||||
|
||||
We modeled this design on Moore's 1970 [Forth virtual machine](http://www.ultratechnology.com/4th_1970.pdf). It is a simple two-stack design – the data stack is supplemented with a return stack to support jumping to and returning from subroutines, as specified above, and as conceptualized by Turing. The return address (Turing's "note") is pushed onto the return stack (Turing's "delay line") when calling, and the return address is popped into the `PC` when returning.
|
||||
|
Loading…
x
Reference in New Issue
Block a user