Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!uw-beaver!rice!titan.rice.edu!preston
From: preston@titan.rice.edu (Preston Briggs)
Newsgroups: comp.arch
Subject: Re: speculative execution
Message-ID: <1990Oct9.224312.2031@rice.edu>
Date: 9 Oct 90 22:43:12 GMT
References: <1990Oct9.162639.23516@rice.edu> <3431@bnr-rsc.UUCP>
Sender: news@rice.edu (News)
Organization: Rice University, Houston
Lines: 27

I wrote:
>>You could probably do it in hardware too (that it, go shooting off
>>down some code path before knowing a condition), but I expect
>>compilers can do a better job.   Think in terms of trace scheduling.

In article <3431@bnr-rsc.UUCP> bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) writes:
>Hmm, you mean your compiler can schedule code so that five instructions
>are issued to one function unit on every clock?
>There are some occasions when multiple copies of h/w can do better than
>compiler. I believe speculative execution is one.

Given the same number of functional units, with same latencies,
same number of registers, ...
I believe I can write a compiler that will make code run
faster than hardware that does speculative execution.
My version of the hardware should also be cheaper
in that it doesn't have to coordinate the multiple paths of speculation.

Why can I win?  I can look farther ahead at compilation than the
hardware can while running.

Is there some variation of hardware and software that's even quicker?
I dunno.

-- 
Preston Briggs				looking for the great leap forward
preston@titan.rice.edu