Which calculators run RPL under the hood?

[Jonathan Busby]

(12-09-2019 06:48 AM)cyrille de brébisson Wrote:  - Rpl is great as it allows manipulation of "objects"... But it still lakes some stuff, like the ability to define new object types, which is sad...

Well, RPL actually *does* support the creation of new objects, in a round-about fashion Note that since you're an experienced HP Saturn assembler programmer, don't take my explanation of how it's accomplished as patronizing or anything as I'm speaking to a more general audience ( You most likely know everything that I'm about to say )

Take the HP48G/GX for example. If one only allows for indirect execution then one can use a fixed address in a library in port 0 for the address of the object prolog's indirect execution code. If one wants to fully support direct execution and =SKIPOB so that the object can be used by the RPL OS, then one still needs a fixed address in port 0. In this case though, the object prolog must contain the =PRLG "nop" at its start and two 5-nibble pointers to the object's direct execution code and its =SKIPOB code, respectively, starting 10 nibbles behind the object's prolog code. This should fully enable one to define custom object types that do essentially anything one desires

Regards,

Jonathan

EDIT #1 : Note that upon library initialization, the library must add its starting address in port 0 to the CON(5) offsets that are part of the object's prolog and recalculate the library's CRC. If one doesn't correct the address as described then expect a TTRM

EDIT #2 : As they say "The Devil is in the details" even for an atheist like myself . In the general case of defining custom objects inside a library in port 0, because the =PRLG routine uses the B field when subtracting to determine the direct execution address, then all of the object prolog addresses in the library need to fall within a 256*n + 10 ... ( 256*(n + 1) - ε ) range, where ε is the minimum size of a control transfer instruction. Also, the library needs to contain a 256 nibble padding at the beginning or end of the object prolog sequence, so that the addresses can be adjusted to fit the aforementioned criteria when the library's address changes. As for programs that use the library's custom objects, there are many ways to solve the problem of changing object prolog addresses when the library's address changes. One could use a software "guard" mechanism in which code that intends to use the libraries custom objects calls, a say, "INIT" routine which causes the library to check if its address has been changed, and, if it has, then the library will need to adjust the block of objects prologs and re-compute its CRC. As for storing custom object prologs, that's were it gets kind of hairy One could use a type of "loader" which scans an object sequence, and, assuming now that the custom object prolog addresses have been mapped to their number within the prolog sequence, the loader would adjust the object prolog addresses to the correct ones. All of this is to guard against object prolog address changes that occur from installing, and purging libraries and backup objects. A possibly easier way would be to set the port 0 EOS marker and pointer to end port 0 just before the custom object library starts. You'd have a slight "memory leak", so you'd need another user visible library in order to purge the "hidden" library. Anyways, I could kepp going on but I'll stop for now