Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ubc-cs.UUCP
Path: utzoo!utcsri!ubc-vision!ubc-cs!ludemann
From: ludemann@ubc-cs.UUCP (Peter Ludemann)
Newsgroups: net.arch
Subject: Re: oops, corrupted memory again!
Message-ID: <231@ubc-cs.UUCP>
Date: Fri, 2-May-86 17:42:37 EDT
Article-I.D.: ubc-cs.231
Posted: Fri May  2 17:42:37 1986
Date-Received: Sat, 3-May-86 12:00:10 EDT
References: <117@prairie.UUCP> <780@bentley.UUCP>
Reply-To: ludemann@ubc-cs.UUCP (Peter Ludemann)
Organization: UBC Department of Computer Science, Vancouver, B.C., Canada
Lines: 26
Summary: 

In article <780@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes:
>[comments on overflow-checking architecture]
>         ...  What I was thinking of, though, was a computer with strict
>architecture that could be used for development and testing; when the
>program is shipped to the Real World it would presumably run on "normal"
>architecture.

A mere 7 years ago, I worked on a "real world" machine which _always_ 
had subscript range checking (and pointer validity checking) turned 
on.  It had to be very reliable (digital telephone switching).  
Definitely _not_ an AT&T product --- rather, Northern Telecom (BNR).  
I don't recall a single problem with bad pointers trashing memory.  

The machine's performance was pretty impressive (remember, this was 
1979 with a 16-bit architecture): average instruction time: 1usec 
(and most of the instructions were _not_ very RISC-y.  The only 
registers were for data and stack bases; everything else was done on 
the stack.  I don't recall any cache).  The machine had a fairly wide 
micro-code, so I think that there was very little overhead in the 
array index range checking.  

We did _all_ our programming in a dialect of Pascal.  If anyone had 
suggested turning off range checking on the production machine, s/he 
would have been laughed out of the building.  We derived great peace 
of mind from the builtin checking.