Path: utzoo!attcan!uunet!husc6!ukma!mailrus!bbn!apple!baum
From: baum@Apple.COM (Allen J. Baum)
Newsgroups: comp.arch
Subject: Re: Re: questionable nos.--SPARC vs. MIPS on gcc
Message-ID: <23208@apple.Apple.COM>
Date: 3 Jan 89 19:53:35 GMT
References: <22745@apple> <2700003@prisma>
Reply-To: baum@apple.UUCP (Allen Baum)
Organization: Apple Computer, Inc.
Lines: 25

[]
>In article <2700003@prisma> mo@prisma writes:
>>In article <22745@apple.Apple.COM>, baum@Apple.COM (Allen J. Baum) writes:
....stuff impying that the load-use interlock can't be avoided without
    looking at multiple instructions at once....

>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.

Sorry, but I believe you are wrong. While non-stalling loads don't require
this in general, they do require it in the load-use interlock case, i.e.
where the data is used immediately after it is loaded. If you know a scheme
that can avoid this, please post (and patent it) quickly.
 In any case, the same technique can be used to make the architecturally
required NOP instruction take zero cycles, WITHOUT recompilation.
 If you have a counterexample/argument, I'd love to hear it.
--
		  baum@apple.com		(408)974-3385
{decwrl,hplabs}!amdahl!apple!baum