Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Support EIP2315 (Subroutines). #59

Closed
lialan opened this issue Apr 6, 2020 · 2 comments
Closed

[Feature] Support EIP2315 (Subroutines). #59

lialan opened this issue Apr 6, 2020 · 2 comments
Labels

Comments

@lialan
Copy link

lialan commented Apr 6, 2020

Greg Colvin has already pushed the changes:
ethereum/EIPs#2576

ethereum/go-ethereum#20619

@chfast
Copy link

chfast commented Apr 17, 2020

Do you have any comments how subroutines (as proposed in EIP-3215) would affect LLVM backend? In particular can you map LLVM IR functions to EVM subroutines?

@lialan
Copy link
Author

lialan commented Apr 27, 2020

@chfast The subroutine backend actually simplify things. In particular, in the era of Pre-EIP2315 we will have to maintain the caller context all by ourselves, including pushing return address on to stack. Take a look at this graph: https://github.com/etclabscore/evm_llvm/wiki/Stack-and-Memory-management#memory-stack

So in Pre-2315:

When we see a call:

  1. save current frame pointer on to stack
  2. push function arguments on to stack
  3. push return address (have to push func arguments first, because now, we can calculate the fixed return address very easily: current PC + 6)
  4. jump to subroutine

When we see a return:

  1. push return value on to stack
  2. do a SWAP1/2/3/... to bring return address to top of stack (this is automatically generated by stack allocator, value depends on how many values you are going to return)
  3. jump back to return address

You can see that it actually adds a lot of stack manipulations, and makes it a bit harder to debug.

What can we do when we have EIP2315:

a call to a function will be mapped to the following operations:

  1. save current frame pointer onto stack
  2. push function arguments onto stack
  3. jump to subroutine

And when we see a return instruction:

  1. push return values
  2. call RETURNSUB

Now we don't have to push the return address on to stack. this will reduce the number of arguments living on the stack, leading to less stack manipulation instructions, hence better performance.

Does it answer your question?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants