Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!dayton!umn-cs!stachour
From: stachour@umn-cs.UUCP
Newsgroups: comp.arch
Subject: Re: What should be in hardware but isn't
Message-ID: <2207@umn-cs.UUCP>
Date: Mon, 28-Sep-87 22:22:41 EDT
Article-I.D.: umn-cs.2207
Posted: Mon Sep 28 22:22:41 1987
Date-Received: Fri, 2-Oct-87 02:17:17 EDT
References: <581@l.cc.purdue.edu> <18336@amdcad.AMD.COM> <582@l.cc.purdue.edu> <704@winchester.UUCP>
Organization: University of Minnesota, Minneapolis
Lines: 47
Summary: Yes, but the benchmarks are biased because of the past.


> In article <582@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
> ...
> 
> As noted before here, a plausible way to design a computer is:
> 
> 1) Pick a REPRESENTATIVE set of benchmarks.
> 2) Do a first-cut architecture, based on past experience.
> 3) Do compilers.
I've NEVER seen anyone design compilers for a machine that is only
being similated, and chose the architecture of the hardware based
on measurement, and build the machine later. (Well, one exception,
Multics many years ago, but that design set goals seldom met now.)
> 4) Add or delete features,
>       measuring the impact by running compiled/assembled
> code through architectural simulators.
> 5) Iterate until you can't find anything else to add that actually
> improves performance by some noticeable amount,
> or until you run out of time.
> 
> This is not a perfect recipe, of course.  For example, if the benchmark
> set is chosen poorly, bad surprises will happen. 


However, the biggest problem getting support is finding relevent
benchmarks.  For example, Bill Young's article about design &
implementation showed that unix security was broken, and all unix
systems vulnerable because of a 'bug'.  The bug causer was over-running
an array bounds.  But people don't write code that checks array-bounds.
They even choose ugly languages like C that don't check rather than
ones (like PL/I or Pascal) that do because they can't stand the
inefficiency (or so they say). Instead they write buggy programs!
It is these buggy programs used for the benchmarks, they're there...
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.


BENCHMARKS PREVENT ONE FROM REPEATING ERRORS OF THE PAST, *BUT*
THEY ARE NOT VERY HELPFUL IN GUIDING THE FUTURE.

Paul Stachour
Honeywell SCTC (Stachour@HI-Multics)
UMinn. Computer Science (stachour at umn-cs.edu)