Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site opus.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!hao!nbires!opus!rcd
From: rcd@opus.UUCP (Dick Dunn)
Newsgroups: net.arch
Subject: Re: uninitialized data (and parity bits)
Message-ID: <88@opus.UUCP>
Date: Tue, 1-Oct-85 01:50:15 EDT
Article-I.D.: opus.88
Posted: Tue Oct  1 01:50:15 1985
Date-Received: Fri, 4-Oct-85 06:04:54 EDT
References: <436@uvm-cs.UUCP> <5600035@uiucdcsb>
Organization: NBI,Inc, Boulder CO
Lines: 22

>One way to trap on uninitialized memory locations is to set the parity bit
>incorrectly for uninitialized locations.  If the location is read before being 
>written, a bad parity interrupt will occur.  The Burroughs stack machines use
>this technique.

Of course, you only want to be able to do such a thing in some protected
processor mode (if at all) because if a user process can execute an
instruction which will put bad parity on one of its words, you've just
traded one class of error for another.  (Scenario:  Program goes off and
trashes an instruction into something that puts bad parity on a data word.
Megacycles and parsecs away, it finally uses the data and gets a parity
error.)

BTW, if you use the mechanism of "bad parity" as a detector for a program
using uninitialized data, haven't you (in principle) removed the usefulness
of bad parity for detecting memory errors (which is what it was designed to
detect in the first place)?  Seems that if you really want an uninit-data
value, you should add hardware tagging for that purpose rather than
usurping the purpose of some other indicator.
-- 
Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
   ...If you plant ice, you're gonna harvest wind.


Brought to you by Super Global Mega Corp .com