Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site petsd.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!vax135!petsd!joe
From: joe@petsd.UUCP (Joe Orost)
Newsgroups: net.arch
Subject: Re: Re: Where to do stack checking, etc.
Message-ID: <651@petsd.UUCP>
Date: Wed, 25-Sep-85 09:13:41 EDT
Article-I.D.: petsd.651
Posted: Wed Sep 25 09:13:41 1985
Date-Received: Fri, 27-Sep-85 03:12:25 EDT
References: <796@kuling.UUCP> <1713@orca.UUCP> <1599@peora.UUCP> <335@ihlpl.UUCP> <2384@uvacs.UUCP> <1232@hcrvx1.UUCP> <3563@tellab2.UUCP>
Reply-To: joe@petsd.UUCP (Joseph M. Orost)
Organization: Perkin-Elmer DSG, Tinton Falls, N.J.
Lines: 38
Keywords: parity error, uninitialized data
Summary: What about virtual memory or byte operations

In article <3563@tellab2.UUCP> thoth@tellab2.UUCP (Marcus Hall) writes:
>In article <2384@uvacs.UUCP> mac@uvacs.UUCP (Alex Colvin) writes:
>>I'm still looking for a machine that will trap references to uninitialized
>>data.
>
>Hasn't this been implemented in some system by faking a parity error on all
>uninitialized data.  After trapping on the parity error, if what's there is
>the same as the bit "special" pattern, it's a pretty good guess that it's
>uninitialized (as distinguished from a real live parity error).
>
>I'm fairly sure that I have seen this somewhere, but I'm not quite sure where
>it was.  It requires being able to write a word with bad parity (not too
>hard, I guess) and is essentially very kludgy, but it doesn't cost an extra
>bit just to tell if the area is uninitialized.

What happens on a machine with virtual memory, or even swapping?  How do you
swap out/in a parity error?  Do you have to lock in all pages that have
parity errors anywhere jammed in them?

What about an uninitialized array of bytes.  Say you want to set the first
byte = 0.  So, you execute a store byte instruction.  Now, most processors
that I know of do a store byte by doing a load fullword, inserting the byte,
and doing a store fullword.  BANGO!  a parity error!

No wonder Ada doesn't require unitialized variable checking!

				regards,
				joe

--

 ........        .........	Full-Name:  Joseph M. Orost
 .       .       .		UUCP:       ihnp4!vax135!petsd!joe
 . ......   ...  ........	ARPA:	    vax135!petsd!joe@BERKELEY
 .               .		Phone:      (201) 758-7284
 .               .........	Location:   40 19'49" N / 74 04'37" W
				US Mail:    MS 313; Perkin-Elmer; 106 Apple St
					    Tinton Falls, NJ 07724


Brought to you by Super Global Mega Corp .com