General info on 48/49/50 ROM entry points

[grsbanks]

I do already have the list of entry points compiled by Joe Horn and yes, it is an invaluable compendium of information.

Being interested in getting up to speed with Saturn ASM programming I'm most interested in the entries that have the "ML" suffix and therefore "do" something instead of just being addresses of RPL objects.

Some I'm familiar with ("DBUG.TOUCHE", "ErrjmpC", "GETTEMP" etc.), some I can guess at their purpose. Others.... Is there any documentation anywhere that describes what the code at these entry points actually does and how to use it?

The Saturn processor was clearly designed with manipulation of real numbers encoded in 16 nibbles in mind. The field structure of its internal registers gives that away in no uncertain terms. Surely there must be a routine somewhere that, for example, takes a real number thusly encoded in A.W or C.W, Allocates 21 nibbles of memory with the required availability checks, fills the structure with the prologue and the data from the register and sends a pointer to the structure to the RPL stack, right? Or do we need to reinvent the wheel each time because HP didn't feel that something like that would be useful?

Both UserRPL and SysRPL operate on the stack. The big advantage of ASM over them is that you can avoid using the stack altogether except to pass parameters to your ASM routine and to return results, and therefore save time. Surely there must be an entry point somewhere for each of the basic mathematical operations that operates on data in the registers, right?

