+- 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