Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watmath.UUCP
Path: utzoo!watmath!atbowler
From: atbowler@watmath.UUCP (Alan T. Bowler [SDG])
Newsgroups: net.arch
Subject: Re: RISC
Message-ID: <14882@watmath.UUCP>
Date: Thu, 6-Jun-85 13:54:55 EDT
Article-I.D.: watmath.14882
Posted: Thu Jun  6 13:54:55 1985
Date-Received: Fri, 7-Jun-85 02:22:56 EDT
References: <639@vax2.fluke.UUCP> <2743@nsc.UUCP> <576@terak.UUCP> <611@lll-crg.ARPA> <591@terak.UUCP>
Reply-To: atbowler@watmath.UUCP (Alan T. Bowler [SDG])
Organization: U of Waterloo, Ontario
Lines: 21
Summary: 

In article <591@terak.UUCP> doug@terak.UUCP (Doug Pardee) writes:
>
>I thought this too, until I looked into some RISC machines.  They use
>32-bit instruction words, twice as wide as the equivalent instructions
>in, say, the 680xx and 320xx cpus.
>
Actually a brief examination of code actually produced by compilers
on a 68000 shows that the compiler seldom generates anything but
32 bit instructions.  (including addressing).  It generates 16 bit
instructions formats less often than it generates 48 bit ones (absolute
address).
   This is not to say I am a big fan of what is currently being called
RISC.  It strikes me that a good deal of the claims about performance,
don't jive with what happened, and where there were actual performance
gains they where attributed to the wrong part of the archetecture.
   I am also not a big fan of very complex instructions either.  My
experience shows that supplied "CALL" instructions that do any
more than store a return address in a register make subroutine call
design difficult, and usually slower.
  There is entirely too much religious faith and too little fact in
most "RISC" discussion.