Interpretation of return address stack

[b little]

As it is stated in page 16 of riscv-specv-v2.2.pdf, return-address prediction stacks are used.

It states that for JAL will should push the return address onto the return-address stack when rd = x1/x5.

But does it mean to 

  1. push the old return address onto then stack, i.e. return address before the JAL instruction, the value of x1 before executing JAL

  2. push the new return address, i.e. the address of the next instruction after JAL?

Thank you.

[Bruce Hoult]

On Thu, Jul 12, 2018 at 5:34 AM, b little <ror...@gmail.com> wrote:

As it is stated in page 16 of riscv-specv-v2.2.pdf, return-address prediction stacks are used.

That's not really correct.

Some implementations might want to provide a return-address stack to improve performance, but others won't.

Either way, the program must produce the same results.

 

 

It states that for JAL will should push the return address onto the return-address stack when rd = x1/x5.

But does it mean to 

  1. push the old return address onto then stack, i.e. return address before the JAL instruction, the value of x1 before executing JAL

  2. push the new return address, i.e. the address of the next instruction after JAL?

It's only suggestions. You can do whatever you want -- whatever makes sense in your hardware. There is no way for software to examine the contents of the return address stack. (not directly -- you could do a spectre-style timing attack)

There is no definition for what should happen if the return-address stack gets full, or empty, or for what (if anything) you should do to recover if pushes and pops turn out to be mismatched. There is no definition that says whether x1 and x5 should use the same return-address stack or different ones ... can you call a function putting the return address into ra (x1) and then the function saves it to the stack, later restores it to x5, and returns using that? Well .. certainly it CAN, and that must *work* .. but is it *fast*? That's all up to you -- simulate on programs of your choice and see what works best.

So all of this is nothing more than a convention. Compilers can assume that *if* a return-address stack is implemented certain kinds of jumps will be interpreted as function calls and certain kinds as function returns. And people designing hardware can assume that if they see a jump instruction matching one of those patterns then the compiler did that on purpose.

Ok, so just as an example of how I"d think about it .... the purpose of a return-address stack (just as with branch prediction and branch target prediction) is to enable the instruction fetch unit to run ahead of the execution pipeline. You don't want to wait to see if a condition turns out to be true, and you don't want to wait to see what value will be in ra when the return instruction is actually executed. You want to have the necessary (hopefully correct) information right there, in the instruction fetch unit.

So, in this situation when you see an instruction that looks like a function return, you'd like to have the (probable) address to return to right there handy, in the return-address stack.

So ... when you see what looks like a function call ... you'd want to store the return address in both the return-address stack and in ra (x1 or x5), at the same time.

Even more .. think about your option 1. When you see a function call instruction, there is NO GUARANTEE about what is in ra before the new turn address is put there. It might still have the last function return address in it. And it might not. It's quite common for program code to use ra as temporary register while calculating what function to call e.g. when loading a function pointer or C++ virtual function. Saving whatever rubbish happens to be in ra just before the call is not useful.

[b little]

Yeah, that makes sense. I read it incorrectly. Thank you very much.

在 2018年7月12日星期四 UTC+1下午4:00:50，Bruce Hoult写道：