[TUHS] why is sum reporting different checksum's between v6 and v7
Random832
random832 at fastmail.com
Sat Dec 12 11:07:19 AEST 2015
Noel Chiappa writes:
> The two use different algorithms to accumulate the sum (I have added comments
> to the relevant portion of the V6 assembler one, to help understand it):
>
> V6:
> mov $buf,r2 / Pointer to buffer in R2
> 2: movb (r2)+,r4 / Get new byte into R4 (sign extends!)
> add r4,r5 / Add to running sum
> adc r5 / If overflow, add carry into low end of sum
> sob r0,2b / If any bytes left, go around again
Interestingly, the SysIII sum.c program, which I assume yields the same
result for this input, appears to go through the whole input
accumulating the sum of all the bytes into a long, then adds the two
halves of the long at the end rather than after every byte. This
suggests that the two programs would give different results for very
large files that overflow a 32-bit value. Of course, that's (16843010
bytes if all of them are 255) well beyond the size of file you're likely
to encounter on a v6 system.
Also, if this sign extends, then its behavior on "negative" (high bit
set) bytes is likely to be very different from the SysIII one, which
uses getc.
Can someone who has V6 up test what the checksum of a file consisting of
a single byte with the high bit set? On the "modern" implementations it
is the same as the value of the byte [e.g. 255] in both algorithms.
More information about the TUHS
mailing list