35s program checksums

[MarkHaysHarris777]

(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,