Week 4 lecture - allocating space on stack

77 views
Skip to first unread message

Hou In (Ivan) Tam

unread,
Sep 27, 2020, 11:09:45 PM9/27/20
to cmpt-295-sfu
# Lecture Question
Week : 4
Slide deck name: L08-RISCV pg.34
Question:
Please correct me if I am wrong,
my understanding of function arguments is that the first eight arguments are stored in registers a0-a8.
The caller is responsible for loading up a0-a8.
And the callee can then use the values in them.
We do not need to use the stack unless there are more than eight arguments.

In this way,
why do we need to allocate space for a0 and a1 on the stack frame of test()? (as in pg. 34)
I thought they are passed in using registers a0 and a1, but not the stack.

Arrvindh Shriraman

unread,
Sep 28, 2020, 1:24:20 PM9/28/20
to cmpt-295-sfu


On Sunday, September 27, 2020 at 8:09:45 PM UTC-7, Hou In (Ivan) Tam wrote:
# Lecture Question
Week : 4
Slide deck name: L08-RISCV pg.34
Question:
Please correct me if I am wrong,
my understanding of function arguments is that the first eight arguments are stored in registers a0-a8.
The caller is responsible for loading up a0-a8.
And the callee can then use the values in them.
We do not need to use the stack unless there are more than eight arguments.

Yes; that is correct.
 

In this way,
why do we need to allocate space for a0 and a1 on the stack frame of test()? (as in pg. 34)
I thought they are passed in using registers a0 and a1, but not the stack.


Note that test is making a call to sum(). To pass the arguments to sum() test is going to overwrite the a registers.
When you return back from sum() and come back to test you will need to re-reference the arguments.

Rule : Anytime a function makes a call to another function or going to overwrite a0 or a1 when calculating the return value, you need to save a0 and a1. 

Two options: either save a0 and a1 to s registers OR at the point where you might be overwriting a0 and a1 e.g., just before the call to sum() save them on the stack. 

The stack is essentially serving as a temporary memory location to spill and restore the registers as you may have run out of registers






 

Hou In (Ivan) Tam

unread,
Sep 28, 2020, 4:38:23 PM9/28/20
to cmpt-295-sfu
Thank you for your reply.

Unfortunately, I am still confused about what we are doing on slide 34 (and slide 35)

On slide 34, I believe we are using s1 and s2 to save a0 and a1 (RED circle in the attached picture).
And I believe we have allocated space for saving s0 and s1 before changing them (such that we can restore them before returning to main()) (RED arrow)
In this case, why do we still need to allocate space for them on the stack? (RED square)
L08 Slide 34.png
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Similarly on slide 35, when we are passing arguments to sum(), I am not sure why we are storing a0-a7 on the stack.
(Are we assuming that sum() will call other functions and overwrite all a0-a7 ?)
L08 Slide 35.png

Arrvindh Shriraman

unread,
Sep 28, 2020, 5:21:08 PM9/28/20
to cmpt-295-sfu
You are correct in your understanding. IN THIS PROGRAM, there is no need to allocate space for the incoming arguments.

Slide 34: Note that the parent function e.g., main() is only allocating the space so that test can save the a registers if it wants to. It is not copying, it is just creating the space 
In this case, test() does not end up using that space.

Slide 35: Again test is allocating the space that sum can use for saving the a registers (if it wants to)
We are only allocating space for the incoming arguments


Hope this helps...

On Monday, September 28, 2020 at 1:38:23 PM UTC-7, Hou In (Ivan) Tam wrote:
Thank you for your reply.

Unfortunately, I am still confused about what we are doing on slide 34 (and slide 35)

On slide 34, I believe we are using s1 and s2 to save a0 and a1 (RED circle in the attached picture).
And I believe we have allocated space for saving s0 and s1 before changing them (such that we can restore them before returning to main()) (RED arrow)
In this case, why do we still need to allocate space for them on the stack? (RED square)
L08 Slide 34.png


After moving a0 to s0.
a0 is being used to hold the result tmp (look at the instruction MOVE a0,t0).

tmp is required for the second call to sum "u = sum(s,tmp.....), so a0 is going to be referenced there. 
After the first call to sum 

Hou In (Ivan) Tam

unread,
Sep 28, 2020, 5:48:56 PM9/28/20
to cmpt-295-sfu
Thank you for your reply, that really helped.

One last question:
Can we allocate space on the stack on the fly?
For example, if we want to save a register in the middle of a function, can we allocate space for that in the middle of the function?
(i.e. do a "ADDI sp sp -4" in the middle of a function)
I believe that is fine because we can use fp to restore sp before returning, am I correct?

Arrvindh Shriraman

unread,
Sep 28, 2020, 7:07:24 PM9/28/20
to cmpt-295-sfu
You can; however, this is dangerous

You will be better of restoring the sp right after you dont need the space. 
Cause otherwise at the epilogue point when you re-reference sp to restore ra and s registers, SP is not where it should be.

See example below:
Lets say hypothetically sp is at 100.
foo():
addi sp, sp, (-12). SP = 88
sw ra, 0 (sp)      (RA is saved at 88)
sw s0, 4 (sp)     (S0 is saved at 92)
sw s1, 8 (sp)     (S1 is saved at 96)


add sp,sp, (-4)   SP = 84
sw t0, 0 (sp)
....
lw t0,0(sp)
NOW LETS SAY YOU DONT DO THE addi sp,sp,4 

SP still at 84
Epilogue would have to be modified
lw ra, 4(sp)   ---- Offset relative to SP is now 4   
lw s0, 8(sp)
lw s1, 12 (sp)

You see that the offsets of the lw in epilogue no longer match the sw in the prologue. 
This is because SP moved in the middle and you did not remove during deallocation. 
Two solutions
- Either try avoid manipulating SP in the middle OR
- Always deallocate space  
add sp,sp,-4 # allocate
sw t0,0(sp)
Do Dangerous things
lw t0,0(sp)
addi sp,sp,4 a # Deallocate

Hou In (Ivan) Tam

unread,
Sep 28, 2020, 10:04:45 PM9/28/20
to cmpt-295-sfu
Thank you for the detailed response!
Reply all
Reply to author
Forward
0 new messages