Apparently, the semester is still going on.  I knew I should have
scheduled more lectures.  In any case, a student writes:


        Dear Dr. Patt,

        I took your course  360N in fall 2005, and I remeber you telling us
        something about reorder buffers and how they are used to (as the name
        suggests) reorder the instructions being executed such that the
        instructions are released at the head of the buffer in order. The
        instructions which come out of the head of the buffer are written
        into the register file whereas the instructions even if their
        result is computed and are still in reorder buffer queue will not
        be written to the register file.

        I wanted to know if my understanding of the reorder buffer is
        correct.

        I also wanted to know what might be the disadvantages of using
        such a buffer except from the fact that it adds another step in
        the pipeline where results are picked up from the buffer head and
        put into register file. I also heard something about "precise
        interrupts" relating to reorder buffers. I tried to look online
        but could not find an easy to understand explaination.

        Can you please let me know what these special kinds of interrupts are?

        Regards,
        <<name withheld to protect the inquisitive one>>



Thanks for the question.  All important stuff.  I thought I did talk
about this in the context of HPS a week or so ago.  Apparently much too
fast.  So, let me take them one at a time.

The reorder buffer.  Made up of physical registers.  As instructions
enter the pipeline (fetch phase), they are assigned the next sequential
physical register.  After an instruction executes (potentially,
out-of-order), its result is temporarily stored in the corresponding
physical register, until it is ready for retirement, at which point
the value in the physical register is written back to the permanent
architectural register.  Instructions are retired in-order, which means
the value in a physical register can be retired only after all the preceding
physical registers have been retired.  Thus the reorder buffer gets written
randomly (as instructions happen to execute), but get read for retirement
purposes sequentially.

The extra step in the pipeline is usually not a big deal, since it comes
at the end of the pipeline, out of the critical path.

Precise interrupts, more generally called precise exceptions, is the term
given to the situation wherein an exception causes the machine to be put
into the state immediately preceding the faulting instruction, before
control is turned over to the exception handler.  ...as opposed to
imprecise exceptions, where instructions after the faulting instruction
may complete execution before the exception is detected.  

So, the definition of precise exceptions is really quite simple.  It refers
to the fact that one can recover the state that the machine would have been
in if ALL instructions prior to the faulting instruction had executed
correctly and if NONE of the instructions following the faulting instruction
had executed.

Simple example:  MUL R1,R2,R3
                 ADD R4,R5,R6

If the MUL faults after the integer ADD has completed, it is impossible to
recover the state before the MUL since R4 now has a "new" value.  Therefore,
NOT imprecise exceptions.  However, there are many ways to make sure this
does not happen, such as using a reorder buffer.

"Precise exceptions" is a critical element (usually) of a computer system
for two important reasons.  First, it is usually the case that we do not
want instructions following a faulting instruction to commit their result 
to the architecturally visible state.  Precise exceptions guarantee this,
since the machine is put into a state consistent with ALL instructions
before the faulting instruction having executed to completion, and NONE
of the instructions after that point executing at all.  Second, it is
generally useful to recover the state of the machine just before the
exception occurred in order to identify the cause of the exception.
Precise exceptions guarantees that as well.

Hope all this helps.

If you will be in 382N, we will cover all of this ad nauseum. Precise
exceptions, the extra stage in the pipeline, whether the values actually
do get written back (Pentium Pro) or whether a pointer gets updated
(Pentium 4), etc. etc. etc.  This is a classical element of Superscalar
processors, and something we will deal with at length next semester.

Good luck.  ...in 382N, or wherever the road takes you.

Yale Patt