As I understand it, a lot of documentation for HP machines and the Saturn processor is in French rather than English. That doesn't bother me, I'm bilingual anyway (j'ai passé presque la moitié de ma vie en France) I'd just like to sink my teeth into something that does a bit more than scratch the surface of what's in these machines.

[pier4r]

(12-30-2017 11:51 AM)grsbanks Wrote:  As I understand it, a lot of documentation for HP machines and the Saturn processor is in French rather than English.

Thanks for the interesting post, anyway the bit quote above is interesting as well. Why is it in french? Was the Saturn CPU developed in France? Even so, was it only for the internal market? (otherwise a company would try to be as international as possible for its products)

[grsbanks]

(12-30-2017 11:55 AM)pier4r Wrote:  Thanks for the interesting post, anyway the bit quote above is interesting as well. Why is it in french? Was the Saturn CPU developed in France? Even so, was it only for the internal market? (otherwise a company would try to be as international as possible for its products)

I honestly don't know why this should be the case. All I do know is that the seminal documentation of the 48G/GX, for example, is in French in the form of the excellent book, "Voyage au Centre de la HP-48G/GX" by Paul Courbis. Back in the day I also had a hard copy of the equivalent book for the HP-28C/S. See http://www.courbis.fr. Let's not forget HP's own Cyrille de Brébisson and Bernard Parisse, who are native French speakers and who may have had some influence in the direction that things took.

[Joe Horn]

There is no book which covers ALL the entry points, because there are so many, but Jim Donnelly's book called "An Introduction to HP 48 System RPL and Assembly Language Programming" covers most of the important ones. It's available for free download as a PDF file in US Letter format and in European A4 format. Many thanks to Jim Donnelly for giving his permission for it to be freely available, and to Eric Rechlin for making the PDF versions from scratch since the original electronic copy was lost.

[Raymond Del Tondo]

(12-30-2017 11:51 AM)grsbanks Wrote:  As I understand it, a lot of documentation for HP machines and the Saturn processor is in French rather than English. That doesn't bother me, I'm bilingual anyway (j'ai passé presque la moitié de ma vie en France) I'd just like to sink my teeth into something that does a bit more than scratch the surface of what's in these machines.

Have you checked the ML documentation on http://www.hpcalc.org ?

[Gerald H]

(12-30-2017 01:08 PM)Joe Horn Wrote:  There is no book which covers ALL the entry points, because there are so many, but Jim Donnelly's book called "An Introduction to HP 48 System RPL and Assembly Language Programming" covers most of the important ones. It's available for free download as a PDF file in US Letter format and in European A4 format. Many thanks to Jim Donnelly for giving his permission for it to be freely available, and to Eric Rechlin for making the PDF versions from scratch since the original electronic copy was lost.

Wonderful book, I have 2 copies, one worn & one new, too valuable to use, made my own scan donkey's years ago & used the print from that scan to work with.

A benign act to make the work freely available.

[rprosperi]

(12-30-2017 01:28 PM)Raymond Del Tondo Wrote:  Have you checked the ML documentation on http://www.hpcalc.org ?

In particular, check out "Programming in System RPL", which although obviously aimed at SysRPL rather than ML, is a huge (640 pages) reference for 48/49/50 Entry Points, almost certainly the largest such document.

[DavidM]

(12-30-2017 11:51 AM)grsbanks Wrote:  Both UserRPL and SysRPL operate on the stack. The big advantage of ASM over them is that you can avoid using the stack altogether except to pass parameters to your ASM routine and to return results, and therefore save time. Surely there must be an entry point somewhere for each of the basic mathematical operations that operates on data in the registers, right?

One document that I often refer to for Saturn coding information on the 50g is this one. While by no means complete, it does provide many useful entries that can at least give you a starting point for experimentation. In particular, note sections 8.4 (Long Reals) and 8.10 (Popping and Pushing).

Keep in mind that most internal numerical functions (as opposed to symbolic) are written for extended reals instead of standard reals. Several of the SysRPL standard-precision real functions that I've traced begin by first converting the arguments to extended form so that the extended real functions can then be called for them. Intermediate results are then converted back to standard reals at the end of processing. I suspect that most work that same way.

There are undoubtedly internal routines to perform basic math functions with register-based extended reals (each extended real requires two registers). I'd bet that most of those routines are unsupported, though. Using Nosy (or similar apps) allows you to step through the built-in code to find some of these gems, but using them always comes with the risk of making your code specific to the firmware version you currently have installed.

[grsbanks]

Thanks to everyone for the pointers. I have some good reading material to keep me going for a while now

[grsbanks]

(12-30-2017 04:52 PM)DavidM Wrote:  Keep in mind that most internal numerical functions (as opposed to symbolic) are written for extended reals instead of standard reals.

This is an interesting point. I'll run some benchmarks on this to see if there's a significant difference in execution times between working with standard reals throughout on the one hand and working with extended reals but converting to/from standard reals when needed.

Point taken about stepping though the code to find the base ML routine.

[DavidM]

(12-31-2017 01:38 PM)grsbanks Wrote:  

(12-30-2017 04:52 PM)DavidM Wrote:  Keep in mind that most internal numerical functions (as opposed to symbolic) are written for extended reals instead of standard reals.

This is an interesting point. I'll run some benchmarks on this to see if there's a significant difference in execution times between working with standard reals throughout on the one hand and working with extended reals but converting to/from standard reals when needed.

I haven't compared the results in a while, but I seem to recall that there isn't a significant difference in the speed of many standard vs. extended numerical functions. I'd guess this is due to the fact that the conversions to/from extended are relatively quick when compared to the actual processing of the numerical function itself, which is the same code in both cases. My guess is that you'll find a "pure extended" approach only very slightly faster than a "pure standard" one. It may also depend on the specific functions that you test, since the conversion time as a percentage of total time would be larger for the faster commands (eg. +/- vs. TAN/SIN).

The upside to this is that there's usually no performance penalty for using the extended real functions in SysRPL programs. You just have to remember to do the conversions. While an extended real on the stack simply looks like a longer-than-normal real in scientific notation, there's not much you can do with them outside of a custom program (or specific SYSEVALs).

[grsbanks]

(01-01-2018 03:57 PM)DavidM Wrote:  I haven't compared the results in a while, but I seem to recall that there isn't a significant difference in the speed of many standard vs. extended numerical functions.

Just to test this very quickly I ran 2000 multiplications of two standard reals in one program and two extended reals in another.

There's a 10% or so difference in speed, so nothing huge.

I think that most of the time is used up by stack manipulation here. What I should do is try with something more complex than multiplication. Involve some trig and/or logarithmic functions.

[DavidM]

(01-01-2018 04:10 PM)grsbanks Wrote:  Just to test this very quickly I ran 2000 multiplications of two standard reals in one program and two extended reals in another.

There's a 10% or so difference in speed, so nothing huge.

I think that most of the time is used up by stack manipulation here. What I should do is try with something more complex than multiplication. Involve some trig and/or logarithmic functions.

Stack manipulation (especially in SysRPL) is very fast. A short loop using %+ and %SQRT vs. %%+ and %%SQRT gave the following results:

%+: 2.74047851562
%%+: 2.02880859375
(5000 iterations, %+ was 35% slower than %%+)

%+ %SQRT: 7.46215820312
%%+ %%SQRT: 6.84362792969
(3000 iterations, %+ %SQRT was 9% slower than %%+ %%SQRT)

Here's the code I ran:

Code:

::
   CK0NOLASTWD

   GARBAGE
   %1
   %0
   SysTime UNROT
   5000 ZERO_DO (DO)
      OVER %+
   LOOP
   SysTime
   UNROT2DROP SWAP
   bit- HXS>% % 8192 %/
   "%+" >TAG

   GARBAGE
   %%1
   %%0
   SysTime UNROT
   5000 ZERO_DO (DO)
      OVER %%+
   LOOP
   SysTime
   UNROT2DROP SWAP
   bit- HXS>% % 8192 %/
   "%%+" >TAG

   GARBAGE
   %1
   %0
   SysTime UNROT
   3000 ZERO_DO (DO)
      OVER %+ %SQRT
   LOOP
   SysTime
   UNROT2DROP SWAP
   bit- HXS>% % 8192 %/
   "%+ %SQRT" >TAG

   GARBAGE
   %%1
   %%0
   SysTime UNROT
   3000 ZERO_DO (DO)
      OVER %%+ %%SQRT
   LOOP
   SysTime
   UNROT2DROP SWAP
   bit- HXS>% % 8192 %/
   "%%+ %%SQRT" >TAG
;

[grsbanks]

Thanks for running those tests. My own tests confirm your findings.

Good idea to do a garbage collection before starting the loop, I didn't think of that.