From: mash@mips.com (John Mashey)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 9 Apr 1992 01:11:17 GMT
Organization: MIPS Computer Systems, Inc.
NNTP-Posting-Host: winchester.mips.com

In article <1992Apr8.184814.27845@bert.eecs.uic.edu> solworth@bert.eecs.uic.edu (Jon Solworth) writes:
>>A: the RISC addressing modes need at most an add of 2 inputs to create
>>the address, and (depending on the design) may well use the standard
>>ALU to generate the address.

>>The proposed addressing mode needs to add 3 distinct inputs, which probably
>>means back-to-back adds *before* the data address is available. There is
>>a good chance that this could be in the critical path for many pipelined
>>designs.

>I find myself almost always agreeing with John Mashey, but not this time.
>Frankly, I don't see anything *fundamentally* different --- the above statement
>is like saying several years ago that multiply instructions are fundamentally
>different -- they are not, they just take more hardware to build efficiently.
>The addressing instruction could be executed efficiently with a carry-save
>adder and need not use the adder used in the ALU.

>Also, it is OK to increase the critical path in a RISC (or any other processor)
>if the added functionality reduces average computation time.

Sorry, I got several emails; I'd been in a litle hurry when I wrote that,
and should have explained more. 

1) Of course it is OK to increase the critical path time if it gains
performance.

2) Let me say what I meant when I said *fundamentally* different:
this includes both architecture and implementation issues.  I would
say that integer add and integer multiply are *fundamentally* different,
simply because it is very likely that in most reasonable implementations,
multiply will take logner than add.  This is not to say you couldn't
invent something otherwise. (I.e., my definition of fundamental here
wasn't "fundamental, like the speed of light is the speed of light",
i.e., a science definition, but more like an engineering definition.

3) In any case, several people pointed out, of course, that one could
have a 3-input adder.  And here, I should have mentioned that, but I was
in a hurry.  The issue is:
	a) If I have this address mode, I get less instructions.
	b) If I do it with a 3-input adder:
		I'll add gates and gate delays
	but perhaps worse:
		I'll need another bus, and depending on the technology,
		this might lead to awkward layout issues.  [As has been
		noted in this newsgroup in the past, wires don't shrink
		as fast as transistors...]
		Obviously, this is especially relevant in single-chip designs.
	c) And so, if the layout issues are awkward, then I'll end up with
	doing it with 2 separate adds.
[This is what I was thinking, but condensed it too much, sorry.]

4) So ... in any of the architectures that support this mode, perhaps
people can point out implementations where the cycle time of:
	[Ra, Ri<<size, d] and [Ra, 0, d] are the same.
There may be some; any of the ones I've looked at usually end up with
an extra clock cycle, implying that you've got a 2-input adder in there,
not 3....

Anyway, we shouldn't argue about the definition of *fundamental*, more to
the point is why most people have *not* implemented this mode, or if
implemented it, ended up with a 2-input adder...
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS:	MIPS Computer Systems M/S 5-03, 950 DeGuigne, Sunnyvale, CA 94086-3650
Newsgroups: comp.arch