Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!bionet!apple!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ncar!tank!uxc!uxc.cso.uiuc.edu!urbsdc!aglew
From: aglew@urbsdc.Urbana.Gould.COM
Newsgroups: comp.arch
Subject: Re: RISC v. CISC --more misconcepti
Message-ID: <28200232@urbsdc>
Date: 5 Nov 88 22:09:00 GMT
References: <623@quintus.UUCP>
Lines: 31
Nf-ID: #R:quintus.UUCP:623:urbsdc:28200232:000:1536
Nf-From: urbsdc.Urbana.Gould.COM!aglew    Nov  5 16:09:00 1988


>/* Written 10:45 pm  Nov  2, 1988 by ok@quintus.uucp in urbsdc:comp.arch */
>...a generation of programmers has been brainwashed that Hardware Rules,
>and if some potentially useful operation is expensive it is their job
>to avoid it rather than have the hardware and compiler people get it
>right.  People are still avoiding procedure calls (and RISC designers
>are assuming that procedure calls are not deeply nested) because old
>designs made procedure calls expensive.
>
>...
>
>The bottom line is that architectures should _support_ the operations
>programmers find useful, but that some architects have shown that good
>enough support can be had by doing part of an operation in hardware,
>part in software.  Too bad about Whizzbang.
>/* End of text from urbsdc:comp.arch */

Bravo! I'm not sure about the frequency of use of multiply/divide, but
I heartily agree about procedure calls, and with the overall sentiment
that programmers should do what is best from the viewpoint of 
algorithmic efficiency, etc., and hardware should seek to support that.

Procedure calls are one of the few good ideas that Computer Science has
had. Building machines that are going to encourage people not to nest their
procedures deeply is criminal, if those machines are likely to be used
in SDI.

At Gould, we were always finding places where Berkeley and AT&T code
written for the VAX went to ridiculous lengths to avoid floating point
and integer multiply/divide. For instance, we had poor buffer cache behaviour,
using the %(2^n) algorithm.