Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!decwrl!apple!snorkelwacker!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!tcdcs!swift.cs.tcd.ie!vax1.tcd.ie!rwallace
From: rwallace@vax1.tcd.ie
Newsgroups: comp.arch
Subject: Re: Architecture questions
Message-ID: <6838.26e7f109@vax1.tcd.ie>
Date: 7 Sep 90 19:12:09 GMT
References: <10057@goofy.Apple.COM> <2516@l.cc.purdue.edu>
Organization: Computer Laboratory, Trinity College Dublin
Lines: 46

In article <2516@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) 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.
> 
> 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.

Consider the following kinds of operations:

1. Scientific and engineering work (floating-point)

2. Text processing (byte addressing)

3. Transaction processing (floating-point, bytes and fixed-length integers)

4. Graphics (best done in chunks as large as the CPU can handle, using barrel
   shifters and masking)

5. Compiling (integers and pointers)

 - in no particular order. These make up something over 99% of all computation.
Hence hardware is designed to make them fast. This means dealing with
floating-point, integers and bytes fast. To be sure you could probably list 50
different kinds of algorithms that would benefit from bit addressing but these
make up less than 1% of the computation that gets done, and the extra hardware
would slow down other operations and increase costs. Why should 99% of users
pay in money and time for something that will improve processing speed for 1%?

-- 
"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
rwallace@vax1.tcd.ie