RCL IND IND: a solution in search of a problem?

12162014, 06:54 PM
Post: #1




RCL IND IND: a solution in search of a problem?
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 pseudorecursive 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 

12162014, 07:18 PM
Post: #2




RE: RCL IND IND: a solution in search of a problem?
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.
http://WilsonMinesCo.com (Lots of HP41 links at the bottom of the links page, http://wilsonminesco.com/links.html ) 

12162014, 10:56 PM
(This post was last modified: 12162014 10:59 PM by Dieter.)
Post: #3




RE: RCL IND IND: a solution in search of a problem?
(12162014 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". (12162014 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 

12162014, 11:37 PM
Post: #4




RE: RCL IND IND: a solution in search of a problem?  
12172014, 07:27 AM
Post: #5




RE: RCL IND IND: a solution in search of a problem?
(12162014 11:37 PM)Thomas Klemm Wrote: Would that make us two star programers? 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 

12192014, 08:28 AM
(This post was last modified: 12192014 08:31 AM by Ángel Martin.)
Post: #6




RE: RCL IND IND: a solution in search of a problem?
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 tripleIND in that case (my head spins with all these pointers). Code:
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 

12192014, 09:28 AM
Post: #7




RE: RCL IND IND: a solution in search of a problem?
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 

12192014, 12:40 PM
Post: #8




RE: RCL IND IND: a solution in search of a problem?
This may be a little offtopic, but you made me remember the Nova architecture from Data General, the first computers I worked with (not counting my HP25) around 1979. As memory space was 64 KBy of 16bit 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. Andrés C. Rodríguez (Argentina) Please disregard any idiomatic error. 

12192014, 05:29 PM
(This post was last modified: 12192014 09:53 PM by Ángel Martin.)
Post: #9




RE: RCL IND IND: a solution in search of a problem?
(12192014 09:28 AM)charger73 Wrote: What is the the difference when "you" end a routine with: Good catch  as it happens the second example is from a routine located in a bankswitched 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 

12192014, 05:32 PM
Post: #10




RE: RCL IND IND: a solution in search of a problem?
(12192014 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 

12192014, 09:12 PM
Post: #11




RE: RCL IND IND: a solution in search of a problem?
(12192014 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... 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. Marcus von Cube Wehrheim, Germany http://www.mvcsys.de http://wp34s.sf.net http://mvcsys.de/doc/basiccompare.html 

12212014, 02:34 PM
Post: #12




RE: RCL IND IND: a solution in search of a problem?
(12162014 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?). 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 HP42S 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 HP41C 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 HP42S 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 ? HP41C 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 HP41C 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 HP41C 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 HP42S 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 ? HP41C 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 HP41C 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 

12232014, 08:06 AM
(This post was last modified: 12232014 08:08 AM by Ángel Martin.)
Post: #13




RE: RCL IND IND: a solution in search of a problem?
(12212014 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. Yes, RCLMath 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 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)