Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!elroy.jpl.nasa.gov!lll-winken!taco!mcnc!duke!drh
From: drh@duke.cs.duke.edu (D. Richard Hipp)
Newsgroups: comp.arch
Subject: Re: Clarification on 3 Addr vs 2 Addr Archs
Message-ID: <673707950@romeo.cs.duke.edu>
Date: 8 May 91 13:05:51 GMT
References: <1991May7.175646.25449@clipper.ingr.com> <1991May7.195932.8770@rice.edu> <1991May7.222645.14128@sequent.com>
Organization: Duke University Computer Science Dept.; Durham, N.C.
Lines: 28

In article <1991May7.222645.14128@sequent.com> johnv@sequent.com writes:
>[P]ure 3-address machines (ones without 2-address
>abbreviated forms) tended to have needless information.  Most programs
>do not require three address instructions.  Pure 2-address machines were
>much better than pure 3-address ones -- occasionally a 2-address machine will
>need to have a 'useless' instruction just to get the arithmetic done, but it
>is seldom.

I once proposed an architecture that featured "2.5" addresses, instead of the
usual 2 or 3.  Each instruction contains two complete register numbers, call
them A and B, as in a conventional 2-address machine, plus one extra bit
which indicated whether the third address (the destination) should be the
same as A or should be register zero (the accumulator).  In other words,
operations could be of two forms:

            r[A] = r[A] op r[B]

or

            r[0] = r[A] op r[B]

The idea was that the lack of a third address saved on instruction bandwidth,
but the option of using r[0] as the destination eliminated many unnecessary
MOV instructions.

This was only an idea, and was never tested.  I would be interested to hear
if John Van Zandt, or anyone else, has ever looked at this addressing scheme
and what they found after looking at it for a while.