(01-24-2015 05:53 PM)rprosperi Wrote: [ -> ]As you say, more research is needed, just thought I would share that discovery, which could be documenting that I'm the only idiot that never noticed this.
There are several things I know for sure at this point:
1) CK is based on labeled groups of lines, NOT associated lines from other labeled units (although associated lines from other labeled units CAN change lines of a calling program, and therefore CAN change the calling program's CK <--- this is usually what happens to folks...
2) Ck is NOT based on ordering of labels, nor is it based on position in program storage.
3) CK is NOT based on variable storage, nor indirect memories
4) If the labeled unit does not change, then the CK WILL NOT CHANGE (I have not been able to invalidate this claim taking 1-3 into account, thus far.
Consider the following: (keep in mind this is NOT a real program... know one would do this:
Code:
A001 LBL A ; LN=9 CK=24F1
A002 1.2
B001 LBL B ; LN=9 CK=7534
B002 1.3
C001 LBL C ; LN=9 CK=28C6
C002 x
C003 RTN
-
Now consider please, do we have three programs, or one program? If you XEQ A all three will run... try it.
Changing any of the lines, in any of the segment labels, will ONLY change the CK of that labeled unit (even though ALL the lines of the program are associated with the entire program). Changing x to / in C will ONLY change the CK of C, not A, nor B.
Now consider this monster... and remember, nobody would code this... but they code stuff LIKE it all the time:
Code:
A001 LBL A ; LN=9 CK=8550
A002 XEQ B002 ;
A003 RTN ;
B001 LBL B ; LN=21 CK=2889
B002 1.2 ;
B003 1.3 ;
B004 + ;
B005 RTN ;
-
Now consider please (after studying) "what will happen if insert x<>y after B001?"
Will the CK for B change alone? Will the CK for A also change????
In fact the CK for both will change, and this is a BIG FAT surprise to most would-be programmers of the HP35s; especially if some time passes before they update B. Let us suppose that the coder inserts the x<>y instruction immediately after B001 so that the whole thing looks like this:
Code:
A001 LBL A ; LN=9 CK=B85F <==oh, look a surprise maybe
A002 XEQ B003 ; <====notice what happens here (recalculated)
A003 RTN ;
B001 LBL B ; LN=24 CK=7FE0 <=== we expected this change
B002 x<>y ; CODE INSERTED HERE CAUSES the TROUBLE
B003 1.2 ; <==== entry point of B is renumbered !
B004 1.3 ;
B005 + ;
B006 RTN ;
-
Now suppose for a moment that you have many entry points (targets of a GTO(s) or XEQ(s) in a labeled unit (say U for utilities) and you make even ONE change in the utilities labeled unit near the top... yup, ALL of the CKs will change in EVERY SINLGE labeled unit that calls the routines in the U labeled unit because ALL or MOST of the U labeled unit entry points get renumbered, and then subsequently (recalculated) in the calling routines... <===== this is what is happening with most folks experiencing this
The bottom line is that if the CK changes in a labeled unit, then SOME character has changed in that labeled unit (normally due to GTO XEQ target renumbering).
So far, including comments from you, I have yet to find *anyone* experiencing this so-called bug that IS NOT the victim of this scenario; albeit, usually way more complicated than this one.
Now I ask you, (and I'm still researching it and hammering it out to make sure) is it fair to call this an HP firmware bug? Or, is the CK mechanism doing its job as designed by some brilliant engineers and the bug-labeling is really unwarranted (maybe an apology might be in order...)? I ask you?
Food to Think On...
Cheers,