Re: A89: Stupid Stack Operation Question: LONG
[Prev][Next][Index][Thread]
Re: A89: Stupid Stack Operation Question: LONG
Actually, you answered it just fine. It just took me a while to figure
out what you were saying. I found a good example of this explanation that
I include here for someone else who might not understand this.
ASSUME for the moment that A7 has $4000 (just as an example) stored
in it.
code fragment 1:
move.w _LCD_HEIGHT, -(a7) ; pushes height to stack $3FFE
sub.w #8, (a7)
move.w _LCD_WIDTH, -(a7) ; pushes width to stack $3FFC
sub.w #1, (a7)
move.w #0, -(a7) ; pushes 0 to stack $3FFA
move.w #0, -(a7) ; pushes 0 to stack $3FF8
jsr util::erase_rect ; pushes return address to stack $3FF4
add.l #8, a7 ; corrects this routines effect on SP
code fragment 2:
erase_rect:
move.l d0-d7/a0-a2, -(a7) ; pushes 44 bytes to stack $3FC8
bsr prep_rect ; pushes return address to stack $3FC4
; some other code here
move.l (a7)+, d0-d7/a0-a2 ; pops registers stack $3FF4
stack at this point:
$3FC4 return address ; to code fragment 2
$3FC8 d0-d7/a0-a2 ; from erase_rect
$3FF4 return address ; to code fragment 1
$3FF8 0
$3FFA 0
$3FFC _LCD_WIDTH
$3FFE _LCD_HEIGHT
$4000 original SP
code fragment 3:
; at this point a7 points to $3FC4
; uses the following instructions to access data
move.w $36(a7), d4 ; $3FC4 + $36 = $3FFC = 0
move.w $3A(a7), d5 ; $3FC4 + $3A = _LCD_HEIGHT
move.w $34(a7), d0 ; $3FC4 + $34 = $3FF8 = 0
move.w $38(a7), d1 ; $3FC4 + $38 = _LCD_WIDTH
; something
rts
Now WHEN code fragment 3 returns the SP is returned to $3FC8.
BEFORE code fragment 2 returns it pops registers returning SP to $3FF4
WHEN code fragment 2 returns it pops return address returning SP to $3FF8
Returning to the calling program with the original SP of $3FF8 and only
8 bytes to account for. Hence add.l #8, a7.
And we have the SP restored to the original value of $4000. Whew...
I think I've got it. It gets a little confusing keeping track of what the
stack contains and where the data is located within the stack but, if
that's the way it is done...
Thanks
On Thu, 14 Jan 1999, Nate Mueller wrote:
>
> >But, you did not answer my question. Sure you have access to all stack
> >data at all times. But usually one gets data as LIFO using some sort of
> >pop (which restores SP), like move.w (A7)+, D0.
> >
> >If I do: move.w D0, -(A7) ; pushes D0 onto stack
> > jsr myRoutine
> > ; some restoration here is only necessary if SP is same as
> > ; before jsr.
> >
> >Doesn't the myRoutine usually access the data with:
> > move.w (A7)+, D0 ; pops the Data and restores SP pointer.
> > ; do something
> > rts ; returns to calling program with original SP
> > ; restored.
> >
> >So, if it does work this way, the stack is already restored when the
> >return occurs. If fact if the SP is restored to it's original data and
> >I add something to that value, I have grown the stack unnecessarily.
> >
> >Now it altogether possible to access the data with something that does not
> >change the value of the SP. Like move.w #2(A7), D0. And further I'm not
> >sure that one should ever mix and match these two methods.
> >
> >Does TI use this latter method of accessing subroutine parameters? Is
> >that maybe why the SP is corrected. That is, access the parameters
> >without modifying the SP?
>
> I use the move.w #2(A7), D0 method for accessing parameters. With this I
> know that if I ever need to access them twice inside the same function it
> will still be there. Another possibility is that the function uses the
> stack to store stuff within the function. If the function will need to be
> reading and writing these values several times then the stack pointer would
> not be restored after every read, but at the end of the function.
>
> --Nate
>
> PS: If I still didn't answer your question, give a sample of code that has
> the problem.
>
----------------------------------------------------
Shoot-to-Win
Protect the 2nd Amendment
----------------------------------------------------
References: