DB48X: HP48-like RPL implementation for DM42

[c3d]

(09-27-2024 01:53 PM)M0R33z Wrote:  Is it possible to program the DB48x in SystemRPL ? It just crossed my mind while I'm sitting here at work :-)

I have some bad news followed by some good news.

The bad news: no. SystemRPL is a way to directly invoke entry points in the ROM of a given model. Since DB48X is a completely new implementation of RPL, there is no way to provide meaningfully compatible SystemRPL without having users download an HP ROM.

More annoyingly, going that route would have precluded many of the innovations that make DB48X interesting, such as ultra-dense object format, variable-precision decimals, true fractions, phasors (complex numbers in polar form), exact angle conversions, and many more. All these require a complete "rethinking" of low-level details such as the internal representation of RPL objects. Some of this is explained in my FOSDEM 2023 presentation.

Just to give an very simple example, SystemRPL makes relatively heavy use of "binary integer" values. #03FF9 will represent binary integer 1. This uses 2.5 bytes. A "normal" binary integer uses 5 bytes. The binary integer values are 20 bits, which matches the A (address, 5 nibbles) field of Saturn processor registers. All this is "nonsensical" on a 32-bit CPU like the ARM chips in the DM32/DM42. To leverage years of development, HP implemented a full Saturn emulator on their ARM chips just to be able to reuse code that was essentially 4-bit oriented. This is how you end up with 2.5 bytes for object sizes.

DB48X takes the approach that integers are first-class citizen, so while there are true binary integers, you can use them directly in computations. The encoding for 19 is (in current versions) 1F 13, it's only two bytes. You can use the BYTES command to see what the encoding looks like. This makes all the knowledge about SystemRPL names such as NINETEEN a bit irrelevant. You add these binary integers with normal +, not some special #+. This means that you pay the extra cost of type checking, but then this also means that 1 1+3i + gives you 2+3i, and that this is also coded using binary integers, 11 1F 02 1F 03. So now you have a complex number in 5 bytes, the same space that HP's SystemRPL would use to encode a regular binary integer.

In short, SystemRPL is much less necessary with DB48X.

This leads me to the good news.

The good news: SystemRPL was initially a way to code the HP ROM in a dense way. DB48X is fully open source, and written in quasi-normal C++. I say "quasi-normal" because it requires a bit of discipline to enable garbage collection and dense object representation in C++. In any case, if you need to write something "system level" that you would like to add to DB48X, you can. If you want that code to invoke any internal routine in DB48X, you can. If you want to code something in ARM assembly language, you can (I have not needed that so far, but it's definitely possible). If you want to have the compiler sweat a little to turn a C++ expression into an equivalent RPL program, you can. In short, you can do the kind of system-level programming that you could not even dream of on HP calculators.

SystemRPL as used by non-HP programmers (i.e. those not using it to actually write the ROMs) was also a way to leverage a vast catalog of preexisting small utilities. Here too, I have some good news: DB48X has a library system that, in the very next release, will become even more useful, by allowing you to have individual library entries in their own source file. Let me illustrate how that can replace SystemRPL.

Say that you need #4+PICK. The RPL code for that is "4 + PICK". First, let me remind you that the actual encoding of that code in today's DB48X is 1F043E34. So that's 4 bytes, which means that the saving compared to the 2.5 bytes is not that great. But let's imagine you really want that new word. Now, add this entry to your library.csv:

Code:


"SysRPL"
        "Add4Pick",     "« 4 + Pick »"

Now, your Library menu has a "SysRPL" submenu, which features a new "word" called Add4Pick. The exact encoding of that object will depend on your library, but on my machine today, it encodes as 0D 19. So now that's two bytes, a 20% reduction in memory usage relative to classical RPL.

Ah, but you might object that SystemRPL was also a way to cross-build for HP calculators using HP tools. By the way, you probably do not know that, but in the 1990s, I had created an alternative to the official HP tools called HPDS (I did not even know at the time that the HP tools existed). This is what I used for example to create my Lemmings game. End of the digression.

To that objection about cross-building, I would answer that you don't even need such cross-building tools with DB48X. A nice thing about the library approach I just mentioned is that it's "live": connect your DM32/DM42, edit the library.csv file, and you immediately update the programs in the library. If you write your programs using the emulator, you can have your favorite text editor, Emacs, on the side, edit your library objects, and test them in the simulator without even restarting it.

In the current release, what you could put in the library was limited, because you had to have small-enough objects to fit in a CSV file. That was a bit inconvenient. On the dev branch, and in the release I plan to release this week-end, this problem is fixed by letting you put the objects in their own file. You do that by having the definition of the object begin with =. If there is only an = sign in the definition, then the name of the library entry is also the name of the file in the library subdirectory.

I have converted the various demos that shipped with previous releases to this format. For example, the program illustrating the benefits of the tail recursion optimization in DB48X using the Collatz conjecture looks like this:

Code:


«
    @ --------------------------------------------------------------------
    @
    @ Collatz conjecture check - Check tail recursion in a test
    @
    @ --------------------------------------------------------------------
    @ Interesting values to start with:
    @ - Long stopping time: 1161, 2223, 2463, 2919, 3711, 6171
    @ - High trajectory value: 138367, 159487, 270271, 665215, 704511
    @ See https://en.wikipedia.org/wiki/Collatz_conjecture

    DUP "      " + 1 DISP MEM 2 DISP

    IF DUP 1 ≠ THEN
        IF DUP 2 MOD THEN
            3 * 1 +
        ELSE
            2 /
        END
        ⓁCollatzConjecture
    END
»

The library configuration file shows how this is made available to the user via the Library menu:

Code:


"Mathematics"
    "CollatzBenchmark",    "="
    "CollatzConjecture",    "="
        "CountPrimes",          "="
        "TriangleEquations",    "="