Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!hubcap!mark
From: mark@hubcap.clemson.edu (Mark Smotherman)
Newsgroups: comp.arch
Subject: Re: Sustained Performance Computer Architecture
Keywords: instruction pipeline, instruction prefetch
Message-ID: <5242@hubcap.clemson.edu>
Date: 25 Apr 89 02:01:27 GMT
References: <14292@duke.cs.duke.edu>
Organization: Clemson University, Clemson, SC
Lines: 24

In article <14292@duke.cs.duke.edu>, ad@romeo.cs.duke.edu (Apostolos Dollas) writes:
> A new general-purpose computer architecture with sustained instruction pipeline 
> performance (regardless of program flow changes) has been developed at the 
> ... The instruction fetch and decode operations are 
> performed by multiple instruction decode units (IDU) which prefetch all 
> potentially needed instructions. The knowledge of the segments of code which 
> will potentially be needed during any portion of the execution
> is extracted at compilation time in the form of a program flow graph. 
> 
> Apostolos Dollas                  |    ad@duke.cs.duke.edu

How does this proposed architecture attack the short runlengths between
conditional branches?  Riseman and Foster thought about an infinite
resource machine in '71 or so (IEEE TC paper) and decided that they
could get a mere ten-fold speedup if they allowed 64K (yes, 64*1024)
prefetch paths.  How does compile-time info solve the power-of-two
branch path problem?  Do you profile and add compensation code (as does
Multiflow Trace)?  Do you back out of prefetched instructions when you
decide you have predicted the wrong path (as does HPS)?

Are you publishing this work?  Comp. Arch. Symp.?  ASPLOS?  IEEE TC?
-- 
Mark Smotherman, Comp. Sci. Dept., Clemson University, Clemson, SC 29634
INTERNET: mark@hubcap.clemson.edu    UUCP: gatech!hubcap!mark