Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!voder!apple!bcase
From: bcase@apple.UUCP (Brian Case)
Newsgroups: comp.arch
Subject: Re: Condition Codes in General Registers
Message-ID: <7454@apple.UUCP>
Date: 22 Feb 88 00:39:23 GMT
References: <6834@sol.ARPA> <780004@otter.hple.hp.com>
Reply-To: bcase@apple.UUCP (Brian Case)
Organization: Apple Computer Inc., Cupertino, USA
Lines: 44

In article <780004@otter.hple.hp.com> kers@otter.hple.hp.com (Christopher Dollin) writes:
>In view of this discussion on the merits or otherwise of condition codes,
>especially as applied to RISCy machines, I wonder what the assembled multitudes
>think about the architecture of the Acorn Risc Machine (ARM)?
>
>The critical points about the ARM from this point of view are (a) it is based
>on condition codes rather than compare-and-branch; (b) the register operations 
>set the CCs *optionally*; (c) *every* instruction is conditional, so some IF
>statements can be implemented with no branching at all; for example
>
>    abs(x) -> x
>
>can be implemented as
>
>    TEQ     x, #0       ; tell me about (register) x 
>    RSBMI   x, #0       ; if it's <0 then 0-x -> x (reverse subtract)

Ah!  A very good question indeed.  The ARM does indeed gain some advantage
in some cases.  Architecting (some cringe at such language) arithmetic ops
this way (i.e., setting them only if the instruction says to do so) fixes
one of the major problems with condition codes:  One or several instructions
can separate the instruction that sets the CCs and the instruction that uses
the CCs.  (The Berkely RISCs have this feature, don't they?)  If you look
at real code, you'll see that the ability to conditionally execute any
instruction saves some jumps.

My biggest complaints about the ARM are:  it can name only 16 registers,
part of the PC is taken up by some status bits (to allow much simplified
internal interrupt return sequencing), and the use of traditional CCs may
cause problems for future aggressive implementations, i.e. the kind of
implementation that exploits out-of-order or multiple-instruction-at-a-
time techniques.  Other little complaints center around the somewhat
longer critical path in the execute pipeline stage (barrel shift in series
with ALU) that might very well cause the ARM to lag other processors in
clock rate and the addressing modes (post-/pre- increment/decrement will
cause a little implementation complexity in a more heavily pipelined
implementation; abort/restart may be a pain).

The ARM is probably one of the absolute best processor choices available
for really low-cost, medium-performance (where medium now means 2x to 3x
cheap 68020 system) embedded applications.  However, with only 16
registers and no clear commitment to "aggressive" implementations by
anyone (where are these implementations?  the ARM has been available for
a _long time_ by most RISC standards), I can't imagine choosing it for the
main CPU of anything that has to last through several generations.