Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!tut.cis.ohio-state.edu!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.arch
Subject: Re: Clarification on 3 Addr vs 2 Addr Archs
Message-ID: <25157@as0c.sei.cmu.edu>
Date: 8 May 91 13:08:16 GMT
References: <1991May7.175646.25449@clipper.ingr.com>
Reply-To: firth@sei.cmu.edu (Robert Firth)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 72

Sigh.  Let me point out first that one cannot decide which
architecture is "best" in isolation.  It is necessary to
consider application domain, programming language, language
use styles, compiler effectiveness, and a host of hardware
issues.

However, here are some numbers; make of them what you will.
Some are from my own analyses of the Vax-11 and PE-3200
architectures, back when I wrote compilers for those machines;
others are taken from Daniel Klein's and my evaluation of
the MIPS machine, published as SEI Technical Report
CMU/SEI-87-TR-25.

First question: if you have a machine with true 2-address and
3-address modes uniformly, how many of each will you use?  An
approximate answer can be given from the VAX numbers, which tell
me that, where the alternatives exist, about 18% of operations
take three addresses rather than two.  If the 3-address modes did
not exist, approxmately 6% more move instructions would be
generated, for a code expansion of about 2%.

Second question: if you have a machine where the destination and
one operand must be registers, how much do you lose if they are
required to be the same register?  An approximate answer can be
found by looking at the PE-3200, which forces destination and
left operand to be in the same register, and counting the number
of register shuffles or operand reloads caused because the left
operand has been destroyed.  The answer is that, of all diadic
operations, approximately 14% destroy an operand you don't want
destroyed.  The extra instructions to preserve or reload this
operand (you reload if it's no slower since that sometimes
saves a register) yield a code expansion of about 4%.

Final question: on a machine like the MIPS, where the address
modes do not span memory, you must sometimes construct a
'long' address by adding a 32-bit offset to a base register.
In other words, you can't say

	load temp, #abcdefgh(base)

you must say

	add temp, base, #abcd0000
	load temp, #efgh(temp)

Clearly, this needs a three-operand add instruction.  If your
machine looks like the MIPS, but has only a two-operand add, you
need an extra register shuffle to avoid destroying the value in
base.  Our figures showed that about 7% of loads, or about 2%
of all instructions, fell into this category, so that 2% is the
code expansion you are facing.

My conclusions:

(a) It is not worth implementing full 3-address mode a la Vax

(b) For a one-address general-register machine, the cost of
    always destroying the left operand is reasonable, and
    I think the gain in architectural simplicity justifies it

(c) For a load/store machine, it is better to have more registers
    and only two-address than fewer registers and three-address.
    However, that usually isn't the trade-off.

Finally: *make a choice and stick to it*.  Worse than either
choice is a machine with two or more forms of every operation, one
that takes two registers and one that takes three.  Keep it simple
and orthogonal, and make it run like a bat out of ASPLOS.

Hope that helps

Robert Firth