The Museum of HP Calculators

HP Forum Archive 19

[ Return to Index | Top of Index ]

Why no relative pointer in RPL
Message #1 Posted by David Hayden on 10 Mar 2010, 7:22 a.m.

I noticed the other day that RPL has no simple way to evaluate an object via a relative address. What I mean is that there's no way to say "evaluate the object whose address is here +/- some offset." This ability is practically a requirement of creating position-independent code.

It's trivial to evaluate an object using an absolute address - just put the address in the run stream. But when a library wants to call a subroutine, it must do it via an XLIB object which finds the library, gets the command from the hash table and jumps there. This is complex and time consuming. The other ways are via a global identifier or a LAM. Since many HP39gs aplets aren't libraries, they have to resort to a jump table at the beginning of the program. Double yuck.

A solution to this seems simple to me. A "relative pointer" object consisting of a 5 nibble prolog and a 5 nibble relative offset. It's function would be to call the object pointed at by the offset.

I suspect there's a good reason why such a thing doesn't exist, but I can't think of it. Does anyone have any ideas?

Thanks, Dave

      
Re: Why no relative pointer in RPL
Message #2 Posted by C.Ret on 10 Mar 2010, 11:25 a.m.,
in response to message #1 by David Hayden

Hye,

There is several simple ways to evaluate an object in RPL via a relative address. I may missing same thing about the XLIB and LAM object you speak about.

As far as I understand indirect reference mechanisms, the following RPL codes are all indirect reference to object in the XLib list :

Suppose the following list of objects store in XLib { 10 20 30 [1 2 3] [[7 8 9][4 5 6][1 2 3]] "Any Text" « DUP PRG » (12,3) 12.3_feet #adress ...} 'XLib' STO

To evaluate the object at the relative adress n, simply GET it ! 'XLib' n GET EVAL

Ex. 'XLib' 5 GET EVAL or 'XLib(5)' EVAL returns "Any Text"

And, a more relative adress can be used using any supplementary Index :

Ex. { 3 5 2 4 6 7 6 3 9 } 'Index' STO then 'Xlib' 'Index' 2 GET GET returns "Any text"

Or several as need : Ex. [ 1 2 3 4 5 1 2 3 4 5] 'PostIndex' STO tehn 'XLib' 'Index' 'PostIndex' 7 GET GET GET returns "Any Text"

And so on...

So, it looks to be easy and simple to make relative, relative indexed, relative multi indexed references in RPL !

No extra "pointer" object is required as any list, array or matrix may be used as a pointer table.

I certainly missing samething there and I may mistaken which XLIB, LAM or prolog's nibble you speak about.

Can you please be a bit more explicit concerning the HP49g's aplets jump table ?

            
Re: Why no relative pointer in RPL
Message #3 Posted by David Hayden on 10 Mar 2010, 1:43 p.m.,
in response to message #2 by C.Ret

The methods you mention will work, but what I'm talking about is something lower level. Suppose you have a library like this:

xNAME CMD1
::
  %1
  myInc
  %2
  myInc
;

NULLNAME myInc
::
  %1
  %+
;

The calls from CMD1 to myInc get converted into XLIB objects (AKA DOROMP objects). These objects contain a 3 nibble library ID and a 3 nibble command number. XLIB's prolog has to find the library, find its link table, find the command's entry in the link table and only then does it know where "myInc" is located.

A "relative pointer" object would be 1 nibble smaller than an XLIB, it would reduce the size of a library (because the internal commands wouldn't need to be in the link table) and it would be faster.

This is low level stuff related to how programming languages are implemented. Sorry if I wasn't clear.

Thanks, Dave

Dave

                  
Re: Why no relative pointer in RPL
Message #4 Posted by Han on 11 Mar 2010, 12:52 a.m.,
in response to message #3 by David Hayden

Is the GOTO command perhaps what you are looking for?

There are other ways to implement such a relative jump, but it requires embedding in a little bit of Saturn assembly code. The following code is untested (just what came to my head).

xNAME CMD1
::
  %1
  myInc
  %2

CODE
  GOSBVL =SAVPTR
  GOTO   _jumphere-(*)
ENDCODE
;

NULLNAME myInc 
::
SKIP
CODE
_jumphere
  GOVLNG =GETPTRLOOP
ENDCODE 
  %1 %+ 
;
                        
Re: Why no relative pointer in AKA DOROMP objects
Message #5 Posted by C.Ret on 11 Mar 2010, 2:55 a.m.,
in response to message #4 by Han

Thanks for the explanations.

I now understand my mistake, all this have nothing with user RPL and it looks to me more related to internal code and machine assembly language than I have expected from the first post title.

As I have no HP49, nor HP50, I only interpret RPL as user RPL languages as available on HP28C/S calculator. And I have to admit I have no clue of what all this stuff is related to.

What you are describing here have nothing to do with classic RPL and it's look to be really system specific (I suspected you aren't actualy hacking all this code on true HP calculator, but on emulator or dedicated software environnment).

That's the cost of this technology, no more portability and sharable understanding or logic. This is exactly the travers denoncied by RPN users who like RPN's portability, no hardware specificity and a wide shared standard.

Sorry, for being incompetant in this stuff.

                              
Re: Why no relative pointer in AKA DOROMP objects
Message #6 Posted by David Hayden on 11 Mar 2010, 11:09 a.m.,
in response to message #5 by C.Ret

Quote:
What you are describing here have nothing to do with classic RPL and it's look to be really system specific (I suspected you aren't actualy hacking all this code on true HP calculator, but on emulator or dedicated software environnment).
Actually, it isn't system specific, it's generic system RPL and goes right back to Wickes's RPLMAN.DOC description of the language.

I received a wonderful explanation in a private email. I won't mention who in case he wants to remain anonymous. It isn't really practical currently because of the way the calculator does memory management. When you execute a command in a library that isn't in port 0, the calculator copies the command to temporary memory and executes it there. Since it copies the command and not the whole library, a relative pointer wouldn't point to the right place.

Another casualty of an address space that's too small.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall