Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!vail!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.arch
Subject: Re: Parity hardware for uninitialized variable checking?
Summary: Correcting another Seymour myth
Message-ID: <16065@vail.ICO.ISC.COM>
Date: 1 Sep 89 23:57:05 GMT
References: <12.filbo@gorn.santa-cruz.ca.us> <4322@druhi.ATT.COM>
Organization: Interactive Systems Corp, Boulder, CO
Lines: 30

terrell@druhi.ATT.COM (TerrellE) writes in response to the idea of causing
bad memory parity on uninitialized values (long lines re-broken):

> One of the machines that Cray designed for CDC had 1's complement (not
> 2's complement) arithmetic...[description of negative 0]

Didn't ALL the machines he designed for CDC use 1's comp?

> Cray took advantage of this and made one of the 0 representations a
> designated undefined value.  The hardware would trap on an attempt to
> read a variable with this undefined value.

Not true.  Negative zero did not cause a trap.  There was a floating-point
value which would cause a trap if used as an operand--actually there were
several, but this one was distinguished by the fact that FP operations
would never generate it.  (It was the "negative indefinite"; whenever the
hardware generated an indefinite it would produce the positive form.)

But this only gives you a trap on using the uninitialized value in a
floating-point operation.  No integer operations trapped.  Even for FP
values, you could copy them around to your heart's content without
trapping--which can make it hard to find where the uninitialized value
really came from at the outset.

Negative zero could have been used--at considerable expense in the code--
as a marker for uninitialized integers.  Compiled code would have to look
for it, and it would take two tests.  But (as with -indef) a negative zero
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...Are you making this up as you go along?