Re: The RISC penalty (David L Moore)
28 Dec 1995 11:59:15 -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 (1995-12-19)
Re: The RISC penalty jbuck@Synopsys.COM (1995-12-20)
Re: The RISC penalty (1995-12-21)
Re: The RISC penalty (1995-12-28)
Re: The RISC penalty (1995-12-28)
Re: The RISC penalty (1995-12-30)
Re: the RISC penalty (1995-12-30)
Re: the RISC penalty (1995-12-31)
| List of all articles for this month |

From: (David L Moore)
Newsgroups: comp.compilers
Date: 28 Dec 1995 11:59:15 -0500
Organization: Netcom
References: 95-12-063 95-12-077 95-12-103 95-12-132
Keywords: architecture, performance

> [Certain applications, such as 68K semi-compiling interpreters and
> TP kernels thrash I cache. This is worse on RISC cpus because the
> instructions contain > many wasted bits]

So, it sounds like one should build a RISC chip without many wasted
bits! There is no reason why you cannot build a RISC machine with
variable length instructions - the first RISC like machine (the CDC
6600) did just that. Variable length instructions make multi-issue
harder because you first have to find the start of the instructions,
which adds a few gate delays, but the only time this actually slows
you down is when you just mis-predicted a branch. Otherwise, it just
adds some real-estate to your instruction decoding logic.

One might want to design an architecture in which:

i) Some instructions address a limited range of registers. You might
have 32 registers but compact 16 bit instructions can only address the
first 8, so you would have 7 bits for the operation.

Access to large numbers of registers is most useful for loops since it
gives you somewhere convenient to put the invariants and induction
variables and to support instruction scheduling, which is often more
effective in loops, where you can unroll and jam, than it is in
straight-line code, providing that you do not succumb to register

So I can bring myself to believe that short form instructions with
limited register access are a win for straight-line code. Of course,
one would want full-length versions for use in loops.

ii) You might want some two address instructions. This could allow you
to address any of the 32 registers in a 16 bit opcode and still have
six bits to denote the operation. Two address architectures in general
are a pain because keeping an intermediate result always costs you a
copy, but you only need a two-address form for the last use of any

The afore-mentioned CDC 6600 had 3 banks of 8 registers and 15 bit
instruction were 3 register. There were 9 bits of register information
(3 fields of 3 bits) and the bank information was encoded in the 6 bit
operation code. Not all of the 27 possible combinations of bank were
supported and one register was identically zero to support degenerate
(two-address) forms.

Post a followup to this message

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