Path: utzoo!attcan!uunet!husc6!bloom-beacon!apple!baum
From: baum@Apple.COM (Allen J. Baum)
Newsgroups: comp.arch
Subject: Re: questionable nos.--SPARC vs. MIPS on gcc
Message-ID: <22887@apple.Apple.COM>
Date: 26 Dec 88 22:59:18 GMT
References: <82150@sun.uucp> <22745@apple.Apple.COM> <1117@raspail.UUCP>
Reply-To: baum@apple.UUCP (Allen Baum)
Organization: Apple Computer, Inc.
Lines: 27

[]
>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