Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!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.212103.363@rice.edu> Date: 9 Oct 90 21:21:03 GMT References: <1990Oct9.162639.23516@rice.edu> Sender: news@rice.edu (News) Organization: Rice University, Houston Lines: 64 In article khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) writes: >By having hw support one can >execute instructions before knowing if they are legal. The MF/trace >machine lost big time when they predicted wrong .... this limits the >length of speculative traces, and the applications for which you get >speedup. >Compilers can't do everything ;> Sure they can :-) And if we could build these good compilers, think how cheaply we could build the hardware. In particular, we can arrange all sorts of optimistic execution. Imagine some hypothetical machine that can issue one FLOAT and one INT instruction per cycle. IF we've got code like this int-1 int-2 int-3 int-4 if (something) { float-1 float-2 float-3 store result } float-4 int-5 int-6 ... We could rearrange it (perhaps) into int-1, float-1 int-2, float-2 int-3, float-3 int-4, float-4 if (somthing) { store result } int-5 int-6 Generally, we can hoist computations from one branch that set registers that are dead on the "other" branch or store into a dead location (on the other branch). We need to be careful to avoid traps. Note that there's no cost if the branch isn't taken if we only hoist operations to fill unused slots. This (I believe) differs from the trace scheduling philosophy which is more aggressive. In general, we need to be careful about fatally increasing register pressure. The i860's exposed pipeline provides an elegant way out, allowing simple aborts of optimistic computations by ignoring what's partially computed in the pipe. -- Preston Briggs looking for the great leap forward preston@titan.rice.edu