Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!pesnta!hplabs!hpda!hpisoa2!hpitg!ubc-cs!ludemann@ubc-cs
From: ludemann%ubc-cs@ubc-cs.UUCP
Newsgroups: net.arch
Subject: Re: oops, corrupted memory again!
Message-ID: <231@ubc-cs>
Date: Sat, 3-May-86 02:42:00 EDT
Article-I.D.: ubc-cs.231
Posted: Sat May  3 02:42:00 1986
Date-Received: Sun, 11-May-86 15:47:35 EDT
Lines: 25

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.