🚀 go-pugleaf

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.