[comp.sys.handhelds] Questions about internal RPL programming on the hp48

matt@physics16.berkeley.edu (Matt Austern) (03/07/91)

I've just started trying to write programs in machine language and
internal RPL, and there are a few (probably very basic) points that I
have questions on.  Would someone out there like to enlighten me?

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

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".

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?

Thanks to everyone who has posted their findings about hp48 internals;
this information has been extremely useful.
--
Matthew Austern                   Just keep yelling until you attract a
(415) 644-2618                    crowd, then a constituency, a movement, a
austern@lbl.bitnet                faction, an army!  If you don't have any
austern@physics.berkeley.edu      solutions, become a part of the problem!

ervin@pinbot.enet.dec.com (Joseph James Ervin) (03/07/91)

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

frechett@spot.Colorado.EDU (-=Runaway Daemon=-) (03/07/91)

In article <895@sousa.enet.dec.com> ervin@pinbot.enet.dec.com (Joseph James Ervin) writes:
>What does RPL stand for????

Reverse Polish Logic.

	ian

-=Runaway Daemon=-

bgribble@jarthur.Claremont.EDU (Bill Gribble) (03/07/91)

In article <1991Mar6.222246.16952@csn.org> frechett@spot.Colorado.EDU (-=Runaway Daemon=-) writes:
>In article <895@sousa.enet.dec.com> ervin@pinbot.enet.dec.com (Joseph James Ervin) writes:
>>What does RPL stand for????
>Reverse Polish Logic.

Actually, I thought it was Reverse Polish LISP.  Makes a lot of sense 
  if you've ever programmed LISP, 'cause RPL is pretty much the same.

>	ian

*****************************************************************************
**   Bill Gribble                     Harvey Mudd College, Claremont, CA   **
**   bgribble@jarthur.claremont.edu   Never heard of it?  You're stupid.   **
*****************************************************************************

d7matsa@dtek.chalmers.se (Mats Ackberger) (03/07/91)

>In article <1991Mar6.222246.16952@csn.org> frechett@spot.Colorado.EDU (-=Runaway Daemon=-) writes:
>>In article <895@sousa.enet.dec.com> ervin@pinbot.enet.dec.com (Joseph James Ervin) writes:
>>>What does RPL stand for????
>>Reverse Polish Logic.

>Actually, I thought it was Reverse Polish LISP.  Makes a lot of sense 
>  if you've ever programmed LISP, 'cause RPL is pretty much the same.

>>	ian

According to Hewlett Packard Journal, December 1987;
RPL stands for "ROM-based Procedural Language".

	Mats

Mats Ackberger				  |     /|   /|    /| ------  ---
Chalmers University of Technology	  |    / |  / |   / |   /    /__
NET:   d7matsa@dtek.chalmers.se		  |   /  | /  |  /--|  /        /
VOICE: +46 31 500700 (work)		  |  /   |/   | /   | /     ___/  
       +46 303 96638 (home)		  |
SNAIL: Box 126, S-43402 Kungsbacka,SWEDEN |

jpser@cup.portal.com (John Paul Serafin) (03/08/91)

It *IS* Reverse Polish Lisp, but you would never guess that from Official
HP publications which call it "ROM based Procedural Language"

feustel@netcom.COM (David Feustel) (03/10/91)

I'm brandnew to the group and know nothing about internal RPL
programming of the 48 other than that it apparently is possible. How
can I get the documentation so I too can program my 48 in internal RPL
and/or assembly language? Thanks.
-- 
David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631
EMAIL: netcom.com

billw@hpcvra.cv.hp.com. (William C Wickes) (03/12/91)

RPL stands for Reverse Polish Lisp.  In the early days of RPL development,
we got tired of calling the unnamed system "the new system," and one
of the development team came up with "RPL," both as a play on "RPN" which
has been the loved/hated hallmark of HP calcs forever, and as an accurate
indication of the derivation of the language from Forth and Lisp.

RPL was never particularly intended to be a public term; at the time of
the HP Journal article (August 1987) on the HP 28C there was an attempt
to create a less whimsical name--hence "ROM-based procedural language,"
which preserved the initials but had a more dignified sound.  The development
team never calls it anything but (the initials) RPL.  You can choose
either of the two full-word versions that you prefer.  Or how about
"Rich People's Language?"

Bill Wickes
HP Corvallis

peraino@gmuvax.gmu.edu (03/13/91)

>It *IS* Reverse Polish Lisp, but you would never guess that from Official
>HP publications which call it "ROM based Procedural Language"

     Actually, I have an HP publication buried somewhere, which came out
when the 28c was released, and they really did call it reverse
polish lisp.

peraino@gmuvax.gmu.edu

jpser@cup.portal.com (John Paul Serafin) (03/14/91)

>>It *IS* Reverse Polish Lisp, but you would never guess that from Official
>>HP publications which call it "ROM based Procedural Language"
>>
>     Actually, I have an HP publication buried somewhere, which came out
>when the 28c was released, and they really did call it reverse
>polish lisp.
>
>peraino@gmuvax.gmu.edu
Please dig it up!   Especially in light of Bill Wickes recent posting.
John Serafin
jpser@cup.portal.com

akcs.kevin@hpcvbbs.UUCP (Kevin Jessup) (03/16/91)

In the "Hewlett-Packard Journal" dated August, 1987, Charles Patton
described RPL as "ROM-based procedural language".  Was there a
publication prior to this that described it otherwise?

By-the-way, the August 198 issue of the HP Journal was devoted entirely
to the hardware and software of the HP28 and HP18C calculators.  It
was very informative.

Sorry HP, I guess you will now be swamped with backorders!