Date: Thu, 7 Mar 1991 09:11 CST
Subject: Re: Questions about internal RPL programming on the hp48
Organization: Digital Equipment Corporation
Lines: 72

Matthew  Austern asks:

>First, I don't understand what is meant by calling internal RPL code
>"threaded."  (Perhaps this just means I've never used forth.)
>

Well, from my understanding this terminology just implies that
the RPL program is not actual code, but rather a sequence of
addresses through which execution flows.  Imagine if you will
that the actual flow that the machine follows is a thread that
repeatedly passes through the fabric of the program.  Each RPL
instruction is like the point in the fabric where the thread
punches through.


>Second, I don't understand the difference between, for example,
>#1592D and #18AA5.  These are documented in Derek Nickel's
internals >list as, respectively, "Set last RPL token to <0h> and
verify DEPTH >= 1" >and "Save last RPL token and verify DEPTH >=
1".  I suppose my >problem is that I don't understand what is
meant here by "last RPL >token".

I have exchanged mail with Jan Brittenson on this point, and I
will give you my opinion, and explain how I came to that
opinion.

In the course of doing some system RPL proramming, I had need to
do argument checking, so I wanted to use the RPL instructions
that do this.  I had my choice between one that said "save last
RPL token" and one that said "set last RPL token to <0h>".  I
tried both.  There was a significant difference.

When I used the command that said "save last RPL token", I got a
strange XLIB number when the parameter check failed.  When I used
"set last RPL token to <0h>" the code which prints out the error
message did not attempt to display the XLIB that generated the
error.

In other words, did you ever wonder how the machine knows, when
you hit + with no arguments, that it should include "+" in the
error message to tell you what command (i.e. XLIB) generated the
error?  My guess is that the "last RPL token" is just a variable
somewhere into which is stored the ID of the most recent RPL
token.  When something goes wrong and an error message must be
displayed, the system will pull the saved ID out of this variable
and use it in the error message.  By using system RPL routines
that say "set last RPL token to <0h>", the system flags this
variable as containing bogus data, and that it should not be used
in error messages.  I have no idea what other things this "last
RPL token" variable may be used for.

Please keep in mind that this is just my guess based on my own
observations.  Oh, by the way, Bill Wickes uses the "set LAST RPL
token to <0h>" in his ASC routines.  That's why when you feed ASC
bad parameters, the error message makes no attempt to identify
ASC as the command that generated the error.


>Finally (and this is perhaps the only nontrivial question), does
>anybody know if there is a good way to use local non-stack
storage in
>an internal RPL program?  That is, is there a way to use local
>variables or the equivalent?

I'll leave this one to Jan Brittenson.  :-)

While we're at it, I have a question I've wanted to ask for a
while, but I keep forgetting.....

What does RPL stand for????

>>>Joe Ervin