The RISC penalty (Duane Sand)
9 Dec 1995 19:54:46 -0500

          From comp.compilers

Related articles
The RISC penalty (1995-12-09)
Re: The RISC penalty (1995-12-17)
Re: The RISC penalty (1995-12-18)
Re: The RISC penalty -- some real data (1995-12-18)
Re: The RISC penalty (1995-12-19)
Re: The RISC penalty jbuck@Synopsys.COM (1995-12-20)
Re: The RISC penalty (1995-12-21)
[5 later articles]
| List of all articles for this month |

From: (Duane Sand)
Newsgroups: comp.compilers
Date: 9 Dec 1995 19:54:46 -0500
Organization: Compilers Central
Keywords: architecture, performance

The December 1995 issue of IEEE MICRO magazine has an interesting and
inflamatory article in its Micro View column, named "The RISC
Penalty", written by Tom Pittman. (I believe Pittman was one of the
pioneers of Tiny Basic, back in the very early days of "Dr Dobb's
Journal of Orthodontia, Running Lite Without OverByte")

Recently, Pittman has been working on faster replacements for
PowerMacs' 68K emulator, using dynamic recompilation of 68K code into
mildy-optimized PowerPC code. He and others found that recompilation
did not give the speedups they expected over simple interpretation,
when running large real programs. He says the main problem is the
excessive number of code cache misses caused by the poor code density
of RISC code. He calls the whole RISC architecture thing a fad, a
severe case of The Emperor's New Clothes. He argues for maybe going
to a byte-coded stack machine instruction set, a la Burroughs. Along
the way, he flames C compiler vendors, and claims that C is inherently
less optimizable than Pascal.
[Seems to me that the swings back and forth between CISC and RISC
architectures over the past 30 years have reflected the relative
performance of processors and memory. When processors are a lot
faster, CISC wins since decoding a fancy instruction is faster than
waiting for memory. When memory is relatively fast, RISC wins.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.