Path: utzoo!attcan!uunet!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Architecture questions
Message-ID: <2516@l.cc.purdue.edu>
Date: 6 Sep 90 13:40:17 GMT
References: <10057@goofy.Apple.COM>
Organization: Purdue University Statistics Department
Lines: 38

In article <10057@goofy.Apple.COM>, pauls@apple.com (Paul Sweazey) writes:

			.......................

> It is obvious to most that todays computing systems would not get faster 
> by having the hardware support bit-level addressing, much less an infinite 
> number of data types.  But there are entire classes of systems that don't 
> get explored (or even conceived of) because they don't map well into the 
> architectural constraints of computing systems today .

I disagree.  It is the case, of course, that if the computations are done in
the current methods with the current structures that they are likely not to
improve it other hardware is added.  But would the same algorithms be used
with these other hardware facilities.

> I am mildly surprised that brainstorms about revolutionary architectures 
> are rare in comp.arch.  We could be just a brainstorm away from the next 
> killer-micro-wave.

I am not at all surprised.  Look at the vitriol against those who suggest
that integer arithmetic is for more than addresses and loop counting.  Look
at the arguments that including such-and-such would break the current 
compilers, and conflict with the current languages.

On and off, I have suggested numerous operations which have arisen from
computational problems in probability and statistics which would be easy
in hardware and are at least moderately difficult in software.  The common
response (there have been a few exceptions) is that nobody should want
those things.  We need, instead, the view that if something can be done
easily in hardware it should, and that if the concept is not in the language,
that is the fault of the language.

This group really should be concerned with the last quoted paragraph, and
not with how to limit hardware and software.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)