HP Forums
RCL IND IND: a solution in search of a problem? - Printable Version

+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: RCL IND IND: a solution in search of a problem? (/thread-2636.html)



RCL IND IND: a solution in search of a problem? - Ángel Martin - 12-16-2014 06:54 PM

While doing some code optimization in a few FOCAL programs I briefly considered a RCL IND IND implementation to approach a segment of code dealing with pseudo-recursive register manipulation. I ended up tossing the idea to the bin but wonder if anyone here has had similar thoughts..

Is the RCL IND IND an absurd concept, or would it be actually useful for anything? I must admit I can't come up with an example right now... also wonder if some similar structure is available in RPL models (so advanced they were, right?).

What say you?

for clarity, here's an example:
Say register 5 contains the value "6", and register "6" has the value "3",
then RCL IND IND 05 = RCL IND 06 = RCL 03


RE: RCL IND IND: a solution in search of a problem? - Garth Wilson - 12-16-2014 07:18 PM

How about a GTO IND IND or any of the other IND IND's? The only doubly indirect addressing that immediately comes to mind from experience is in ITC Forth's NEXT; but that would be irrelevant to FOCAL.


RE: RCL IND IND: a solution in search of a problem? - Dieter - 12-16-2014 10:56 PM

(12-16-2014 06:54 PM)Ángel Martin Wrote:  Is the RCL IND IND an absurd concept, or would it be actually useful for anything?

I wouldn't call it absurd, but IMHO there are simply too few useful applications compared to the effort of implementing such a "double IND".

(12-16-2014 06:54 PM)Ángel Martin Wrote:  I must admit I can't come up with an example right now...

A long time ago I wrote some kind of matrix program that used line swapping. The register addresses of swapped elements were logged so that later the same swap could be applied to new data. This required a RCL IND 01 to recall the new address of the element that R01 pointed to, and then a RCL IND X to recall that element's value. I think this was the only time such a RCL IND IND command would have been useful.

Dieter


RE: RCL IND IND: a solution in search of a problem? - Thomas Klemm - 12-16-2014 11:37 PM

Would that make us two star programers?

Cheers
Thomas


RE: RCL IND IND: a solution in search of a problem? - Ángel Martin - 12-17-2014 07:27 AM

(12-16-2014 11:37 PM)Thomas Klemm Wrote:  Would that make us two star programers?

Cheers
Thomas

Nice example and appropriate to this subject - I think. So there's after all some merit to the concept. Yes, I also used once RCL IND X right after another RCL IND nn - like Dieter points out, and it's the same as the double IND indeed.

Obviously for completion sake STO IND IND needs to be thrown to the set, but GTO IND IND is going to be more difficult so I'll probably skip it (read: I don't know enough to tackle it).

Cheers,
'AM


RE: RCL IND IND: a solution in search of a problem? - Ángel Martin - 12-19-2014 08:28 AM

Here's the code for both functions, RIND2 and SIND2... easy does it: only 50 bytes for the whole thing.

I've made them prompting, and with IND capability - so effectively they provide a triple-IND in that case (my head spins with all these pointers).

Code:

