🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #21232

Re: Register Scoreboarding

#21232
From: John Mashey
Date: Sat, 13 May 1989 00:22
35 lines
2474 bytes
In article <23884@shemp.CS.UCLA.EDU> marc@cs.ucla.edu (Marc Tremblay) writes:
>In article <19463@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>>	b) Load-misses (R3000s use write-thru caches, so there aren't really
>>		store misses).
>Since the R3000 uses write-thru caches and 
>since the depth of the write buffer is 4, 
>I assume that "stores" stall the processor only when more 
>than 4 consecutive writes occur or whenever the buffer overflows. 
>Saving the register file on a context switch could certainly
>generate stalls if it is done sequentially (i.e without interleaving
>register stores with non-store intructions).
>From your comment I suppose that those situations do not occur very often?

Stores stall the processor whenever the write-buffer is full.
it actually takes a bit longer than 4 consecutive stores, in the simple
case, as (for example, on an M/2000), writes are retired to memory
1 word / 2 cycles.  You actually get something like 6 consecutive
writes before going into a stall-every-other-cycle state.

The register-save sequence typically has just a few stalls in it, as there
are other instructions interleaved, and it first saves the registers
that C won't, while letting those that C would be saved later.
I think the FP-regs-save sequence stalls a little more, as there's less
to do in the middle of it, but then it happens less often also.

The issue is statistically nonexistent for function calls, as relatively
few (dynamic) function calls save 6 or more registers.

Block-copies do their best to interleave the loop overhead and reads and
writes, so they don't see it either.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Technical Details
Message-ID: <19533@winchester.mips.COM>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!apple!oliveb!pyramid!prls!mips!mash
References: <24821@lll-winken.LLNL.GOV> <GRUNWALD.89May9113443@flute.cs.uiuc.edu> <3288@orca.WV.TEK.COM> <19463@winchester.mips.COM> <23884@shemp.CS.UCLA.EDU>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!apple!oliveb!pyramid!prls!mips!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: Register Scoreboarding
Message-ID: <19533@winchester.mips.COM>
Date: 13 May 89 00:22:25 GMT
References: <24821@lll-winken.LLNL.GOV> <GRUNWALD.89May9113443@flute.cs.uiuc.edu> <3288@orca.WV.TEK.COM> <19463@winchester.mips.COM> <23884@shemp.CS.UCLA.EDU>
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 35