Path: utzoo!mnetor!uunet!husc6!uwvax!dogie!uwmcsd1!leah!itsgw!batcomputer!cornell!uw-beaver!tektronix!orca!tekecs!frip!andrew
From: andrew@frip.gwd.tek.com (Andrew Klossner)
Newsgroups: comp.arch
Subject: To interlock or not to interlock (was Re: Instruction Scheduling)
Message-ID: <9858@tekecs.TEK.COM>
Date: 23 Mar 88 07:44:27 GMT
References: <12513@sgi.SGI.COM> <12560@sgi.SGI.COM> <12678@sgi.SGI.COM> <45292@sun.uucp>
Sender: nobody@tekecs.TEK.COM
Organization: Tektronix, Wilsonville, Oregon
Lines: 15

[Removing "comp.misc" from newsgroup list; it's bad practice to
cross-post to both a miscellaneous and a non-misc group.]

A situation in which hardware stalling on a scoreboard is a big win is
in loading possibly-cached data.  We have a Motorola 88000-based
workstation on which a load takes 3 cycles if the target is in cache
and 9 (or more!) cycles otherwise.  The compiler often can't determine
whether the target of a particular instruction will be in cache;
sometimes the same instruction will fetch from memory the first time
through a loop and from cache the next time.  Without hardware
interlocks, the compiler would pretty much be forced to insert eight
instructions between a load and the next reference to that register.

  -=- Andrew Klossner   (decvax!tektronix!tekecs!andrew)       [UUCP]
                        (andrew%tekecs.tek.com@relay.cs.net)   [ARPA]