Various forms of μops have long been the basis for traditional
microcode routines used to simplify the implementation of a particular
CPU design or perhaps just the sequencing of certain multi-step operations or addressing modes. More recently, μops have also been employed in a different way in order to let modern
CISC processors more easily handle asynchronous parallel and speculative execution: As with traditional microcode, one or more table lookups (or equivalent) is done to locate the appropriate μop-sequence based on the encoding and semantics of the machine instruction (the decoding or translation step), however, instead of having rigid μop-sequences controlling the CPU directly from a microcode-
ROM, μops are here dynamically buffered for rescheduling before being executed. This buffering means that the fetch and decode stages can be more detached from the execution units than is feasible in a more traditional microcoded (or hard-wired) design. As this allows a degree of freedom regarding execution order, it makes some extraction of
instruction-level parallelism out of a normal single-threaded program possible (provided that dependencies are checked, etc.). It opens up for more analysis and therefore also for reordering of code sequences in order to dynamically optimize mapping and scheduling of μops onto machine resources (such as
ALUs, load/store units, etc.). As this happens on the μop-level, sub-operations of different machine (macro) instructions may often intermix in a particular μop-sequence, forming partially reordered machine instructions as a direct consequence of the out-of-order dispatching of microinstructions from several macro instructions. However, this is not the same as the
micro-op fusion, which aims at the fact that a more complex microinstruction may replace a few simpler microinstructions in certain cases, typically in order to minimize state changes and usage of the queue and
re-order buffer space, therefore reducing power consumption. Micro-op fusion is used in some modern CPU designs. The size of this cache may be stated in terms of how many thousands (or strictly multiple of 1024) of micro-operations it can store:
Kμops. == References ==