The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: random832@fastmail.com (Random832)
Subject: [TUHS] why is sum reporting different checksum's between v6 and v7
Date: Fri, 11 Dec 2015 20:07:19 -0500	[thread overview]
Message-ID: <m28u5079vc.fsf@fastmail.com> (raw)
In-Reply-To: <20151212003057.75C5B18C0CB@mercury.lcs.mit.edu>

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.




  reply	other threads:[~2015-12-12  1:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-12  0:30 Noel Chiappa
2015-12-12  1:07 ` Random832 [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-12-12  1:22 Noel Chiappa
2015-12-12  1:46 ` Random832
2015-12-12  1:50 ` John Cowan
2015-12-12  0:03 Will Senn
2015-12-12  0:10 ` Clem cole
2015-12-12  0:38 ` Random832

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m28u5079vc.fsf@fastmail.com \
    --to=random832@fastmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).