Path: utzoo!attcan!uunet!lll-winken!uwm.edu!zaphod.mps.ohio-state.edu!usc!orion.oac.uci.edu!ucivax!ucla-cs!oahu.cs.ucla.edu!marc
From: marc@oahu.cs.ucla.edu (Marc Tremblay)
Newsgroups: comp.arch
Subject: Re: High-Priority Instructions
Message-ID: <37310@shemp.CS.UCLA.EDU>
Date: 26 Jul 90 17:41:02 GMT
References: <58428@bbn.BBN.COM>
Sender: news@CS.UCLA.EDU
Organization: UCLA Computer Science Department
Lines: 49

In article <58428@bbn.BBN.COM> schooler@oak.bbn.com (Richard Schooler) writes:
>  The Motorola 88100's register file has only a single write port, and
>thus on each cycle, only a single instruction can write a result.  This
>is known as the "writeback slot".  When carefully hand-scheduling code
>(and thinking about scheduling algorithms), the writeback slot can be a
>real pain, mainly because of the fixed priority scheme: if instructions
>of different latency contend for the writeback slot, then the integer
>unit gets it first, then floating-point instructions, then loads
>(roughly).  However, it often happens that loads or floating-point
>instructions are on the critical path, and can get stalled because of
>other instructions stealing the writeback slot.

It looks like Motorola did not want to deal with functional unit
latencies when instructions are issued.
Otherwise they could use a result shift register where the "writeback slot"
is reserved in advance according to the latency of the functional unit used.
Conflicts are thus resolved in advance. Collisions cause stalling of
the issuing unit.
One of the advantages of a fixed priority scheme though, is that one could
have variable latency functional units (for example an early exit multiplier).
That kind of functional unit is hard to handle with a result shift register.

>  I thus propose that instructions have a "high-priority" bit, which the
>compiler would place on critical-path instructions that would otherwise
>get delayed.  Ties between instructions of the same priority would be
>broken by the usual rules.  The scheduler could then mostly ignore the
>writeback slot.  What do you think?

Let's see, instructions are held up because other instructions
have higher priority, they will proceed only if there is an empty slot.
If there is no empty slot, that means that other instructions are producing
useful work and that the write-back slot is running at full throughput
(since there is only one instruction issued per cycle, there can only be
one instruction result produced per cycle in the steady state).
If the write-back slot is running at full throughput that means that
data dependency is resolved and that the stalled instruction is not needed
at the moment.
If you assign a high-priority bit to instructions, that means that the flow
will be modified in the sense that an another instruction will be stalled
while the high priority instruction proceeds. In the general case that will
add up to the same number of cycles. There might be something to gain if when
exiting the sequence of instructions executing at full throughput, there is
some data dependency associated with the previously stalled instruction,
which takes a long time to resolve (long load latency for example).

_________________________________________________
Marc Tremblay
internet: marc@CS.UCLA.EDU
UUCP: ...!{uunet,ucbvax,rutgers}!cs.ucla.edu!marc