Browse Prior Art Database

Fast isync completion for SMT

IP.com Disclosure Number: IPCOM000012664D
Original Publication Date: 2003-May-19
Included in the Prior Art Database: 2003-May-19
Document File: 3 page(s) / 61K

Publishing Venue

IBM

Abstract

In an SMT processor core with shared exception handling logic, overhead is introduced whenever an instruction has an exception or if the instruction is in a category that requires special processing at completion time (a.k.a. "ugly-ops"). Although exceptions and ugly-ops are generally rare, a particular ugly-op, isync, can be fairly frequent, and the overhead of a thread's arbitration and use of the exception handling logic is undesirable. A method is disclosed for more efficient isync processing in an SMT processor core with shared exception handling logic.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

Fast isync completion for SMT

Disclosed is a method for efficiently completing isyncs in an SMT processor core with shared exception handling. This method includes: - identification of isyncs at dispatch time and encoding into the completion table - identification of isyncs at completion time on a per thread basis. - per thread checking of whether or not a context synchronizing flush is required with the isync execution. - bypassing of the exception handling logic when no flush is required, eliminating arbitration overhead. - completion of the isync as soon as appropriate conditions are identified.

Shown in Figure 1 is the architecture for sharing an exception handling block between two threads. Each thread has a status block which holds state information relative to that particular thread. If an exception or ugly-op exists at the next to complete instruction group, the thread will arbitrate for use of the exception handling logic. Upon being granted use of the exception logic by the arbitration logic, relevant thread-specific information is muxed into the exception logic. The exception handling block decodes what kind of exception or ugly-op exists and determines appropriate actions. This decoding represents a large block of logic and it is desirable to not duplicate it on a per-thread basis. Exception and ugly-op handling then proceeds, and outputs, like completion of isyncs, are then gated into thread-specific versions based on whichever thread currently owns...