Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!shelby!apple!vsi1!wyse!mips!mash
From: mash@mips.COM (John Mashey)
Newsgroups: gnu.gcc
Subject: Re: Porting gcc to the new Sun SPARCstation 1 and SPARCstation 300 series
Message-ID: <19031@winchester.mips.COM>
Date: 8 May 89 18:42:08 GMT
References: <8905030323.AA27122@jato.Jpl.Nasa.Gov> <102542@sun.Eng.Sun.COM>
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 19

In article <102542@sun.Eng.Sun.COM> david@sun.com (J.R. ``Bob'' Dobbs) writes:
>In article <8905030323.AA27122@jato.Jpl.Nasa.Gov> earle@JATO.JPL.NASA.GOV
>(Greg Earle - Sun Software Support) writes:
>>On the other hand, the new SPARCstation machines have a write-through cache.
>>Both write buffers are only one write deep.  On the SPARCstation-1, it is
>>32 bits deep; on the SPARCstation/SPARCserver 300 series, it is 64 bits deep.
>>Because of this, back-to-back writes can tie up the memory bus.
>
>For the same reason, you shouldn't schedule a load right after a store.

Hmmm.  Surely this isn't as important as spreading the stores, i.e.,
you'd expect that most loads will hit in the cache, and hence will not
conflict with stores,  unless there's something very unusual in the
memory/cache design.
-- 
-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