Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cmcl2!beta!hc!ames!acornrc!rbbb
From: rbbb@acornrc.UUCP
Newsgroups: comp.arch
Subject: Re: What should be in hardware but isn't
Message-ID: <461@acornrc.UUCP>
Date: Thu, 1-Oct-87 19:14:27 EDT
Article-I.D.: acornrc.461
Posted: Thu Oct  1 19:14:27 1987
Date-Received: Sat, 3-Oct-87 06:39:44 EDT
References: <581@l.cc.purdue.edu> <18336@amdcad.AMD.COM> <582@l.cc.purdue.edu> <2207@umn-cs.UUCP>
Organization: Acorn Research Centre, Palo Alto, CA
Lines: 18
Summary: Look at the IBM 801-related literature

In article <2207@umn-cs.UUCP>, stachour@umn-cs.UUCP (Paul Stachour) writes:
> However, the biggest problem getting support is finding relevent
> benchmarks.
  ...
> But try to find a benchmark with lots of good array-checking in it.
> Unless the program was written in Algol for a B55xx or PL/I for a
> GE6xxx, you probably won't.  So putting array-checking into hardware
> (to make it reasonable for all programmers to do something which
> most of them know they should, but don't) will not happen, because
> the benchmarks will not contain code that checks array bounds.

If you check some of the IBM 801 and 801-related literature, I believe you
will find a discussion of optimizations that (safely) remove checking code,
so at least someone has thought about this problem.  Running a language
with array bounds checking the 801 (in combination with the PL8 compiler)
ran very well.  Again, RISC wins (with a clever enough compiler).

David Chase