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

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

 - It only modifies existing Draft, Review, 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 2021-03-13 23:11:07 -05:00 committed by GitHub
parent 19faf219a7
commit 5c979a724a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -65,9 +65,7 @@ If [EIP-3337 BEGINDATA](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-33
## Rationale
We modeled this design on the, simple, proven, [archetypal Forth virtual machine](https://users.ece.cmu.edu/~koopman/stack_computers/index.html) of [1970](http://www.ultratechnology.com/4th_1970.pdf). It is a two-stack design -- the data stack is supplemented with a return stack to support jumping into and returning from subroutines, as specified above. Most other models place the return address on the stack.
The separate return stack ensures that the return address cannot be overwritten or mislaid, and obviates any need to swap the return address past the arguments on the stack. Importantly, a dynamic jump is not needed to implement subroutine returns, allowing for deprecation of dynamic uses of JUMP and JUMPI. Deprecating dynamic jumps is key to practical static analysis of code.
We modeled this design on the simple, proven, archetypal Forth virtual machine of 1970. It is a two-stack design -- the data stack is supplemented with a return stack to support jumping into and returning from subroutines, as specified above. The separate return stack ensures that the return address cannot be overwritten or mislaid, and obviates any need to swap the return address past the arguments on the stack. Importantly, a dynamic jump is not needed to implement subroutine returns, allowing for deprecation of dynamic uses of JUMP and JUMPI. Deprecating dynamic jumps is key to practical static analysis of code.
(JUMPSUB and RETURNSUB were also defined in terms of a `return stack` in [EIP-615](https://eips.ethereum.org/EIPS/eip-615))
.