Our design deals with inter-microinstruction pipeline hazards in three ways. The simplest is to avoid them. MIPS avoids hazards by a set of programming rules that are followed by the compiler. With this solution comes the choice of a very smart compiler or a lot of extraneous No-Op's. We didn't want to introduce such rules (and their attendant increase in code size) at the machine instruction level. We do avoid some hazards by implementing a few infrequently-executed instructions with awful side effects (Store IFU Register, for example) by a carefully coded sequence of microinstructions that clears microinstructions for preceding instructions out of sensitive places in the pipeline before the killer microinstruction does its dirty deed, and then prevents microinstructions for succeeding instructions from entering sensitive places in the pipeline while the deed is still in progress.

Another case of hazard avoidance is delay-matching in parallel paths. Dragon has a simple loop-free pipeline in which nearly every computational resource (gate, bus, etc.) is used at only one pipeline stage. This greatly simplifies pipeline scheduling, but it also means that some paths through the pipeline are longer than they would otherwise need to be. For example, consider the store-back path to the EU RAM. For ordinary arithmetic, this could be located at Level 3. But because we put the ALU operations and data cache references in tandem, rather than in parallel, for data cache references the EU RAM store-back path has to be at Level 4. A hazard is avoided by inserting an extra pipeline stage between ALU output and EU RAM store-back path, so that it is always used at Level 4.

Another way Dragon deals with hazards is to detect them, and to prevent some upper endangered segment of the pipeline from advancing, while allowing the lower danger-free segment to advance normally. A microcode No-Op, which changes no state and participates in no hazards, is inserted in the pipeline gap thus created. The boundary between the stationary initial pipeline segment and the advancing final pipeline segment is chosen as high in the pipeline as possible, but so that at least one of the two participants in any hazard is on the stationary side of the boundary. In Dragon, there are three such boundaries. One is at Level 0, and deals with next instruction not ready, or a Call-Return hazard. One is at Level 1, and deals with those cases of EU RAM Write-Read hazard that cannot be short-circuited. And one is at Stage 3, and deals with data cache not ready.

The final way Dragon deals with hazards is to detect them, and to achieve the desired effect in another way, without introducing delay. The data path round-trip, from the EU RAM, through the ALU, through a best-case data cache operation (or the parallel collision-avoiding pipeline stage), and back into the EU RAM, takes three pipeline stages. During that time a potential Write-Read hazard exists on the EU register that is specified as the destination of a microinstruction, because a following microinstruction can read the wrong value. Many of these hazards can be handled without wasted cycles by means of EU pipeline short-circuits, which are additional data pathways in the EU that carry data backward one or two pipeline stages. For example, there is a short-circuit from the output of the ALU back to either input, so that an instruction may use the arithmetic result of the previous instruction. The use of these short-circuit paths is governed by the IFU. It matches the source register addresses of an instruction about to enter pipeline stage 1 against the destination register addresses of instructions further down the pipeline. Short-circuit paths are expensive, both in area and complexity, so we have included them only where they will speed up common instruction sequences.

Dragon has a way of attaining a state as if all microinstructions beyond pipeline stage 3 ran to completion, while all those at stage 3 and earlier never started. This mechanism, combined with careful microcoding of multi-microinstruction instructions, allows a data cache fault, or an arithmetic fault, to behave as if an XOP (extended op, or very short procedure call) had been inserted before the instruction that caused the fault, and allows the instruction to be re-executed after the fault has been remedied. This same mechanism is also used to speed up correctly-predicted conditional jumps.

This state restoration is probably the one mechanism responsible for the most logical complexity in the processor. The mechanism is implemented in different ways for the different state variables involved. To recover state in the EU, where permanent state changes only take place at pipeline stage 2 and beyond, the IFU converts destination register addresses to an unimplemented register number, converts the ALU operation in Level 1 to a harmless OR, and notifies the ALU to recover Carry and other small amounts of state from internal saved versions. Within the IFU, the current program counter, S, and L registers at Level 1 are reloaded from shadow copies at Level 3.

The worst problem is the IFU's control stack cache, IStack. This cache contains the caller's return PC and L values for the most recent few pending procedure calls, XOP's, or Reschedule interrupts, or fault traps in the current process. To avoid a complex recovery process, this cache is located at Level 4, which is attained only by microinstructions that do not fault. Unfortunately, this means that if the matching Return appears fewer than three pipeline stages after a Call, the control stack cache does not yet contain the caller's return PC, so a Call-Return hazard exists and an interlock must be activated.