Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!unmvax!ncar!gatech!purdue!decwrl!hplabs!hpfcdc!hpldola!hp-lsd!prisma!mo
From: mo@prisma
Newsgroups: comp.arch
Subject: Re: Re: questionable nos.--SPARC vs. MIPS on gcc
Message-ID: <2700003@prisma>
Date: 29 Dec 88 16:45:00 GMT
References: <22745@apple>
Lines: 40

>/* Written  3:59 pm  Dec 26, 1988 by baum@apple in prisma:comp.arch */
>[]
>>In article <1117@raspail.UUCP> dsc@raspail.UUCP (Dave Christie) writes:
>>
>>In article <22745@apple.Apple.COM>, baum@Apple.COM (Allen J. Baum) writes:
>>A lot of stuff that I quite agree with, and: 
>>
>>>    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.
>>
>>This is precisely what the MIPS code reorganizer does...
>
> Of course it does. And, where it fails, it must insert a no-op. SPARC doesn't,
>and its hardware will insert a cycle. The original article tried to make the
>point that the architectural interlock meant that some implementations of SPARC
>would not require that cycle. My point was that in these situations only a
>very complex machine that examined multiple instructions simultaneously in
>hardware, and could execute instructions out of order would be able to avoid
>the interlock cycle, and that MIPs could spend that kind of hardware, and
>create 0-cycle no-op instructions to have the same effect.
>
>--
>		  baum@apple.com		(408)974-3385
>{decwrl,hplabs}!amdahl!apple!baum
>/* End of text from prisma:comp.arch */

Sorry folks, but you don't have to do the full-blown
superscalar "multiple instructions per cycle" to have non-stalling
loads.  Further, the fact that the SPARC doesn't INSIST the
compiler put NOPs in there means that the binaries for the
existing SPARC processors will run faster, without recompilation,
on a machine which can usually avoid the load stalls.

Running the same binaries, but faster, is clearly a win.

	-Mike