hp 50G SysRPL linked arrays

[Podalirius]

Hi, I am investigating in some "Hi-End" features of System RPL.
I dont be able to find any info about linked arrays. The Programming in SysRPL second edition,
by Eduardo Kalinowski and Cardten Dominik only give very low info.
How I can find detailed info? Maybe some books?
Thank you very much for all help!!!

[DavidM]

(08-07-2018 01:32 PM)Podalirius Wrote:  Hi, I am investigating in some "Hi-End" features of System RPL.
I dont be able to find any info about linked arrays. The Programming in SysRPL second edition,
by Eduardo Kalinowski and Cardten Dominik only give very low info.
How I can find detailed info? Maybe some books?
Thank you very much for all help!!!

I'm not aware of any books describing the use of LNKARRYs, but you can find a few small bits of information in archived usenet posts from comp.sys.hp48.

The only semi-official documentation I've ever run across is the listing of the data structure in James Donnelly's "An Introduction to HP 48 System RPL and Assembly Language Programming". I believe that same structure is probably documented in a couple of other places as well. Despite searching for it, I've never run across any formal documentation pertaining to the use of these arrays.

Theoretically, they should allow faster access to specific elements for some arrays, though I've never seen any conclusive comparisons made. I would expect the biggest performance differences to occur with very large arrays and/or specially-formatted arrays created for specific purposes. Arrays of strings would probably benefit more than arrays of objects with coherent sizes, since locating the start of the string object with the included pointers should be much easier than the sequential skipping that would otherwise be required.

SysRPL compilers provide limited support for creating simple LNKARRYs, but the more complicated structures can be coded manually (using labels to facilitate the pointer creation).

As an example (using Debug4x):

Code:

LNKARRY [ % 1 % 2 % 3 ]

...creates a LNKARRY object that is similar to a UserRPL [ 1. 2. 3. ] vector, but it adds the offset pointers to the elements automatically.

To truly take advantage of the LNKARRY features, though, you probably need to be more explicit about how the array is defined. For example, if you wanted to build a 6-element LNKARRY that has 3 unique numbers each repeated twice, you could do it as follows:

Code:

ASSEMBLEM
   % prologue
   $(5)=DOLNKARRY

   % size field
   GOIN5 EndOfTestLinkArray

   % object type
   $(5)=DOREAL

   % count of dimensions
   $(5)1

   % dimension 1
   $(5)6

   % offset 1
   GOIN5 LA_Object_3

   % offset 2
   GOIN5 LA_Object_2

   % offset 3
   GOIN5 LA_Object_1

   % offset 4
   GOIN5 LA_Object_2

   % offset 5
   GOIN5 LA_Object_1

   % offset 6
   GOIN5 LA_Object_3

   % OBJECTS

   *LA_Object_1
   $0000000000000010

   *LA_Object_2
   $0000000000000020

   *LA_Object_3
   $0000000000000030

   % marks the end of the object
   *EndOfTestLinkArray
!RPL

This creates the equivalent LNKARRY for a UserRPL [ 3. 2. 1. 2. 1. 3. ].

If you look closely at how the above is defined, you'll see that the 3 raw elements are only defined once, and the offsets specify the ordering (and quantity) of the final elements in the array.

I've never seen any descriptions of which internal array functions support LNKARRYs, but I suspect most of the documented SysRPL ones do.

Hopefully others can clarify with more detail.

[Claudio L.]

(08-08-2018 01:55 AM)DavidM Wrote:  I've never seen any descriptions of which internal array functions support LNKARRYs, but I suspect most of the documented SysRPL ones do.

Hopefully others can clarify with more detail.

It's been a long time so I might be wrong but I vaguely recall trying to use linked arrays and no commands supported them. It seems the object type was created but never actually used for anything in the ROM.

[DavidM]

(08-08-2018 02:18 AM)Claudio L. Wrote:  It's been a long time so I might be wrong but I vaguely recall trying to use linked arrays and no commands supported them. It seems the object type was created but never actually used for anything in the ROM.

OK, we're both wrong -- it's somewhere between what we both said. I just got lucky on the first few I tried, and subsequently fell into the "assumption trap". The following is not an exhaustive test, but I did at least check the following:

^ARSIZE: works
GETATELN: works
^DIMLIMITS: works
OVERARSIZE: works
^MDIMS: doesn't work
MDIMSDROP: doesn't work
PULLREALEL: doesn't work
PUTEL: doesn't work
PUTREALEL: doesn't work

I stopped checking after that. GETATELN is probably the most important, as it has to abide by the offset list to gain access to the individual elements. The size/dimension commands only look at the fields that are presumably in the same place (and usage) in both formats, but MDIMS/MDIMSDROP are SysRPL programs that have no dispatch for the LNKARRY type and thus throw a "bad argument type" error.

The PULL/PUT commands appear to assume that the argument is a standard array (with no pointers are present), and thus fall apart miserably if called. The result can leave things in a very bad state, with an imminent crash likely.

So I was perhaps hasty in my suspicion of more widespread support, but since LNKARRYs are best thought of as read-only anyway, the ones that do work might be enough for a determined SysRPL programmer.

That said, I'm still not sure that there's much reason to use them! The limited testing I did a long time ago (on a 50g) didn't show any appreciable difference in performance for the things I tried. I probably didn't throw any really large arrays at it, though. It's too much hassle to create them manually, so it wasn't easy to test. The only advantage I can see is if you need to create an array for internal use that has lots of duplicates (see the earlier example for how that can save space), or perhaps if you have some use for an array of strings that you need to access faster than a sequential skip would allow.

[cyrille de brébisson]

Hello,

Basically, the only use of Linked array in the 48 series calculator is for array of error strings...
Since strings have non constant size, doing it this way saves a lot of 'skip over'...

Linked array are also sometimes used to store binary data by libraries.

Cyrille

[Claudio L.]

(08-08-2018 03:07 AM)DavidM Wrote:  OK, we're both wrong -- it's somewhere between what we both said.

Of course! My sample of commands was very limited, I think I tried a few arithmetic operations and gave up when couldn't even add or multiply by a scalar.

Cyrille cleared that up: if they only needed to read strings from an array, the only functions needed were basically get the size and read an element, that's it (so you found them all, or almost all).