Path: utzoo!utgpu!cunews!bnrgate!bwdls58!mlord
From: mlord@bwdls58.bnr.ca (Mark Lord)
Newsgroups: comp.arch
Subject: Re: Snakebytes (long -- and poisonous?).
Message-ID: <6372@bwdls58.bnr.ca>
Date: 4 Apr 91 13:32:57 GMT
References: <1998@kuling.UUCP> <8840022@hpfcso.FC.HP.COM>
Sender: mlord@bwdls58.bnr.ca
Reply-To: mlord@bwdls58.bnr.ca (Mark Lord)
Organization: Bell-Northern Research, Ottawa, Canada
Lines: 26

In article <> cag@hpfcso.FC.HP.COM (Craig Gleason) writes:
<...                   All loads and I-fetches take one cycle.  There
<is a load-use penalty of one cycle when the instruction after the load
<uses the load data as an operand.
<
<Stores take three cycles on the data cache, but if they are followed by
<non-data cache accesses, there will be no penalty.  Therefore the store
<penalty can be zero, one or two states, and the compilers can schedule
<accordingly. 

Thanks for this very useful info.  A question:  what happens with successive
stores?  We seem to have trouble avoiding a lot of these in applications 
around here (BNR), even after the optimizer has its go at things.  Mostly these
occur early in procedures which need to save lots of parameters before invoking
another procedure as the first activity in the current procedure (am I confused
or what!).  As such, the optimizer has trouble spreading them out, and quite
often they end up clumped together:  store,store,store,store. 

What sort of penalty does this incur cycle-wise (and why) ?
-- 
MLORD@BNR.CA  Ottawa, Ontario *** Personal views only ***
begin 644 NOTSHARE.COM ; Free MS-DOS utility - use instead of SHARE.EXE
MZQ.0@/P/=`J`_!9T!2[_+H``L/_/+HX&+`"T2<TAO@,!OX0`N1(`C,B.P/.DS
<^K@A-<TAB1Z``(P&@@"ZA`"X(27-(?NZE@#-)P#-5
``
end