Path: utzoo!attcan!uunet!husc6!bbn!apple!baum
From: baum@Apple.COM (Allen J. Baum)
Newsgroups: comp.arch
Subject: Re: questionable nos.--SPARC vs. MIPS on gcc
Message-ID: <22745@apple.Apple.COM>
Date: 23 Dec 88 03:09:39 GMT
References: <82150@sun.uucp>
Reply-To: baum@apple.UUCP (Allen Baum)
Organization: Apple Computer, Inc.
Lines: 39

[]
>In article <82150@sun.uucp> edkelly@sun.UUCP (Ed Kelly) writes:
>2) There are lots of NOPs in MIPS code. This is an ARCHITECTURAL feature. 
>NOPs are not benign. As well as the direct cycles lost, lots of NOPs is bad 
>for code density, and it increases inst. cache miss penalties(due to more
>memory accesses and greater probability of a miss).
>     Current SPARC implementations incur a clock cycle penalty for some of the
>cases where MIPS has to insert NOPs however, so counting all NOPs against MIPS
>overstates the situation. This includes the load-use interlock case(1,474,619)
>and the untaken annulled branch case(634,700). While these cycles are not 
>"architectural" many implementations will incur these penalties.

    Sorry, but I have to disagree here.
The no-ops are architectural because MIPs thought it unlikely that any
implementation could ever get away without an extra cycle in those
circumstances. Note that SPARC incurs these penalties. I predict that
they will not go away for quite a while.
    Specifically: Load/use interlock. The only way to avoid this is execution
of instructions out of order, which requires that multiple instructions be
examined in parallel, and a lot more. It this can be done, then the "Noop" can 
effectively be executed out of order as well, and its cycle will disappear.
The space it occupies is still there, but the effect on performance is 
second order, and neglible.
    The branch-delay slot annulment is a little different in that it make
take less than Herculean effort to avoid the wasted cycle. But again, that
works both ways. I'll be generous and only put half of those cycles back.

So, putting the cycles back where I believe they belong:

>			SPARC		MIPS		MIPS-SPARC
>
>Total Instructions	16,313,907	18,635,185	+2,321,278
>load interlock cycles	(1,474,619)	na
>untaken-branch annull  (  317,350
                        18,105,876      18,635,185	+  529 309
                                                      ~3% difference
--
		  baum@apple.com		(408)974-3385
{decwrl,hplabs}!amdahl!apple!baum