AAC0    0B2    "2"    
AAC1    004    "D"    "RCL IND IND _ _"
AAC2    00E    "N"     a solution in search of a problem…"
AAC3    209    "I"    
AAC4    213    "S"    Ángel Martin
AAC5    108    SETF 8    
AAC6    0F8    READ 3(X)    
AAC7    070    N=C ALL    
AAC8    03B    JNC +07    [MAIN]
AAC9    0B2    "2"    
AACA    004    "D"    "STO IND IND _ _"
AACB    00E    "N"     a solution in search of a problem…"
AACC    209    "I"    
AACD    212    "R"    Ángel Martin
AACE    104    CLRF 8    
AACF    04C    ?FSET 4    
AAD0    01F    JC  +03    SST'ing a program
AAD1    2CC    ?FSET 13    
AAD2    01B    JNC +03    RUN'ing a program
AAD3    179    ?NC XQ    Get Parameter from NextLine
AAD4    10C    ->435E    [GETRG#]
AAD5    026    B=0 S&X    single registers
AAD6    219    ?NC XQ    check for valid IND addr 
AAD7    10C    ->4386    [EXISTS]
AAD8    0A6    A<>C S&X    
AAD9    270    RAM SLCT    
AADA    038    READ DATA    yy = IND (xx)
AADB    38D    ?NC XQ    convert C to Hex in C[S&X]
AADC    008    ->02E3    [BCDBIN]
AADD    106    A=C S&X    
AADE    255    ?NC XQ    check for valid addr
AADF    10C    ->4395    [VALID]
AAE0    0A6    A<>C S&X    
AAE1    270    RAM SLCT    
AAE2    038    READ DATA    zz = IND (yy) = IND[ IND (xx) ]
AAE3    106    A=C S&X    
AAE4    38D    ?NC XQ    convert C to Hex in C[S&X]
AAE5    008    ->02E3    [BCDBIN]
AAE6    255    ?NC XQ    check for valid addr
AAE7    10C    ->4395    [VALID]
AAE8    0A6    A<>C S&X    
AAE9    270    RAM SLCT    
AAEA    038    READ DATA    zz' s contents
AAEB    10C    ?FSET 8    
AAEC    0A5    ?NC GO          RCL and stack lift
AAED    04A     ->1229    [LXEXL]
AAEE    0B0    C=N ALL    
AAEF    000    WRIT DATA    
AAF0    3C1    ?NC GO    doa proper exit
AAF1    002    ->00F0    [NFRPU]

The calls to the Library#4 are easily ported, let me know if you're interested in getting more details.

These functions are now in the CL_XMEM module.

Cheers,
ÁM


RE: RCL IND IND: a solution in search of a problem? - charger73 - 12-19-2014 09:28 AM

Allways very interesting MCODE examples and very good comments in the coding. Thank you.

What is the the difference when "you" end a routine with:

3C1 ?NC GO doa proper exit
002 ->00F0 [NFRPU]

or :

08C GO in orderly fashion
13E ->AD3E [NFRX2]

Tobie


RE: RCL IND IND: a solution in search of a problem? - Andres - 12-19-2014 12:40 PM

This may be a little off-topic, but you made me remember the Nova architecture from Data General, the first computers I worked with (not counting my HP-25) around 1979. As memory space was 64 KBy of 16-bit words, address lines were just 15. So the most significant (16th) address bit was used as an indirection flag. If you addressed a memory location whose address had "1" as the most significant bit (i.e.: in the range 8FFF to FFFF), the obtained data was to be taken as an address to another memory location where to find the data to be used... only that if the contents of such memory location had "1" as the most significant bit, it will be considered (again) as an address for an indirect operation, and so forth, allowing for a potentially infinite indirection chain.

As this description is just from old memories, it may be somehow inaccurate, so I apologize in advance for possible errors and also for idiomatic mistakes.


RE: RCL IND IND: a solution in search of a problem? - Ángel Martin - 12-19-2014 05:29 PM

(12-19-2014 09:28 AM)charger73 Wrote:  What is the the difference when "you" end a routine with:

3C1 ?NC GO doa proper exit
002 ->00F0 [NFRPU]

or :

08C GO in orderly fashion
13E ->AD3E [NFRX2]

Tobie

Good catch - as it happens the second example is from a routine located in a bank-switched page. Depending on the platform (CL, Clonix, MLDL2k...) a return to the OS from a secondary bank may not "switch" back to the main bank and leave the page "hanging", which is not a good thing. The way to solve that is by switching first to the main bank, and then going to the OS routine - which is done in the subroutine called in lieu of [NFRPU].

Cheers,
'AM


RE: RCL IND IND: a solution in search of a problem? - Ángel Martin - 12-19-2014 05:32 PM

(12-19-2014 12:40 PM)Andres Wrote:  As this description is just from old memories, it may be somehow inaccurate, so I apologize in advance for possible errors and also for idiomatic mistakes.

Yes I can see the resemblance; I guess the common thread is scarce resources, small amount of memory and other factors that forced programmers to think about the code as opposed to just copying and bloating code lines from libraries and other constructs...
those days are pretty much gone!

Cheers,
'AM


RE: RCL IND IND: a solution in search of a problem? - Marcus von Cube - 12-19-2014 09:12 PM

(12-19-2014 05:32 PM)Ángel Martin Wrote:  Yes I can see the resemblance; I guess the common thread is scarce resources, small amount of memory and other factors that forced programmers to think about the code as opposed to just copying and bloating code lines from libraries and other constructs...
those days are pretty much gone!

Not really, at lest not in the "embedded world". WP 34S is a pretty good example, even if written in C instead of assembly language. OTH I was already using C in the eighties on a Z80 driven machine control with a self written real time kernel.


RE: RCL IND IND: a solution in search of a problem? - Sylvain Cote - 12-21-2014 02:34 PM

(12-16-2014 06:54 PM)Ángel Martin Wrote:  Is the RCL IND IND an absurd concept, or would it be actually useful for anything? I must admit I can't come up with an example right now... also wonder if some similar structure is available in RPL models (so advanced they were, right?).

What say you?

I am late for my comments, but I have been thinking since you first mention it on how could this or a derivative be use in the real world.

A pratical use I could find with one of the derivative is an indirect indexed addressing that could be use to access vectors and matrices.

ex.: RCL IND 01 IDX X or RCL IND 01 IDX 02

Another more simpler alternative for the indirect indexed addressing is to implement recall arithmetics like the one in HP-42S with standard indirect access.

ex.: RC+ X then use RCL IND X

I have did a rapid search if you had already implemented the recall arithmetic but did not find it.

Here are some examples with direct indirect indexed addressing (it's becoming confusing here lol) and with alternate indirect indexed addressing using recall arithmetic.

First scenario ...

vector[5] -> R11=33, R12=44, R13=55, R14=66, R15=77
base address -> R01=11
index -> X=2

HP-41C RPN standard (the X<>Y is there to produce the same stack result as the 42S)
Stack before -> L=90 X=2 Y=92 Z=93 T=94
Operation -> [RCL 01] [X<>Y] [+] [RCL IND X]
Stack after -> L=2 X=55 Y=13 Z=92 T=93

HP-42S RPN with arithmetic recall
Stack before -> L=90 X=2 Y=92 Z=93 T=94
Operation -> [RCL+ 01] [RCL IND X]
Stack after -> L=2 X=55 Y=13 Z=92 T=93

Possible implementation ?

HP-41C RPN with arithmetic recall like the 42S
Stack before -> L=90 X=2 Y=92 Z=93 T=94
Operation -> [RC+ 01] [RCL IND X]
Stack after -> L=2 X=55 Y=13 Z=92 T=93

HP-41C RPN with indirect indexed
Stack before -> L=90 X=2 Y=92 Z=93 T=94
Operation -> [RCL IND 01 IDX X]
Stack after -> L=90 X=55 Y=2 Z=92 T=93

Second scenario ...

vector[5] -> R11=33, R12=44, R13=55, R14=66, R15=77
base address -> R01=11
index -> R02=2

HP-41C RPN standard
Stack before -> L=90 X=91 Y=92 Z=93 T=94
Operation -> [RCL 01] [RCL 02] [+] [RCL IND X]
Stack after -> L=2 X=55 Y=13 Z=91 T=92

HP-42S RPN with arithmetic recall
Stack before -> L=90 X=91 Y=92 Z=93 T=94
Operation -> [RCL 02] [RCL+ 01] [RCL IND X]
Stack after -> L=2 X=55 Y=13 Z=91 T=92

Possible implementation ?

HP-41C RPN with arithmetic recall like the 42S
Stack before -> L=90 X=91 Y=92 Z=93 T=94
Operation -> [RCL 02] [RC+ 01] [RCL IND X]
Stack after -> L=2 X=55 Y=13 Z=91 T=92

HP-41C RPN with indirect indexed
Stack before -> L=90 X=91 Y=92 Z=93 T=94
Operation -> [RCL IND 01 IDX 02]
Stack after -> L=90 X=55 Y=91 Z=92 T=93

Best regards,

Sylvain


RE: RCL IND IND: a solution in search of a problem? - Ángel Martin - 12-23-2014 08:06 AM

(12-21-2014 02:34 PM)Sylvain Cote Wrote:  I have did a rapid search if you had already implemented the recall arithmetic but did not find it.

Sylvain

Yes, RCL-Math it is implemented on the SandMath. I added the power function to the classic four (+, - *, /) so it's five in total. It does support INDirect addressing too, but not the stack registers - which makes it somehow limited. I looked into adding those as well but the OS does tricky stuff in that case, and besides the OSX extensions intercept these events, assuming it can only be the standard RCL... so it preempts any other outcome.

Best,
'AM