Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!cs.utexas.edu!sm.unisys.com!ucla-cs!arman
From: arman@oahu.cs.ucla.edu (Arman Bostani)
Newsgroups: comp.arch
Subject: Re: Binaries and Max Speed
Message-ID: <19240@shemp.CS.UCLA.EDU>
Date: 1 Jan 89 04:43:33 GMT
References: <22745@apple> <2700003@prisma> <5847@polya.Stanford.EDU>
Sender: news@CS.UCLA.EDU
Reply-To: arman@cs.ucla.edu (Arman Bostani)
Organization: UCLA Computer Science Department
Lines: 25

In article <5847@polya.Stanford.EDU> andy@solitary.Stanford.EDU (Andy Freeman) writes:
>In article <2700003@prisma> mo@prisma writes:
>[More on the discussion about SPARC runtime stall vs MIPS NOPs:
> Dave thinks that MIPS will be disadvantaged because a binary
> compatible SPARC that manages to avoid load stalls will run
> 3% faster than one that doesn't, while the NOPs will always
> be there in MIPS code that isn't recompiled for an implementation
> that can avoid load stalls.]
>>Running the same binaries, but faster, is clearly a win.
>
>I don't know of any applications where one can't recompile to get the
>last 3% if it is really important. -- stuff deleted --

In this case, I don't even see a reason for recompilation of source
programs. One can always write a "relatively" simple program to get
rid of the NOPs. 






-- Arman Bostani // UCLA Computer Science Department // +1 213-825-3194
	3417 Boelter Hall // Los Angeles, California 90024-1596 // USA
	arman@CS.UCLA.EDU   ...!(ucbvax,rutgers)!ucla-cs!arman