RPL (long) Message #18 Posted by James M. Prange (Michigan) on 11 June 2007, 2:11 a.m., in response to message #14 by Ron Allen
Certainly UserRPL isn't "Classic RPN" as implemented in other HP
RPN models, but with the exception of program structures, UserRPL
is quite consistent in following the RPN (Reverse Polish Notation)
model, that is, any arguments first, followed by the operator;
it's a strictly postfix notation. I'd say that UserRPL
is an implementation of RPN, although not the same as
Classic RPN.
As a logical/mathematical notation, RPN doesn't impose any
inherent limit on the number of arguments waiting to be operated
on. Classic RPN has the limitation of 4 stack registers, plus
other registers which can be copied to or from the stack. For the
UserRPL models, the only limit to the number of stack levels is
the amount of available memory, so in this respect, I'd say that
RPL comes closer to being truly RPN than Classic RPN does.
For the RPL models, assuming that vectored ENTER isn't in effect,
when ENTER (or a key that invokes an implicit ENTER) is pressed,
source code keyed into the command line editor is parsed, and,
assuming valid syntax, compiled and combined into a secondary
(SysRPL program), which is placed on the stack and executed. For
source code "quoted" between UserRPL program delimiters, the
evaluation of the delimiters and their contents is to a program
object.
The contents of the command line amount to the source code for the
contents of a program waiting to be parsed, compiled, and
executed, and the contents of a UserRPL program could be
considered the compiled unevaluated equivalent of a valid command
line.
Note that an ENTER operation always compiles the command line's
(or other editor's) source code to some type of RPL object. The
"stack" is really a stack of pointers to objects elsewhere in
memory, and the "objects" that you see on the stack are really
decompiled character string versions of the objects pointed to.
For the stack display, this decompilation and the display update
takes place only just before the system is ready to accept
keyboard input, not while a program is running.
Similarly, editing, the \->STR command, transferring in "ASCII"
("Text") mode, or printing decompiles the object to a character
string (source code) equivalent, and in the case of transfers or
printing "via wire", optionally with non-ASCII codes "translated"
to pure ASCII sequences.
This compiling explains why all formatting ("white space" and
line-breaks) and commenting is lost as soon as you press ENTER. If
you want to preserve your formatting and comments, then either
write your source code within a character string or else write it
on your PC and transfer it to the calculator.
Note that for the RPL models, when in the "standard stack display"
(no command line or other "special environment" active), pressing
the ENTER key does not invoke an ENTER operation;
it's simply a "keyboard shortcut" that invokes a DUP command.
The UserRPL commands are actually special cases of named SysRPL
programs that include argument checking intended to prevent the
user from doing anything that would corrupt user memory. SysRPL
commands are unnamed on the calculator itself (unless a special
library is installed), and SysRPL commands are actually SysRPL (or
in some cases, machine language) programs that, in most cases,
contain other SysRPL commands and often have embedded machine
language code. Of course, ultimately, it's machine language code
that ends up being executed. If you want to investigate, then I
recommend a library named "Nosy", available from hpcalc.org.
For all RPL models, the ordinary user does have access to SysRPL
objects numerically by the use of the UserRPL commands SYSEVAL,
LIBEVAL (48G and newer only), and FLASHEVAL (49G and newer only).
Care must indeed be used with these commands. For example, SYSEVAL
does check that it has a user binary integer for its argument, but
other than that, it doesn't do any argument checking; it simply
causes execution to jump to that address, whether it makes any
sense to do so or not, and misuse of these commands may very well
cause memory corruption. Also note that "unsupported" entry points
may well change with different ROM revisions, and even "supported"
entry points often change with a different series of models (48S,
48G, or 49). If you want to use one of these operations
frequently, then I'd suggest that you write a small named program
that first checks for the required arguments, followed by the
numeric argument and the SYSEVAL, LIBEVAL, or FLASHEVAL command,
and then execute the program by name. If you want to embed one of
these commands within a UserRPL program, then make sure that the
program will definitely ensure that any required arguments for the
sequence are available on the stack first.
For the 48 series, HP provided tools for writing SysRPL and Saturn
assembly language programs on a PC, and 3rd-party external
libraries were developed to do this on the calculators themselves.
For the 49 series, a SysRPL/assembly language compiler (MASD, or
the "Development Library"), including assembly language mnemonic
keywords, is built-in, although "out-of-the-box", only numeric
SysRPL codes can be used. To use mnemonic SysRPL keywords with the
"Development Library", an extable library has to be installed.
For the ARM-based models (49g+, 48gII, and 50g), the Saturn
processor is emulated, but note that the emulated Saturn processor
has additional (apparently "unsupported", but, I hope, stable)
machine language opcodes and, for the Development Library, their
matching assembly language mnemonic keywords, and it's often
referred to as the "Saturnator" or the "Saturn+ processor".
SysRPL and assembly language programming are intended for
"developers", not for "ordinary users". In general, the results of
a mistake are often dire enough that most of us (Wolfgang and
perhaps a few others are exceptional) shouldn't attempt to use
them for ad hoc programs where development time is an important
consideration. That said, with the 49 series, (or a 48 series with
a RAM card installed), archiving and restoring all of user memory
(which may very well be corrupted in case of a mistake) isn't very
difficult, and the compiler is built-in on the 49 series with an
extable library easily installed, so it isn't unreasonable for an
"advanced" user who's willing to take the time to learn how to do
so to write his own "development language" programs.
The advantages of SysRPL programming are, first, that there are a
lot more commands available than with UserRPL, and second, most
SysRPL commands don't spend any time doing argument checking. Of
course, the disadvantages are that the lack of argument checking
means that the developer has to be more careful, there's a lot
more that can be learnt (much of which is "an exercise for the
student"), and with so many more ways to accomplish the same
thing, choosing which way to do it may be more difficult.
The advantages of assembly language programming are that you can
do things in it that would be difficult or impossible in RPL, and
a well-written assembly language program should be faster than an
RPL program that accomplishes the same thing. A disadvantage is
that it often takes several assembly language commands to
accomplish what could be done with just one RPL command, so
assembly language programs are typically larger. Of course, a
mistake in an assembly language program can be just as disastrous
as in a SysRPL program.
Note that assembly language (or machine language) code sections
can be embedded within SysRPL code.
With the ARM-based models, it's possible to access the underlying
ARM processor, and indeed HPGCC has been developed for using C++
code with these calculators. That said, I've never experimented
with this.
Of course the 49 series also have an ALG mode, and programming in
this mode seems to be what HP means by "hp basic" in regards to
these models. Note that this "hp basic" is not related to BASIC
(Beginner's All-purpose Symbolic Instruction Code). The only thing
that I've bothered to figure out how to do in ALG mode is
switching to RPN mode; if I'd wanted an algebraic model, then I
would've bought a "Brand X" model.
SysRPL is also the underlying "development language" for many of
the algebraic-only models that use the Saturn processor,
beginning with the 18C. In some cases it's possible to write and
compile a SysRPL / assembly language program and transfer it to an
algebraic-only model. I don't have any of the algebraic-only
models, and I have no personal experience with this.
The comp.sys.hp48 usenet group certainly seems a better place to
discuss the RPL models; many RPL experts frequent that newsgroup
and are generally very helpful, although of course it's best to
"do your homework" and try to avoid repeating the "Frequently
Asked Questions". I prefer to participate in that newsgroup by
using Thunderbird with my ISP's news server, but it can also be
accessed through
http://groups.google.com/group/comp.sys.hp48/. The entire
newsgroup archive, all the way back to 1991, can be searched from
http://groups.google.com/advanced_search? (which also works
for any "Google Group" or any usenet group that Google has
archived).
The current HP Museum CD-ROM set / DVD-ROM includes lot of
information about the RPL models, including documentation for the
48SX Equation Library card, which is useful for using the Equation
and Periodic Table libraries on the current models. I particularly
recommend the books by William C. Wickes. See
http://www.hpmuseum.org/cd/cddesc.htm.
Certainly any 49g+/50g user should have the 48gII/49g+ Advanced
User's Reference Manual, available from HP's site.
Note that a version of the current 49g+/50g "ROM" without the
optimizations for running faster on an ARM-based model is included
with Debug4x. With minor tweaks to a copy of a 49G .KML file, this
can be used with the 49G emulator and transferred to a real 49G
with the ROMUPLOAD command. Except for the execution speed and
hardware-dependent operations (including Saturnator-only opcodes
and accessing the ARM processor), you can make the 49G behave very
nearly the same as the 49g+ and 50g, with the latest ROM revision.
Note that emulators for the 48GX and all 49 series models are
included with Debug4x, but also note that it's the "Hardware
Saturn" that's emulated, not the ARM processor with a
"Saturnator". See http://www.debug4x.com/.
Alternatively, a 3rd-party Version G Revision #2.10-7 ROM, with
some bug fixes and additional capabilities, can be found at
http://www-fourier.ujf-grenoble.fr/~parisse/english.html (or
http://www-fourier.ujf-grenoble.fr/~parisse/francais.html if
you read French). This version includes the Equation and Periodic
Table libraries for the 49 series. Information on the 49 series
CAS can also be found from there.
The most recent Equation and Periodic Table libraries for the 49
series can also be found from
http://www.hydrix.com/Download/Hp/.
Of course, any RPL user should be familiar with
http://www.hpcalc.org/.
"Training modules" for the 50g are available at
http://h20331.www2.hp.com/hpsub/cache/383680-0-0-225-121.html.
Other useful on-line resources for RPL models include
http://membres.lycos.fr/ekalin/,
http://hp.giesselink.com/,
http://staff.science.uva.nl/~dominik/hpcalc/,
http://page.mi.fu-berlin.de/raut/,
http://holyjoe.net/hobbies.htm (also
http://holyjoe.net/hp/tiotable.png,
http://holyjoe.net/hp/types4.htm, and perhaps various other
files at http://holyjoe.net/hp/),
http://alaska.magpage.com/~jakes/, and
http://m.webring.com/hub?ring=hp48.
Each new RPL implementation is mostly a superset of the previous
implementation, and the documentation for earlier models is often
better, so don't ignore something just because it's written for a
different model; it may well apply to your model as well.
Take anything that you read with a grain of salt. If you want to
know how someone else (including an HP technical writer) thinks
something works, then read whatever information is available about
it; if you want to know for certain how it works, then experiment
for yourself.
Regards, James
|