Path: utzoo!mnetor!uunet!steinmetz!sunset!oconnor
From: oconnor@sunset.steinmetz (Dennis M. O'Connor)
Newsgroups: comp.arch
Subject: Re: 16 & 32 bit vs 32 bit only instruct
Message-ID: <9728@steinmetz.steinmetz.UUCP>
Date: 29 Feb 88 18:12:52 GMT
References: <2574@im4u.UUCP>
Sender: news@steinmetz.steinmetz.UUCP
Reply-To: sunset!oconnor@steinmetz.UUCP
Organization: GE Corporate R&D Center
Lines: 33

An article by aglew@ccvaxa.UUCP says:
] 
] The big thing about three address instructions is that
] it lets you take maximal advantage of a multiport register
] file. Ie. if you *HAVE* to say A=B+C, then A=C;A+=C makes you
] pay a penalty. And there is always hope that compilers will
] start using the 3 address instructions to avoid dependencies.

Many operations in load-store machines are of the load-it,
modify-it, maybe modify-it-again, then maybe store-it. These
types of operations will never want three-address formats.
The original (destroyed in two-address) value is never reused.
Our research indicated that this was the most common case.
For these types of data, dependencies can't be avoided.

] But, if you don't use them, why pay for them? Why not have a
] decoded instruction cache that takes a compact representation
] and generates the canonical form? It doesn't have to be as fancy
] as CRISP - Patterson's group had a paper on this.

It adds latency. Especially it adds to the latency of a branch. Either
you will have more post-branch slots to fill, or you will have a more
expensive cache-miss penalty. Branches seem to be about one-tenth
of all instructions.

Plus, of course, a classic RISC argument : couldn't you have found a
BETTER use for all that silicon ? A bigger cache ? More registers ? An
on-chip FPU ? UNIX-on-ROM :-) ?

--
    Dennis O'Connor			      UUNET!steinmetz!sunset!oconnor
		   ARPA: OCONNORDM@ge-crd.arpa
   (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)