Browse Prior Art Database

Method and system for Implementing “Register Threads” in a Simultaneously-Multithreaded (SMT) Processor Core

IP.com Disclosure Number: IPCOM000199825D
Publication Date: 2010-Sep-17
Document File: 4 page(s) / 179K

Publishing Venue

The IP.com Prior Art Database

Abstract

A method and system for implementing “register threads” in a Simultaneously-Multithreaded (SMT) processor core, to support Decoupled Access-Execute (DAE) and other execution paradigms is disclosed.

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 38% of the total text.

Page 1 of 4

Method and system for Implementing "Register Threads" in a Simultaneously-Multithreaded (SMT) Processor Core

Disclosed is a method and system for implementing "register threads" in a Simultaneously-Multithreaded (SMT) processor core. The register threads are used to support Decoupled Access-Execute (DAE) and other execution paradigms. The method and system includes allowing two program threads to work in the same set of registers. For this, the register-index thread IDs used by them to index into the desired frame of the physical register file needs to be the same. This is achieved by providing a new Operating System Call (system call) that allows the two program threads to share the same register-index thread IDs.

Since register threads are cooperating threads, often generated from a single machine-instruction-level thread, it is assumed that register threads statically partition the registers amongst themselves as

                        rivate, read-shared, and write-shared registers, and are careful not to overwrite each others' private and read-shared registers. Thus, issues of protection and security do not arise between register threads.

The method and system further includes synchronizing the register threads. As an example, two register threads may be synchronized using standard processor instructions, as illustrated by the following assembly language pseudo-code.

// R0 is the lock register; set to 0 when free, to threadID when a thread is holding the lock

tryLock: R0 = R0 BIT-OR myID;

p

myID is held in a register

// did not acquire the lock

R0 = preferredID; // do this to reduce livelock

goto tryLock;

//

//

have the lock now

{Execute Critical Section;}

R0 = 0;

//

In the preceding pseudo code, the lock register R0 is set to "0" when the lock is free. Further, since both the register threads share the same functional units, two instructions issued to the same functional unit by the two register threads will execute one after the other. Further, register dependence may be enforced between these two instructions. If two processes try to acquire the lock "simultaneously", i.e. they execute "R0 = R0 BIT-OR myID" one after the other, both will see junk in the lock register R0 and then try to give the lock to a preferred process (e.g. the Execute process in the DAE paradigm). Although the preceding pseudo code illustrates synchronizing two register threads by standard processor instructions, other synchronization methods may also be used.

In another instance of the method and system disclosed herein, a fine grained communication method between the register threads is disclosed. This instance includes an extension to an SMT register file to enable each register to function as a

1

if (R0 != myID) {

I

spinlock

}

//

I

unlock

Page 2 of 4

queue when required. The extension to the SMT register includes providing a ReadBusyBit in addition to the WriteBusyBit. The ReadBusyBit enables providing queue semantics for each register.

Initially both the WriteBusyBit a...