Which calculators run RPL under the hood?

[John Keith]

Thanks, Cyrille- that was very informative. "Inside dope" like this is always welcome!

[Jonathan Busby]

(12-09-2019 02:18 AM)Christoph Giesselink Wrote:  

(12-08-2019 07:24 PM)Jonathan Busby Wrote:  Are you sure? I don't remember if the 1LF2 even had a PC=A instruction.

Source Horn Disk 4 file SASM.DOC from the HPTOOLS package:

page 15:

Code:

6.  Saturn Assembler Format and Mnemonics

This chapter describes the Saturn assembler instruction set.
The Saturn CPU has three variations used in several
products.  The 1LF2 was used in the first versions of the
HP-71B.  The 1LK7 is a variation of the 1LF2 used in later
versions of the HP-71B, the HP-18C, and the HP-28C.  The
1LR2 is an integrated CPU/ROM/RAM/Display Driver IC.  Each
new version of the Saturn CPU added new instructions to the
Saturn instruction set.  Instructions available in all
Saturn CPUs are referred to as "level 0" instructions.
Instructions available in the 1LK7 and 1LR2 but not the 1LF2
are referred to as "level 1" instructions.  Instructions
available only in the 1LR2 are referred to as "level 2"
instructions.  In this section, "level 1" instructions are
marked with an asterisk (*), "level 2" instructions are
marked with two asterisks (**).  Instructions with no mark
are "level 0" instructions.

page 116:

Code:

PC=(A)      - Jump (Set PC) indirectly thru A field of A register
---------
                            opcode:  808C
                            cycles:    23

This instruction causes the CPU to jump to the address
pointed to by memory at the address specified by the A field
of the A register.  In symbolic form, the operation is
PC=mem(A[A]).  This opcode is not available on the 1LF2
version of the Saturn CPU.

page 20:

Code:

PC=A       ** Direct jump; A(A) is the
              destination address.
PC=C       ** Direct jump; C(A) is the
              destination address.

Both opcodes PC=A and PC=C are marked with two asterix so they belong to the "level 2" instructions.

Thanks for the tip Indeed, all the direct PC access instructions, including A=PC, PC=A, C=PC, PC=C PC=(A) and PC=(C) were apparently not implemented in the original 1LF2 Saturn CPU, according to SASM.DOC .

Regards,

Jonathan

[BruceH]

(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...

Sometime back in the late 80's or early 90's, Bill Wickes came to an HPCC conference in London and I asked him if they had any plans to make RPL more object-oriented? There was a definite moment of 'rolls eyes' before he politely answered in the negative.

I always wondered if I had unwittingly touched on some internal sore point with the team!

[cyrille de brébisson]

hello,

I actually started working on something like this for the 49G, but it never made it in the code...
Basically creating 2 new prologues, one for raw objects, one for composit objects, which included a "type" referrer (an xlib pointer). The arguements checking code was also modified to be able to detect such objects and call back to the xlib when/as needed...
This would have allowed to create new objects types and have things like normal RPL command respond to them (like +)...

But we had other cats to skin at the time...

Cyrille

[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

[David Hayden]

It seems to me that adding a new object to RPL goes beyond creating a prolog. You also need hooks for:

• Computing the object size
• compiling an object from text
• decompiling an object to text
  

You also need a way to compare objects, and you may want to apply arithmetic operations (and other mathematical operations) to it, or convert it to an existing type so it can apply arithmetic.

Dave

[grsbanks]

The size of an object, when that size is not constant and known in advance, is more often than not in 5 nibbles immediately after the prologue. But yeah, the rest needs addressing.

[Jonathan Busby]

(12-16-2019 03:54 PM)David Hayden Wrote:  It seems to me that adding a new object to RPL goes beyond creating a prolog. You also need hooks for:

• Computing the object size

This is automatically taken care of in the solution I provided. The library in port 0 would have each object prolog prefixed by the direct execution code and =SKIPOB code for that object. =xSIZE calls =OSIZE which in turn calls =SKIPOB on the object, which then calls the object under consideration's custom skip code

Quote:

compiling an object from text

This involves modifying palparse, the master parser for the HP48. Unfortunately, I forget if palparse can be tweaked by overriding any libraries :/

Quote:

decompiling an object to text

The same goes for the de-compiler.

Quote:You also need a way to compare objects, and you may want to apply arithmetic operations (and other mathematical operations) to it, or convert it to an existing type so it can apply arithmetic.

Well, unfortunately, the type dispatching code on the HP48 series can't be overridden unless one takes "extreme" measures You'd either need one ( or, preferably, two ) RAM cards, or, you could de-solder the HP48 ROM chip and add a NAND flash chip, but, you'd probably have to use a tiny daughterboard, which would be tricky

I'll have to look at some of my old notes and/or do a little disassembly to fully answer your questions about parsing and object to string conversion.

...

Well, I went ahead and did some digging and on the HP48 at least, and, most of what constitutes palparse can be overridden by a custom library, and the same goes for the object to string de-compiler

I would imagine that the custom objects, created as I've described them, would only be used within the confines of, say, a secondary and would not be stored -- the more general solution is harder.

Regards,

Jonathan

[Jonathan Busby]

(12-16-2019 04:04 PM)grsbanks Wrote:  The size of an object, when that size is not constant and known in advance, is more often than not in 5 nibbles immediately after the prologue. But yeah, the rest needs addressing.

A lot of objects have that structure, such as code objects, "library data" objects, hex strings, character strings etc. A lot do not of course like secondaries ( eg. :: ... ; ), lists etc. The system uses each object type's =SKIPOB code to determine the size, in general

Regards,

Jonathan

[Claudio L.]

Nice to see this discussion about the extensibility of RPL. Where were you guys in 2013 when I started newRPL? This discussion would've come in handy. To be fair, David and Han actually participated in the early talks, so when I say the people above this post, David you are excluded

Anyway, we figured it out and newRPL actually does *everything* that was mentioned above:

* There's a library number embedded in the prolog to dispatch execution

* There's an object size also embedded in the prolog, so computing the object size is standardized across the entire system.

* Operators are overloaded (so + will be dispatched to new object types automatically), commands in general can be overloaded but I try to avoid that for speed reasons.

* Compiling and decompiling are dispatched to the libraries managing the objects, this includes not just object types but commands as well.

* In addition, there's also object validation being dispatched: The system might request a library to verify if the object is valid. This helps prevent memory corruption due to invalid objects. It also helps composite objects validate that objects that the user included within are valid, for example when the compiler finds the token "[" in the source code, the matrix library recognizes it and opens a composite, requesting validation. Any object the user included after that gets compiled by its own library, and then sent to the matrix library for validation. For example a text string inside a matrix would be compiled just fine, but rejected by the matrix library at the validation step.

* There's no master command list or fixed compiler code. The compiler simply splits the tokens and sends them to all libraries in descending order. Whichever library claims the token first, gets to compile it. This means a library with higher number may override any command or any object definition of a lesser library.