Path: utzoo!mnetor!uunet!husc6!rice!titan!david
From: david@titan.rice.edu (David Callahan)
Newsgroups: comp.arch
Subject: Re: Yield of core-MIPS chips [MIPSCo yield? && Other Issues]
Message-ID: <629@ra.rice.edu>
Date: 31 Mar 88 04:49:45 GMT
References: <2904@omepd> <751@esunix.UUCP> <2089@ho95e.ATT.COM> <10170@steinmetz.steinmetz.ge.com>
Sender: usenet@rice.edu
Reply-To: david@titan.rice.edu (David Callahan)
Organization: Rice University, Houston
Lines: 24

In article <10170@steinmetz.steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>Seriously, when I see people claim that they are taking a pseudocode
>generated by <your favorite compiler> and doing a translate and optimize
>so they can run it on RISC, I wonder why all the fuss? In a few more
>years, perhaps ten, we will know how to build a translator in silicon
>which does a better and faster job of translation, NOP fills, etc, than
>we are now doing in software. I think we will still do a better job with
>software at that time, but it may not be cost effective.
>	bill davidsen		(wedu@ge-crd.arpa)
>  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
>"Stupidity, like virtue, is its own reward" -me

Seriuosly, when people advocate doing things at run-time which we
already know can be done effectively at compile time (once per program!)
I wonder.  The lessons from RISC and VLIW/TRACE seem to be: if you can
move a runtime decision (like instruction scheduling) into the compiler
not only does the hardware become simpler and hence faster, but that's one
less thing to do at run-time. If we could build silicon to do a
``better and faster job ...'' then we pobably will be able to build
one helluva compiler :-).


David Callahan
Rice Univeristy