Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!xanth!lll-winken!uunet!portal!cup.portal.com!bcase
From: bcase@cup.portal.com (Brian bcase Case)
Newsgroups: comp.arch
Subject: Re: How to use silicon (was Re: Intel/MIPS Dhrystone ratio)
Message-ID: <16080@cup.portal.com>
Date: 21 Mar 89 20:03:45 GMT
References: <37196@bbn.COM> <1989Mar16.190043.23227@utzoo.uucp> <24889@amdcad.AMD.COM> <355@bnr-fos.UUCP> <27600@apple.Apple.COM>
Organization: The Portal System (TM)
Lines: 46

>Well, I'll have to slightly disagree here. Auto-increment does not cost another
>adder (for my particular definition of auto-increment); it just writes the
>result of the effective address calculation back to the base register. If you 

Yes, this is the i860's way of autoincrement for the floating-point memory
reference instructions.

>   Note that if you have a superscalar architecture, and can do two inst.
>in parallel (see the Intel 80960CA paper in newest Compcon proceedings), you
>can do this kind of thing as a matter of course; but its a lot more expensive
>to do it that way- you do need a separate read port and adder, as well as a 
>write port. 

Exactly my point about superscalar.  But note that for the expense of the
added data path (I assume it is essentially a duplicate of the primary
integer (and/or) floating-point pipe), you can now execute *any two*
instructions that don't have deliterious dependencies.  Sure, adding only
the hardware needed for auto-increment is cheaper, but do you really want
that garbage in your architecture forever?  When you do go to a super-
scalar implementation (and you will, whomever you are, just to keep up
with the joneses), you now have two data paths that have the added
complexity of auto-increment.  Super-scalar is a good argument for simple
architectures.

>It's probably time to dust off those
>benchmarks and see how often it occurs, and how many cycles it will save.

Well, I'm all for simulation and experimentation.  If it is better and the
cost now and in the future is not prohibitive, then great.  But it ceratainly
isn't clear that auto-increment is the right thing!  My position is that it
is reasonably clear that one should be skeptical.

>   Since this kind of operation is used almost exclusively inside a loop,
>it has quite a bit of leverage.

Yes, this is true.  This is why one would like to look at the idea seriously.

>   Besides, who says you can't find soething else to
>do with the extra write port when you're not doing address updates?

I'm surprised to hear you say that!  I think a more realistic outlook is
to say that "Besides, who says you *can* find something else to do with
the extra write port."  Conjecturing, instead of proving, that an added
feature (with a significant cost) can be used for something else does not
constitute the rigorous persuit of good computer architecture.  Shame!  :-)
:-) :-) :-) :-)