Path: utzoo!attcan!uunet!lll-winken!ames!amdcad!rpw3
From: rpw3@amdcad.AMD.COM (Rob Warnock)
Newsgroups: comp.arch
Subject: Re: Register Scoreboarding
Message-ID: <25608@amdcad.AMD.COM>
Date: 12 May 89 14:47:16 GMT
References: <8905120628.AA08299@decwrl.dec.com>
Reply-To: rpw3@amdcad.UUCP (Rob Warnock)
Organization: [Consultant] San Mateo, CA
Lines: 31

In article <8905120628.AA08299@decwrl.dec.com> neideck@nestvx.dec.com writes:
+---------------
| In article 10198 henry@utzoo.uucp (Henry Spencer) writes:
| >>Clamping the whole CPU on cache miss isn't a technique that can survive...
| >>  I'm very curious to see what the non-scoreboard folks will do.
| >Probably pretty much what they do now:  let access and execution proceed
| >in parallel, assuming the data isn't needed right away.
| Ok, now I'm curious. What DOES a R[23]000, an AMD29000 or Sparc really do
| if there's a data cache miss on a load but there are several instructions
| behind it which aren't interested in the result.
+---------------

Assuming the natural split-I/D memory system (split caches, in this case),
and burst-mode instruction memory/cache, an Am29000 will continue to execute
instructions until either (a) the result of the load is needed, or (b) the
pipeline stalls waiting to start another "primary access" [since there's
only one address bus], which could be due either to a jump which misses
in the Branch Target Cache or another load/store which wants to start.

[While in theory, with really good load scheduling, you could thus avoid
the stall entirely, in practice you typically run on for only a few more
cycles before stalling, since in "general-purpose" code it's hard to schedule
a load far enough ahead to absorb a cache miss.]


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403