Browse Prior Art Database

Virtual Register Mapping in a Shared Coprocessor

IP.com Disclosure Number: IPCOM000124717D
Original Publication Date: 2005-May-04
Included in the Prior Art Database: 2005-May-04
Document File: 3 page(s) / 34K

Publishing Venue

IBM

Abstract

The idea is to use fewer physical registers than there are logically required and control the occupation by a mechanism which avoids deadlock situations.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 37% of the total text.

Page 1 of 3

Virtual Register Mapping in a Shared Coprocessor

If a register-oriented coprocessor is shared by a high number of threads or processors the cost for providing a register set to each thread would be high.

If the coprocessor is used only sporadically by the individual threads most registers would be unused most of the time. However a high number of registers might either be required by the standard architecture (e.g. AltiVec) and/or is desirable for a high performance in periods of use. In particular a typical behaviour is that there are short periods of intensive use of the coprocessor in one thread when a high number of registers is needed, followed with a long period when no or only a small number of registers is used.

It is proposed to use fewer physical registers than there are logically required and control the occupation by a mechanism which avoids deadlock situations.

A common convention between the register allocation on one side and the compiler or programmer on the other is given by a number representing the maximum number of registers occupied by a processor or thread in a low-use period. The programmer or compiler guarantees that a thread reduces the number of occupied registers to at least this bound within a limited number of instructions.

A second (optional) parameter is the maximum number of registers a thread uses. There is an architectural maximum by default, but if a program is written in a way to have a lower maximum register use, than the allocator can allow more threads to use the coprocessor at the same time. The allocator keeps track of the threads that use more registers than the minimum and decides whether another thread can start an intensive-use phase of the coprocessor (indicated by the request to use an additional register such that the number of registers used by this thread surpasses the minimum-register limit). The end-of-use of a register is either marked by a special instruction or by writing a default value (e.g. 0) to it.

For simplicity, in the following explaination it is assumed, that all threads/processors execute programs with equal characteristics with respect to coprocessor register usage. The extension towards inhomogeneous behavior is obvious to someone skilled in the art.

Symbols: p Number of processors or threads using the shared coprocessor r Number of architecture-defined coprocessor registers c Number of physically implemented registers in the coprocessor l Maximum number of registers occupied by one thread/processor in a no-use period h Maximum number of registers occupied by one thread/processor

Relation between symbols: c>=r
Reason: the coprocessor has to provide the full architecture-defined set of registers for at least one processor.

1

Page 2 of 3

h<=r

Reason: a thread can not use more registers than defined in the architecture c>=l*(p-1)+h
Reason: At any time there have to be as many registers that one thread can intensively use to its maximum requirement and all other threads...