On Jun 26, 11:13 am, moja...@[EMAIL PROTECTED]
(Everett M.
Greene) wrote:
> "Mohan kumar" <mohankumar_be...@[EMAIL PROTECTED]
> writes:
> > Hi thanks for your reply,
>
> > the puzzling question that rocks my mind is why should they terminate
the
> > stack by subtracting 64 with the stack pointer(r1)
>
> > addi r1,r11,__stackstart_pt@[EMAIL PROTECTED]
> > addi r1,r11,__stackstart_pt@[EMAIL PROTECTED]
> > addi r0,r0,0
> > stwu r0,-64(r1)
>
> > 1. first two lines of code have defined the stack pointer(r1)
> > 2. third lines has cleared register r0.
>
> Are you certain of that? It appears to do nothing.
> ANDI r0,r0,0 would clear R0.
I'm not quite sure what the first line does that persists, but the
second line loads r1 with the sum of r11 (probably some base register)
and a constant displacement named "stackstart".
The third line clears r0 as you said
And the fourth line stores this value of 0 at -64 relative to the
value having something to do with "stackstart" that was loaded into
r1.
So yeah, I think it's initializing some part of the stack frame to
zero, probably the pointer to a non-existent previous stack frame.
Storing things at small constant offsets from the stack pointer is a
favorite habit of compilers... you see instructions to this effect all
the time, on all sorts of processors. Keeping track of those offsets
especially in relation to a stack pointer that may change during your
procedure is a royal pain to do when coding assembly by hand, but very
easy for a compiler.
|
