Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: Interlocked Pipelines - basic questions
Message-ID: <3298@crdos1.crd.ge.COM>
Date: 27 Mar 91 19:30:30 GMT
References: <1991Mar26.171547.2400@sj.nec.com> <1991Mar26.213709.9246@zoo.toronto.edu>
Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen)
Organization: GE Corp R&D Center, Schenectady NY
Lines: 32

In article <1991Mar26.213709.9246@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:

| >1.  What does the interlocking refer to ?
| 
| To having an instruction which needs not-yet-available data wait around
| until the data is on hand.  The alternative is to require the compiler
| to ensure that the situation never happens, by generating code that
| explicitly stalls when needed results would not be ready in time.

  An example is register scoreboarding, where operations which are going
to modify the contents of a register set a flag such that any subsequent
instruction which uses that register for input will stall.

Consider:
  x1:	mov	memloc1,r2
  x2:	mov	memloc2,r3
  x3:	add	r2,#1,r4
  x4:	sub	r4,r3,r5
  x5:	mov	r5,memloc3

Note that the compiler has put the use of r2 before the use of r3. If
the load from memory has not completed when {x3} starts, it stalls until
the load is complete.

In a machine with lots of parallelism {x4} could be started, since {x2}
may complete first due to caching. However it needs the r4 result of
{x3} so it stalls, too. If there were an instruction to put after {x3} a
good compiler would have done it, since {x3} must complete before {x4}.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
        "Most of the VAX instructions are in microcode,
         but halt and no-op are in hardware for efficiency"