41 RPN LBL GTO rules

[Egan Ford]

Hello All,

I have a rather large 41CX program (not written by myself) that has a number of duplicate LBLs. I am trying to run this program using the 71B 41 Translator ROM, but it fails to run. I think it has to be an issue with the duplicate LBLs.

The manual states that when a GTO is encountered a scan is performed going down, then from top down, until found. But what if their are multiple local LBLs with the same name/number? It is the first or last? Furthermore the docs state that it is cached and not searched again. Is that only true for the original GTO or all GTOs to the LBL?

I'll admit I'm being a bit lazy and can setup an experiment to find the answer, but, well, I'm feeling lazy today. I am also looking for some insight as to why a person would code with duplicate LBLs. Is it a trick to be leveraged? Have others had issues with RPN code and duplicate LBLs on the 71B 41 Translator ROM?

Thanks.

[Thomas Okken]

Local GTOs and XEQs jump to the first matching label following the instruction. This means that for non-overlapping forward jumps, you can reuse labels; in my HP-41 days, I usually reserved LBL 00-02 for forward jumps, and higher numbers for backward jumps.

Once the local label is found, the offset from the GTO or XEQ is stored in that GTO or XEQ, so subsequent executions of that same instruction don't have to perform the search again. The cached offset stays valid until you edit or PACK the program; editing causes all local GTO and XEQ offsets to be invalidated. Offsets in other programs are not affected.

Given that there are 115 local labels to work with in the 41, there may not seem to be much incentive for reusing them, but keep in mind that LBL 00-14 are "short form" labels, occupying one byte less than the regular variety. Likewise, GTOs to those LBLs are also one byte shorter (but they also have a smaller jump offset field, so you should avoid using LBL 00-14 as target for long-range jumps, where "long range" means more than 112 bytes.

Note that the rules for global labels (ALPHA) are different; those are searched for backwards, starting from the .END. You cannot use duplicate ALPHA labels; if you do, only the last one will ever be reached.

- Thomas

[Raymond Del Tondo]

Hello Egan,

re-using local labels inside a FOCAL program is a common technique.

You can save bytes (or reduce program size) if you manage

to use the one-byte local labels 00-14 more than once,

instead of local labels like LBL 22, which take two bytes of memory.

Also, the associated GTO's use two bytes for label 00-14,

but three bytes for numeric labels above 14.

As you know, the primary search direction is forward,

so when a GTO <local> is encountered the first time the program is

run (or after an edit or GTO..), the OS will search for a suitable label,

from the current PC ot the end, and then from the start of the prog.

If found, the offset will be noted in the label opcode,

so the next time the program is run a jump to the label will be faster.

Also note that the two-byte GTO's have a restricted offset field,

so farther jumps will have to be computed each time.

IIRC, the translator ROM produces at least an intermediate file

before actually compiling the FOCAL program.

This processing stage would be a point to jump in.

But for FOCAL programs of which you plan to convert them to FORTH anyway,

I'd replace the duplicate local labels on the HP-41 beforehand.

Just take care to adjust the correct GTO/XEQ statements.

Also be aware of another potential obstacle:

Many HP FOCAL programs make use of indirect addressing.

This feature works for jumps, too!

Something like XEQ IND X will jump to the label whose name or number is in X.

There may be more tricks to be aware of, but I don't have them handy right now:-)

HTH

Edit: Thomas' response was earlier and more precise in less words;-)

Edited: 7 Mar 2009, 7:57 p.m.

[Egan Ford]

Thomas, Raymond,

Thanks. This helps. I think I figured out this program and my confusion. LBLs were being used as NOPs. LBLs after ISG, DSE or conditionals make sense to me. But LBLs after ENTER do not and if I remove them I get incorrect results. What's up with that?

Thanks.

[Thomas Okken]

The LBL after ENTER re-enables stack lift:

CLST 1 ENTER LBL 00 2 => T:0 Z:1 Y:1 X:2


CLST 1 ENTER 2 => T:0 Z:0 Y:1 X:2

Pretty obscure programming style IMHO. RCL X achieves the same result and is a lot more obvious... But maybe ENTER LBL 00 is faster?

- Thomas

[J-F Garnier]

It's amazing that after all these years I can still learn something about HP41 programming! I didn't know this trick.

In that particular case, I would just do "1 ENTER ENTER 2".

J-F

[Mike (Stgt)]

Hehe JF!
Never asked why the ZENROM has a NOP? In contrast to the 0-length text string NOP (F0) it preserves the stack lift en/dis-able state.

Ciao.....Mike

[Namir]

I use the STO ST X as a NOP for the 41C.

Namir

Edited: 8 Mar 2009, 7:18 p.m.

[Egan Ford]

Thanks. Very obscure indeed.