Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

assembly return stack

10 views
Skip to first unread message

rs1n

unread,
Nov 9, 2009, 5:56:24 PM11/9/09
to
I have a quick question regarding the return stack. Consider the
following snippet of code (part of code from the decompression routine
in the compressor package called 'LZD'):

CODE
GOSBVL =SAVPTR
C=DAT1 A
RSTK=C
CD1EX
RSTK=C
A=DAT1 A
LC(5) =DOCSTR
?C=A A
GOYES +
GOSBVL =GETPTRLOOP
+
(more code here)
ENDCODE

My first question is: why there is a GOSBVL call instead of a GOVLNG?
Does it have to do something with things saved onto the return stack?
Right before GOSBVL =GETPTRLOOP there will be two addresses on the
return stack. When GETPTRLOOP is called, there will be an additional
address. However, GETPTRLOOP jumps with PC=(A). So what happens to
everything on the return stack? I guess what I am getting at is: what
happens with the address left on the return stack?

Andreas Möller

unread,
Nov 9, 2009, 6:23:04 PM11/9/09
to
Hello,

>         GOSBVL  =GETPTRLOOP

I am writing this from memory so that might not be 100% correct.

The RSTK level is used for the return. This does not matter here as
you will be exiting to RPL.
Instead you can always use
GOVLNG =GETPTRLOOP
in this case as this is slightly as faster as it does not use a RSTK
level.
I have never encountered any problems exiting with GOVLNG
=GETPTRLOOP.

HTH,
Andreas
http://www.software49g.gmxhome.de
http://www.youtube.com/watch?v=Pj72miclisM

Raymond Del Tondo

unread,
Nov 9, 2009, 6:34:30 PM11/9/09
to
IIRC the GOSBVL at the GETPTRLOOP
is simply a glitch, and the CPU return stack
will be cleared in the main loop.

I saw this (a GSB at an END stmt)
in some other code snippets,
and it had no effect on the general program run,
or in other words, the return address was never reached.


"rs1n" <> schrieb im Newsbeitrag
news:6f68a1df-b580-4436...@37g2000yqm.googlegroups.com...

Yann

unread,
Nov 9, 2009, 6:49:51 PM11/9/09
to
Indeed,
as the call to GETPTRLOOP does not expect to come back,
it *should* be GOVLNG.

So one question could be : why is it not so ?

Reason is that LZD is written using MASD syntax,
while the disassembled code is using SASM syntax.

MASD exit from an ML code is written : LOADRPL

Therefore, it is the compiler which decides to replace this codeword
with the sequence GOSBVL =GETPTRLOOP


It is the compiler which is making a small "mistake" here.
But as said by Andreas, this has very little importance,
because both conditions will anyway exit to RPL.
You can exit from anywhere within your ML code,
leaving the RSTK full of return addresses,
this will have no impact at all ! They simply are ignored.

Using GOSBVL therefore has no real disadvantage,
both cost 7 nibs (3.5 bytes),
speed difference is almost negligible
(GOSBVL is 15 cycles, while GOVLNG is 14 cycles)
so this is completely unnoticeable.

Regards

rs1n

unread,
Nov 10, 2009, 3:29:28 PM11/10/09
to
This makes a lot more sense now. It truly is rather clever how some of
the popular programs handle embedded code to temporarily jump back to
RPL, and then return to code (e.g. safe garbage collection).


On Nov 9, 5:23 pm, Andreas Möller <andreas_moellerNOS...@gmx.de>
wrote:

0 new messages