Browse Prior Art Database

Loosely Coupled Synchronization Mechanism Supporting Precise Interrupts

IP.com Disclosure Number: IPCOM000109687D
Original Publication Date: 1992-Sep-01
Included in the Prior Art Database: 2005-Mar-24
Document File: 4 page(s) / 136K

Publishing Venue

IBM

Related People

Ali, MM: AUTHOR [+5]

Abstract

As math co-processors became processors, actually resting on the same Instruction buses as the general processor, the issue of precise interrupts became the problem of "how to guarantee the interrupt was precise, yet minimize communication overhead in the synchronization protocol used?". Previously all instructions fed to the math co-processor went through the general processor. By the time the co-processor received the instructions, they were past the point of interruption.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Loosely Coupled Synchronization Mechanism Supporting Precise Interrupts

       As math co-processors became processors, actually resting
on the same Instruction buses as the general processor, the issue of
precise interrupts became the problem of "how to guarantee the
interrupt was precise, yet minimize communication overhead in the
synchronization protocol used?".  Previously all instructions fed to
the math co-processor went through the general processor.  By the
time the co-processor received the instructions, they were past the
point of interruption.

      The most commonly used synchronization mechanism is the
tightly-coupled/single-step method.  In this mechanism the math
processor informs the general processor when it has an instruction.
The general processor then tells the math co-processor to either
execute the instruction or cancel it.  This handshaking protocol is
performed on ALL instructions.  The two drawbacks of this mechanism
are: 1) Both units must receive all instructions fetched in order to
keep "in sync".  2) Neither unit can process the next instruction
until the other can process the same instruction.

      The mechanism described in this article is in the environment
of the IBM RISC System/6000* POWER architecture.  The processor
organization is illustrated in Fig. 1.

      In this architecture the branch unit handles all programmed and
external interrupts.  Once the instructions have been dispatched to
the fixed or floating point units, the only interrupts are from
memory access and trap instructions.  I will call these two types of
instructions 'interruptible instructions' in the prospective of the
fixed-point or floating-point processors.  The floating-point unit
does not interrupt on enables IEEE exceptions.  The programmer/user
has the responsibility of polling for these exceptions.  The
mechanism disclosed here pertains to the synchronizing of the
fixed-point and floating-point units in the above architecture.

      Each unit (fixed-point (FXU) and floating-point (FPU)) receives
only the instructions that it executes (i.e., the FPU receives
floating-point multiplies, adds, etc.) with the exception of the
interruptible instructions mentioned above that both units receive.
Synchronization is only important on these instructions.  Fig. 2
shows the relative pipelines of the FPU and FXU.

      The fixed-point decode stage is equivalent to the
floating-point predecode...