Strange issue with KEY GTO

[Thomas Okken]

So inserting a R/S between LBL 99 and the END as you did above should have cleared the cached targets, but it didn't ....

Good point! I hadn't thought of that.

I just tried SST-ing both GTO A instructions, and one of them jumps to the CLST on line 2. Despite the STOP that I had added after LBL 99.

However, then I deleted that STOP, and now both GTO A instructions jump to LBL A.

So, there seems to be something wrong with the logic that clears the jump targets. I'll look into that this weekend, unless I can find time to do it sooner.

[Thomas Okken]

there seems to be something wrong with the logic that clears the jump targets.

No, the logic that clears the jump targets is OK. The problem is an inconsistency in Didier's state file: the program's lclbl_invalid flag is set, which should only be true if all the local GTO/XEQ targets are clear, and yet there is a GTO whose target is not clear.

The lclbl_invalid flag tells Free42 that it doesn't have to clear the local GTO/XEQ targets when editing takes place. The objective is that you don't want to scan the entire program, clearing those targets, every single time an edit takes place. The flag is set when the targets are cleared, and it is cleared when a local GTO or XEQ is performed, causing its target to be set. Thus, there should never be a GTO or XEQ with a target that is set, while the lclbl_invalid flag is also set. (The lclbl_invalid flag indicates that *all* local GTO/XEQ targets are clear, not just some of them.)

The question, then, is how Didier's DM42 got into this state. I don't have an answer to that, unfortunately.
Considering that this is basic Free42 program editing and execution logic, 13 years old, not previously known to have this kind of problem, I suspect that Didier's DM42 got into this bad state because of a DM42 bug, not a Free42 bug... but until the cause is positively identified, there's no way to be 100% sure.

The question of how to get out of that state is also a bit more complicated than I first thought. This should work: enter GTO 00 LBL 00 anywhere in the program, then BST so you're back on the GTO 00; exit PRGM mode, and press SST to execute the GTO 00. It will find the LBL 00, set the jump target in the GTO 00, and clear the lclbl_invalid flag. Then, go back to PRGM mode, and delete the GTO 00 and LBL 00. Since the lclbl_invalid flag is clear, this will cause all the local GTO/XEQ targets to be cleared, and the program should go back to behaving normally.

Saving the program, clearing it, and then reloading it, will also do the trick.

[dlachieze]

Thanks Thomas for the detailed explanation of the Free42 GTO/XEQ targets handling logic.

The question, then, is how Didier's DM42 got into this state. I don't have an answer to that, unfortunately.

I have the answer as I understand now how Free42 is working.

So here is a way to reproduce on Free42 the inconsistency between the lclbl_invalid flag being set with an uncleared target :

First do CLP "TST" if you have it in memory, then GTO .. and enter the following program :

Code: Select all

01▸LBL "TST"
02 CLST
03 XEQ "TKG"
04 8

Now do GTO .. again and enter:

Code: Select all

01▸LBL "TKG"
02▸LBL A
03 "ADD"
04 KEY 1 GTO 01
05 KEY 9 GTO 99
06 MENU
07 PROMPT
08 GTO A
09▸LBL 01
10 GTO A
11▸LBL 99

Exit program mode and press: XEQ "TST", ADD, EXIT
You have 8 in X, and 0 in the other stack registers.
By pressing ADD the LBL 01 has been executed and the target of the GTO A at step 10 has been set to step 02.

Now go in program mode, insert a RTN before the END (step 05 of TST), this clears the XEQ/GTO targets in the program TST (but not in TKG) and sets the lclbl_invalid flag for TST.
Then remove the END at step 06, merging TST and TKG in a single program.
This is where the bug bytes! As the TST lclbl_invalid flag is set, the targets of XEQ/GTO in TKG are not cleared, creating the inconsistency: the target of GTO A now at step 15 is still step 02 which is no longer LBL A.

Exit program mode and press: XEQ "TST", ADD, EXIT
You have now 8 in both X and Y, and 0 in the other stack registers.

[Thomas Okken]

I have the answer as I understand now how Free42 is working.

So here is a way to reproduce the inconsistency between the lclbl_invalid flag being set with an uncleared target :

Yes! That's it!
I just reproduced that on my iPhone.

So it is a Free42 bug, not a DM42 bug.

I'll fix this this weekend and release 2.0.17.

Thank you, Didier!

[dlachieze]

I'll fix this this weekend and release 2.0.17.

Thank you, Didier!

Great ! Now I would like to understand as well the KEY XEQ issue I've posted here.

[Thomas Okken]

Now I would like to understand as well the KEY XEQ issue I've posted here.

I will investigate that this weekend.

[Thomas Okken]

I'll fix this this weekend and release 2.0.17.

Thank you, Didier!

Great ! Now I would like to understand as well the KEY XEQ issue I've posted here.

Didier, can you provide instructions how to reproduce this problem, starting from a Memory Clear or CLALL state?

[dlachieze]

Hi Thomas, it seems that loading the state file is not enough to reproduce the issue which means that some critical things driving this issue are not saved in the state file at the difference of the uncleared XEQ/GTO targets. I’ve been able to fall into this issue again but I’ll need some time to find a way to consistently reproduce it.

In the meantime here is a video showing what’s happening with the Convert program which is provided with the DM4: https://youtu.be/74l27-pmCVE

1. I launched the ‘CONV’ program from the Custom Menu
2. I pressed on ‘LENG’ , for length conversion
3. I entered 2 and pressed on ‘FT’, which called LBL 02 via “KEY 2 XEQ 02” at step 10
4. LBL 02 recognised that 5 was just entered (flag 22 set) and added FT in the Alpha register without doing any conversion
5. the program stopped at the end of LBL 02 on the RTN at step 73 without returning to step 28 after the STOP, so flag 22 was not cleared
6. I pressed on ‘cm’ to convert to centimetres, LBL 06 was called but as flag 22 was not cleared it just replaced the FT by cm in the Alpha register without doing any conversion
7. the program stopped at the end of LBL 06 on the RTN at step 169 without returning to calling address
8. pressing SST executed the RTN at step 169, returning to step 73
9. pressing SST again executed the RTN at step 73 returning to step 28

So the DM42 is in a state where program execution stops at RTN without returning to the calling address while with SST the RTN are executed and the program counter returns to the calling address.

Do you know what is different in the execution of RTN within a program or with SST that could explain this behavior?

[Thomas Okken]

It's not a bug; you need CF 21.

The RTN is not the problem. It's stopping after the AVIEW because you're in POFF mode (flag 55 clear) with printing enabled.

[dlachieze]

Yes ! That's it !

So to prevent the occurrence of such issue the beginning of the CONV program should be modified from:

Code: Select all

01▸LBL "CONV"
02▸LBL 00
03 CLMENU

to something like:

Code: Select all

01▸LBL "CONV"
02 CF 21 	@ Sets or clears flag 21 to match flag 55
03 FS? 55
04 SF 21
05▸LBL 00
06 CLMENU