35s program checksums

[rprosperi]

(01-24-2015 07:51 AM)MarkHaysHarris777 Wrote:  I will give you a little hint about the perceived checksum difficulty-- what constitutes the smallest program unit of execution on the 35s, and what are the limits in storage for checksum computation for a given set of labels over a given memory range? If a would-be programmer does not understand the rules of engagement, then the checksums cannot be used to their advantage. I'm still experimenting with this, but for now I am convinced that the checksum mechanism is working as designed.

Your comments motivated me to RTFM. Again. The section (p. 13-23) which describes the role of the checksum states:

Quote:The checksum is a unique hexadecimal value given to each program label and its
associated lines (until the next label).

Don't believe I ever thought much about the parenthetical note (my emphasis added above).

Looking further into the manual, sections 15, 16, and 17 list many sample programs to illustrate various topics, but in each listing, the [SHOW] Checksums are included within the listings at the end of each 'routine', or stated differently, just before each new label. This would seem to imply the checksum shown is only for the section between the prior label (inclusive) and the following label (exclusive).

So, maybe it is functionaling correctly, though with a perhaps unintuitive behavior. I think most folks would assume a program checksum is just that, a checksum for the program, when in fact they really are routine checksums.

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.

Thanks.