|Re: Seeking Some RPL Tutelage|
Message #6 Posted by James M. Prange (Michigan) on 13 June 2007, 6:25 p.m.,
in response to message #4 by Les Wright
Something that I think will be useful for anyone who writes
UserRPL source code in his favourite text editor.
James's comparative example should be more informative
once I get it on the calculator and see what it actually does.
For those who don't want to mess around with compiling the SysRPL
version, remember that the UserRPL version accomplishes the same
But it's pretty simple step-by-step stuff. No tests or conditional
execution, only one loop, a little stack manipulation, but no
I'm definitely not an expert at either SysRPL or Saturn assembly
language. Yes, I can use them, but I usually can't just sit down
and write a program in them without some reference material at
hand. Often I just want to check the spelling or which order the
arguments should be in, but then I notice another command that
might be better....
I have downloaded the Kalinowski/Dominik examples and will
experiment with them. I have also begun to crack the
I take it that you mean Programming in System RPL, Second
Edition, by Eduardo M Kalinowski and Carsten Dominik? I
don't think that anything better than that for learning SysRPL is
Also see RPLMan (it should be available from hpcalc.org). It was
written when the 48SX was the current model, so it's a bit out of
date, but other than adding some new object types and commands and
the entry points changing, the RPL language hasn't changed all
that much. What's in there still applies, although of course it
doesn't cover the newer additions.
For the development library (including compiler features and
syntax), see "Masd Documentation".
Note that a lot of the additions in the 49 series (including the
development library) came from the "Meta Kernel" (or "MetaKernel"
or "MK"), originally developed for the 48 series, so any
documentation for it might be helpful.
Debug4x may be useful to you, although other than the included
emulators being very useful, I've never much cared for it. But
many others think that it's great.
Also install the OT49Plus library (available from
Wolfgang's site) on
your 49g+ (or 50g); I think that it makes some of the development
library tools easier to use. Wolfgang is another SysRPL expert;
it's as if he could write excellent programs in his dreams. A
criticism is that in his programs, almost everything else, other
than actually working as intended, has a much lower priority than
program size. Wolfgang has taken a break from his RPL programming
hobby to work on his other interests, but his tools for the 49g+
should work on the 50g as well.
Look at and try to understand SysRPL programs that others have
written. Okay, very often the source code, let alone any
commenting, isn't published, but you can decompile an RPL program
with the \->S2 command (or OT49's Sys~ command).
The Nosy library is a very useful tool. It lets you
see the programs that make up the built-in commands and follow the
logic of how the ROM is written (what calls what and under which
condition). You might notice some cases where the ROM code could
be "improved" (made faster or smaller) easily enough, but changing
something might inadvertently move an entry point (thus breaking
anything that uses it), and "don't fix what ain't broken" isn't
such a bad policy.
For that matter, Nosy can also be used for investigating any other
Browse and search the comp.sys.hp48 usenet group. One problem is
that some of the discussions are among experts, so beginners may
well be baffled by those. But there are plenty of "beginner
questions" (and answers) too.
Try setting flag -85. This lets you see the stack (well, however
much of it is visible) decompiled to SysRPL syntax. Note that to
make much sense of a lot of it, extable will have to be installed.
That said, if you use anything else to view an object, you'll see
it in UserRPL syntax.
and so far I have one criticism--the
practicalities of compiling a program on the calculator are
relagated to an appendix, and it took some wading through lots of
info before I appreciated the need for extables and different
versions of SysRPL code. I was trying to compile the example
first.s from the Kalinowski example and got no where until I
stumbled across the stuff about extables. This basic stuff
would've been helpful right at the front of the book.
I think that part of the problem is that the authors are real
experts in SysRPL, and may find it rather difficult to remember
that beginners don't necessarily know all of the essential "basic
First scan through the document quickly to get an idea of how it's
organized and what information is available, then read it more
thoroughly, but just scanning through the command and built-in
ROM objects references, and finally use it as a reference for
A problem with trying to explain SysRPL is that there are so very
many commands, often combining what would typically be thought of
as two or more commands into one, many of which accomplish
almost the same thing. Basically, it seems that if
the system developers found something to be useful for developing
the operating systems, then they built it into the ROM, and if
they thought it to be particularly useful to 3rd-party developers,
then they made it a "supported" entry point. Sometimes a SysRPL
command is poorly named, but once a name is assigned, it tends to
stick; hey, it doesn't have to make sense to ordinary users, as
long as the developers know what it does. Anyway, there are
usually several perfectly good ways to accomplish something, and
what's "best" is very subjective.
"Unsupported" entry points may well change with any ROM revision,
so are best avoided. But Jean-Yves mentioned some ranges of entry
points that won't move, and these are the "unsupported but stable"
entry points that are probably okay to use. He isn't
employed by HP any more, but they haven't moved yet. But if HP
releases another series of RPL models, even the "supported" entry
points may move.
There are also certain RAM locations that, although perhaps not
"supported", still have the same purpose in the 50g as in the
48SX. I've found some of these useful for external I/O. By the
way, I had to look at things written with the 48SX in mind to find
out about some of these in the 49 series.
In trying to explain something to a real beginner, the difficult
question is "where to start"; what basic stuff that "everybody
knows" does he really need to know first? For trying to explain
something to someone who seems basically competent in the subject,
the questions become "what essential knowledge is he lacking for
this topic", along with "what does he already know and doesn't
need to be told".
You may have to slowly and painfully accumulate knowledge until it
reaches a "critical mass" for you and the learning curve suddenly
starts to level off and it becomes much easier to learn more.
That's a good point. These built-in ROM libraries aren't attached
by default, and executing 256 MENU and 257 MENU doesn't attach
them, but you can use the menu keys for operations even if the
libraries aren't attached; to use them for commands, the libraries
have to be attached. That is, if, with them detached, you press a
menu key, it works just fine, but if you use it to get the source
code into a program, you'll find that it's compiled as a name
instead of as a command. But if you compile a program with the
commands (with the libraries attached), the program still works
even with the libraries detached (as long as the program isn't
decompiled and recompiled from source code). To experiment with
this difference, just use 256 DETACH and 256 ATTACH.
Here is an interesting point--Kalinowski/Dominik claim that
Libraries 256 and 257 are not attached by default. In both my 49G+
and in a fresh instance of Emu48, I find that indeed they are--I
get to see proper softkey menus via 256 MENU and 257 MENU without
having to explicitly attach the libraries first via 256 ATTACH and
257 ATTACH. Perhaps calling the menus attaches the libraries
automatically? At any rate, I was tickled to find the compiler
right where the manual said it was.
But my guess is that you installed an extable library (which
happens to be a self-attaching library), which automatically
attaches libraries 256 and 257 as well. The same holds true for
OT49 and perhaps some others. If you find "Development Library" in
the list when you press the APPS key, then it's attached.
By the way, the library 257 commands are called by the library 256
commands. The usual recommendation is that you use the library 256
commands instead of using the library 257 commands directly.
Edited: 13 June 2007, 6:37 p.m.