CN107851006A - Multithreading register mappings - Google Patents

Abstract

A kind of system of processing register access request, including interface for receiving register access request and the processing unit for being connected to the interface.Architectural registers are dynamically mapped in physical register by the processing unit based on such as nearest use of architectural registers of multithreading (multithreading, abbreviation MT) thread and/or the standard of access frequency.The processing unit also searches the corresponding architectural registers for the register access request that matching is can not find in physical register.

Description

multithreaded register map

Background technique

The present invention, in some of its embodiments, relates to the implementation of multithreading, and more particularly, but not limited to, architectural register management in multithreaded kernels.

CPU cores, especially those aimed at the server market, increasingly support multithreading (MT for short). The demand for multi-threaded cores has been growing at a high rate across all server markets, especially in the context of scale-out applications such as Big Data.

There are currently three MT implementations:

1. Fine Grain MT (FGMT for short): threads are interleaved based on the clock;

2. Simultaneous MT (Simultaneous MT, referred to as SMT): threads run at the same time, sharing all machine resources;

3. Coarse grain MT (Coarse Grain MT, referred to as CGMT, also means switching on event MT and SoE MT): the thread runs until it is blocked by an event (usually resulting in a long period of stagnation). Then, the next waiting thread in its natural state takes its place.

Current MT implementations include:

1. Intel's Larrabee (4-way FGMT);

2. Intel Xeon server (2-way SMT);

3. Intel Itanium Montecito (2-way CGMT).

In MT, each thread hosts the overall architectural state of the machine. Each architectural register file set (Architectural Register File Set, referred to as ARF) usually includes:

1. An integer register file (for example, ARMv8 uses 31 registers, each 64 bits wide);

2. Floating point/SIMD register files (for example, ARMv8 uses 32 registers, each 128 bits wide);

3. Status registers (for example, ARMv8 uses about 6 registers, each 64 bits wide);

If the same chip supports multiple threads, the number will multiply. Registers must be available and easily accessible.

Current MT implementations use the following strategy to handle register files (RF):

1) Duplicate the ARF for each thread. This is also used for FGMT and SMT, and in some cases, for CGMT (to avoid long handovers). Duplicating an ARF is very wasteful in terms of silicon area and power consumption.

2) Keep a single register file set and replicate it over and over (CGMT only). This approach is time-consuming, making switching times considerably longer, inefficient, and severely degrading performance.

Contents of the invention

The purpose of the invention is to improve multithreading.

The independent claims purport to achieve this purpose. The dependent claims protect other embodiments.

Embodiments presented herein map the most recently and/or frequently used registers of running threads (ie, active threads) into physical registers. All thread registers are kept in architectural registers, or stored in SRAM. When the requested register is not mapped to a physical register, store the contents of the architectural register in the allocated physical register, possibly replacing previously stored content (e.g., for suspended threads). In this way, the silicon area and energy consumption can be reduced, and the switching time can be shortened.

According to a first aspect of some embodiments of the invention there is provided a system for processing register access requests. The system includes an interface and a processing unit for receiving register access requests. The processing unit dynamically maps a group of registers from the plurality of architectural registers to at least one of the most recent use and access frequency of each architectural register in a plurality of multithreading (MT) threads One of the plurality of physical registers, when a match is not found in the physical registers, the match is looked up in the architectural registers for each register access request.

According to the first aspect, in a first possible implementation manner of the system, the MT thread submits the register access request, and is in a multi-threaded processor.

In a second possible implementation of the system, the register access request is received via at least one pipeline engine.

In a third possible implementation manner of the system, the architectural registers are stored in a static random access memory (static random access memory, SRAM for short).

In a fourth possible implementation manner of the system, the system further includes a memory for storing the access frequency data set. The processing unit updates the access frequency data set with the access frequency of each register, and executes the mapping according to the access frequency data set.

In a fifth possible implementation manner of the system, the system further includes a memory for storing recently used data sets. The processing unit updates the recently used dataset with the recent used and performs the mapping based on the recently used dataset.

According to a fifth implementation manner of the first aspect, in a second possible implementation manner of the system, the recently used data set includes a plurality of records. Each record records the most recent usage of each of said MT threads to said architectural registers.

According to a fifth implementation manner of the first aspect, in a third possible implementation manner of the system, the recently used data set includes each allocation status of the architectural register.

According to a fifth implementation of the first aspect, in a fourth possible implementation of the system, the architectural registers are mapped to the allocation of suspended and running threads in the MT thread, and the physical registers are mapped to Assignment of execution threads to the plurality of MT threads.

According to a fifth implementation of the first aspect, in a fifth possible implementation of the system, the processing unit switches the allocation of any one of the physical registers from one of the MT threads to the MT thread The other of the updates the recently used data set.

In a sixth possible implementation manner of the system, the processing unit maps the architectural register to the MT thread. In a seventh possible implementation manner of the system, the processing unit switches the mapping of any one of the architectural registers from one of the MT threads to another of the plurality of architectural registers.

In an eighth possible implementation manner of the system, when the active thread is not switched to be activated to a different thread, the processing unit sets each state of the physical register mapped to the active thread as available.

According to a second aspect of some embodiments of the present invention there is provided a method for processing register access requests. The method includes:

1) receiving multiple register access requests;

ii) dynamically mapping a set of registers from the plurality of architectural registers to at least one of the plurality of physical registers based on at least one of recent use and access frequency of each architectural register in a plurality of multithreading (MT) threads in the register;

iii) When the requested register is not found in the map of physical registers, finding a match for each of said register access requests in said plurality of architectural registers.

According to the second aspect, in a first possible implementation of the method, the method further includes: monitoring at least one of the recent use and access frequency by recording the plurality of register access requests received via at least one pipeline engine One. Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the invention, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and not necessarily limiting.

Description of drawings

By way of example only, some embodiments of the invention are described herein with reference to the accompanying drawings. With specific reference now to the drawings, it is emphasized that the items shown are by way of example, for purposes of illustrative discussion of embodiments of the invention. Thus, how to practice the embodiments of the present invention will be apparent to those skilled in the art from the description of the accompanying drawings.

In the attached picture:

FIG. 1 is a simplified block diagram of a system for processing register access requests according to an embodiment of the present invention;

FIG. 2 is a brief description of a register mapping scheme provided according to an embodiment of the present invention;

FIG. 3 is a simplified block diagram of a method for processing a register access request according to an embodiment of the present invention;

Fig. 4 is a simple block diagram of a method based on thread background switching provided according to an embodiment of the present invention;

Fig. 5 is a simplified flow chart of a method for processing a register access request according to an embodiment of the present invention.

Detailed ways

The present invention, in some of its embodiments, relates to multithreading, and more particularly, but not limited to, architectural register management in multithreaded kernels.

Embodiments of the present invention utilize a register mapping scheme to dynamically map recently and/or frequently used architectural registers into a smaller set of physical register files, and extract the contents of the registers as needed.

In some embodiments, when a new register access request is issued, the register map (also denoted herein as a mapping table) is checked to see if the requested architectural register is mapped into a physical register. When the requested register exists in the PRF, the physical register is used for register access.

When the requested register is not mapped into the PRF, one or more physical registers are written back into the ARF to make the registers in the PRF available to store other architectural register values. Write the requested architectural register into a physical register, and continue accessing from the PRF.

The mapping table is dynamically maintained and updated as needed during allocation and reallocation of physical registers to architectural registers. Before explaining at least one embodiment of the present invention in detail, it is to be understood that the present invention is not necessarily limited in its application to the structures of components and/or methods set forth in the following description and/or illustrated in the drawings and/or examples and layout details. The invention is capable of other embodiments or of being practiced or carried out in various ways.

The present invention can be a system, method and/or computer program product. The computer program product may include one (or more) computer-readable storage medium(s) having computer-readable program instructions for causing a processor to perform various aspects of the invention.

The computer readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. For example, the computer readable storage medium may be, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of these.

The computer-readable program instructions described herein can be downloaded to each computing/processing device from a computer-readable storage medium, or to an external computer or external storage device through a network such as the Internet, a local area network, a wide area network, and and/or Wi-Fi.

The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, or as a stand-alone software package, partly on the user's computer, partly on a remote computer, or entirely on the remote computer or execute on the server. In the latter scenario, the remote computer can be connected to the user computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can (for example, use an Internet service The provider establishes this connection on the external computer via the Internet). In some embodiments, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA for short), or a programmable logic array (PLA for short) may utilize a computer-readable program State Information of Instructions Execution of the computer readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

Here, aspects of the present invention are described in conjunction with flowcharts and/or block diagrams of methods, apparatus (systems) and computer program products in embodiments of the present invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. At this time, each block in the flowchart or block diagram may represent a module, a segment or a part of instructions, including one or more executable instructions for implementing specific logical functions. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It should also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or actions, or by special purpose hardware and A combination of computer instructions.

Some embodiments of the invention are based on a computing system comprising:

1) memory (such as SRAM), which stores the architectural state of multiple MT threads;

2) storing the physical registers of the physical register file (represented as PRF here);

3) Register mapping, which dynamically maps architectural registers to physical registers.

The terms "architectural register file" and "ARF" as used herein refer to a data set that includes the entire architectural state of all threads. These terms are not limited to the specific type of file, data organization or storage element used to store ARF.

The memory storing ARF has denser data storage than physical registers, but its access time is longer than that of physical registers. A reasonably sized PRF enables fast access to some architectural register contents without significantly increasing silicon area. The terms "physical register file" and "PRF" as used herein refer to data sets stored in physical registers. These terms are not limited to a particular type of file or organization of data.

In some embodiments, memory stores all architectural state for all threads. In this embodiment, simple logic is used for fixed indexing, but is more expensive in regions. In other embodiments, the memory only stores architectural state that is not stored in the PRF, resulting in reduced area and increased indexing complexity.

In some embodiments, each active thread has a predetermined number of physical registers and cannot use physical registers allocated to other threads. In other embodiments, physical registers are allocated dynamically to all active threads.

In some embodiments, when a new register access request is issued, its source and destination operands are looked up in a register map (also denoted herein as a mapping table). When the mapping table shows that the requested register exists in the PRF, the physical register is used for register access. A replacement cycle occurs when one or more requested registers are not mapped into the PRF. During a replacement cycle, one or more physical registers (eg, registers that have not been used recently) are written back into architectural registers. These physical registers can then be used to store other architectural register values. After the warmup period, all selected architectural registers (eg recently used) will be cached in the PRF, execution requiring relatively few replacement cycles. However, a new warm-up period may occur when processing moves to a new stage that employs different architectural registers. The mapping table is dynamically maintained and updated as needed during or after the replacement cycle.

The terms "register request" and "register access request" as used herein include requests for read and write operations on registers. The register map described here is particularly beneficial for core implementations that employ a large number of threads in order to take advantage of thread-level parallelism (e.g., graphics accelerators, big data servers, etc.). A single core can support a greater number of threads by increasing thread level parallelism (TLP) without the overhead of duplicating the entire architectural state of all threads or limiting CGMT operations for long thread switching cycles. The potential benefits of the register map described here increase as the number of threads per core increases.

Referring now to FIG. 1 , FIG. 1 is a simplified block diagram of a system for processing register access requests according to an embodiment of the present invention. The system 100 includes an interface 110 and a processing unit 120 .

The interface 110 receives register access requests. Optionally, the register access request is submitted by multiple MT threads. Optionally, the register access request is received via at least one pipeline engine.

The processing unit 120 dynamically maps a set of registers from architectural registers 150 to physical registers 140 . Optionally, the mapping is based on:

i) access frequency of MT threads ("frequently used");

ii) recent use of MT threads ("Recently Used"); and/or

iii) Frequency of access and combination of recent use.

In response to a register access request, the processing unit 120 determines from the mapping table whether a register value is stored in the physical register 140 . When no match is found in the physical register 140 , the processing unit 120 looks in the architectural register 150 for a match for the requested register.

Optionally, the architectural registers are stored in static random access memory (static random access memory, SRAM for short).

In some embodiments, the system 100 includes memory that stores recently used data sets. The processing unit 120 updates a recently used data set with the most recent use of each register, and performs at least part of the mapping according to the recently used data set. Additionally or alternatively, the memory stores access frequency data sets. The processing unit 120 updates the recently used data set with the access frequency of each register, and performs at least part of the mapping according to the access frequency data set.

Optionally, the recently used data set includes a plurality of records. Each record records the most recent usage of architectural registers in various threads.

Optionally, the recently used data set includes the allocation status of each architectural register. The allocation status indicates when an architectural register is allocated to a physical register and under what circumstances architectural register values can be read from or written to the physical register, and optionally indicates the physical register to which the architectural register is allocated.

Optionally, the architectural registers 150 are allocated to suspended (ie, inactive) and running (ie, active) threads of a plurality of MT threads, and the physical registers 140 are allocated to running threads.

Optionally, when the allocation of architectural registers is switched from one MT thread to another, the processing unit 120 updates the recently used data set. This can happen when threads are terminated or added.

Optionally, when the allocation of physical registers is switched from one MT thread to another, the processing unit 120 updates the recently used data set. This can happen when threads are inactive and physical registers are reallocated to architectural registers of different threads.

Optionally, the processing unit 120 maps architectural registers to corresponding MT threads.

Optionally, the processing unit 120 switches the mapping of the architectural register of a specific MT thread to a different architectural register. Referring now to FIG. 2 , FIG. 2 is a brief description of a register mapping scheme provided according to an embodiment of the present invention. In Fig. 2: i) N represents the number of active threads;

ii) M represents the total number of threads (active and inactive);

iii) K represents the number of all registers of each thread;

iv) J represents the number of registers stored in the PRF 130 per thread.

Therefore, the total number of registers in ARF is M*K, while the number of registers in PRF is less N*J.

For clarity, in the non-limiting embodiment of FIG. 2, the registers stored in the PRF are selected based on access frequency ("frequently used"). In other embodiments, registers stored in the PRF are selected by different criteria (eg, most recently used) and register maps, with access and processing performed in a substantially similar manner.

Mapping table 210 specifies whether the requested register is allocated in PRF 220, and also maintains other information for finding replacement candidates (eg, least commonly used registers). In the embodiment of FIG. 2, the mapping table 210 saves the following fields of each register of an active thread:

i) valid field: indicates whether the architectural register value is stored in the PRF;

ii) Index field: mapping the architectural registers to physical registers;

iii) Dirty field: Indicates whether the value stored in the architectural register corresponds to the value of the mapped physical register;

iv) Access frequency field: When the requested architectural register is not in the PRF, it can be used to select a physical register for overwriting.

In FIG. 2, pipeline engine 200 runs N active threads. The active thread issues a register access request of the architectural register. When a register request is received from the pipeline engine 200 , the mapping table 210 is used to determine whether a register value can be accessed relatively quickly from the PRF 220 or must be obtained from the ARF 230 .

The ARF 230 stores the architectural register files of all active and inactive threads. Data may be transferred between the ARF 230 and the PRF 220 to keep architectural register values and physical register values up-to-date as required for operation. The mapping table is updated accordingly.

In the case of a "register miss" (ie, the requested architectural register is not in the PRF 220), the "victim" physical register is reallocated for the requested architectural register, and the content of the reallocated register is replaced. In some embodiments, inactive threads are the preferred provider of victim physical registers.

Optionally, the victim physical register is selected based at least in part on data (eg, access frequency and/or most recent access) stored in a mapping table.

Optionally, the remapping of source and destination registers is done in the pipeline engine.

Referring now to FIG. 3 , FIG. 3 is a simplified flow chart of a method for processing a register access request according to an embodiment of the present invention. In step 310, a register access request is received. In step 320, the register map is checked to determine when the requested register is mapped into a physical register. In step 330, a match is looked up in an architectural register (ie, ARF) for each requested register that is not mapped to a physical register. Optionally, in step 340, the architectural register value is stored in a physical register.

Optionally, in step 350, the requested register is accessed from said PRF.

In step 360, register mapping from architectural registers to physical registers (ie, PRFs) is performed dynamically. The mapping may be based on recent usage of each architectural register by the MT thread and/or recent usage of each architectural register by the MT thread. Optionally, the mapping is performed based on alternative or additional mapping criteria.

Optionally, recent usage of registers (physical registers and/or architectural registers) is monitored by recording register access requests received via at least one pipeline engine.

Referring now to FIG. 4 , FIG. 4 is a simplified block diagram of a method for processing a register access request according to an embodiment of the present invention. In step 400, the pipeline engine issues a register access request. In step 410, the mapping table is checked to determine if the requested register is stored in the PRF (eg, by checking the "valid" bit of the requested register).

In step 420, a register read or write access is performed when the requested register is stored in the PRF. For write operations, the write data is stored in physical registers that map to the requested architectural registers. For read operations, returns the value stored in the physical register mapped to the requested architectural register.

In step 430, when the requested register is not stored in the PRF, the PRF is searched for an available physical register to store the requested architectural register's data. In step 450, when no usable physical register is found, a victim physical register is selected and its content is stored back to the ARF, thereby creating a usable physical register.

In step 460, it is determined whether the access is a read request. Then in step 470, when the access is a read request, the requested register value is copied from the ARF to an available register in the PRF, as shown in step 470. The read or write operation in step 420 is then performed as described above.

Referring now to FIG. 5 , FIG. 5 is a simplified block diagram of a thread background switching method according to an embodiment of the present invention.

In step 500, it is determined whether the thread switch is hardware or software.

In step 510, when the thread switch is a hardware switch, the engine pipeline switches the active thread to a different thread, temporarily blocking the previously active thread. In step 520, the valid bit of the currently active thread is set to zero. In step 530, only registers marked as dirty in the mapping table are updated in the ARF.

In step 540, when the thread switch is a software switch, the software switches the active thread to another thread, invalidating the previously active thread. In step 550, all physical registers mapped to the architectural registers of the currently active thread are read and written to memory (ie, updated in the ARF). In step 560, all valid bits of the current active thread in the mapping table are set to 0. In step 570, the previously active thread is removed from the thread control register, which designates the active thread.

In summary, the above embodiments are useful for all MT implementations including CGMT. The register map described here significantly reduces CGMT overhead because ARFs are not copied per thread, and restoration of architectural registers is done on demand. Registers for a new thread can be retrieved at thread switch time (i.e. when the machine front end fetches instructions from the new thread). Suspended threads naturally provide physical register victim candidates. Avoiding full ARF replication results in significant reductions in area (die size) and power consumption. Compared to a full ARF save and restore, thread switch times are significantly reduced and can be performed mostly in the background.

The descriptions of various embodiments of the present invention are presented for purposes of illustration only, and are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and changes will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, practical applications or technological advancements, or to enable others skilled in the art to understand the embodiments disclosed herein, compared to technologies available in the market.

It is expected that during the patent period from which this application expires, many related multithreading implementations, register files, architectural registers, physical registers, register map implementations, and register access operations will be developed, and terms include multithreading, register files, architectural registers, Physical Registers, Register Map, Register Access, and Register Access Request include all of these new technologies upfront.

The terms "including" and "having" mean "including but not limited to". This term includes the terms "consisting of" and "consisting essentially of".

The phrase "consisting essentially of" means that the composition or method may contain additional ingredients and/or steps, provided that the additional ingredients and/or steps do not materially alter the basic and novel nature of the claimed composition or method characteristic.

As used herein, the singular forms "a" and "the" include plural reference unless the context clearly dictates otherwise. For example, the term "a complex" or "at least one complex" may include a plurality of complexes, including mixtures thereof.

The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any "exemplary" embodiment is not necessarily to be construed as preferred or superior to other embodiments, and/or does not preclude a combination of features of other embodiments.

The word "optionally" is used herein to mean "provided in some embodiments and not provided in other embodiments". Any particular embodiment of the invention may contain multiple "optional" features, unless such features are contradictory.

Throughout this application, various embodiments of this invention may be presented in a range format. It should be understood that the description in range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of the invention. Accordingly, the description of a range should be considered to have specifically disclosed all the possible subranges as well as individual values within that range. For example, a description of a range such as from 1 to 6 should be considered to have specifically disclosed sub-ranges such as from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6, etc., as well as individual numbers within said range, such as 1, 2, 3, 4, 5, and 6. This works regardless of the width of the range.

When a numerical range is indicated herein, it is meant to include any cited numeral (fractional or integral) within the indicated range. The phrases "within the first indicated number and the second indicated number" and "from the first indicated number to the second indicated number" are used interchangeably herein to mean Include the first and second indicated numbers and all fractions and whole numbers in between.

It is appreciated that certain features of the invention, which are, for brevity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as any suitable other embodiment of the invention. Certain features described in the context of individual embodiments are not to be considered essential characteristics of those embodiments, unless the embodiment is ineffective without those elements. All publications, patents, and patent specifications mentioned in this specification are herein incorporated by reference herein as if each individual publication, patent, or patent specification was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is prior art over the present invention. As far as section headings are used, they should not be construed as necessarily limiting.

Claims (15)

1. A kind of 1. system of processing register access request, it is characterised in that including：

   Interface, for receiving multiple register access requests；

   Processing unit, it is connected to the interface and is used for：

   Based on making recently in each multiple architectural registers in multiple multithreadings (multithreading, abbreviation MT) thread With with it is at least one in access frequency, one group of register is dynamically mapped at least one from the multiple architectural registers In individual multiple physical registers；

   When not finding matching in the multiple physical register, searched in the multiple structure register each described The matching of register access request.
2. 2. system according to claim 1, it is characterised in that the multiple MT threads submit the multiple register access Request, and in multiline procedure processor.
3. 3. system according to any one of the preceding claims, it is characterised in that the multiple register access request warp Received by least one streamline engine.
4. 4. system according to any one of the preceding claims, it is characterised in that the multiple architectural registers are stored in In static RAM (static random access memory, abbreviation SRAM).
5. 5. system according to any one of the preceding claims, it is characterised in that also include being used to store access frequency number According to the memory of collection；Wherein described processing unit is used to update the access frequency data using the access frequency of each register Collection, and the mapping is performed according to the access frequency data set.
6. 6. system according to any one of the preceding claims, it is characterised in that also include being used to store to use number recently According to the memory of collection；Wherein described processing unit be used for using it is described recently using come update it is described use data set recently, and And the mapping is performed using data set recently according to described.
7. 7. system according to claim 6, it is characterised in that it is described to include multiple records using data set recently, each Record the nearest usage record of each the multiple MT thread to the multiple architectural registers.
8. 8. the system according to any one of claim 6 or 7, it is characterised in that described to include institute using data set recently State each distribution state of multiple architectural registers.
9. 9. the system according to any one of claim 6~8, it is characterised in that the multiple structure register is mapped to The distribution for the thread hung up and run in the multiple MT threads, and the multiple map physical registers are to the multiple MT The distribution of the active thread of thread.
10. 10. the system according to any one of claim 6~9, it is characterised in that the processing unit is used for, and will appoint Distribution in one the multiple physical register is switched in the multiple MT threads from one of the multiple MT threads Another when, renewal described uses data set recently.
11. 11. system according to any one of the preceding claims, it is characterised in that the processing unit is used for will be described more Individual architectural registers are mapped in the multiple MT threads.
12. 12. system according to any one of the preceding claims, it is characterised in that the processing unit is used for any one Mapping in the multiple architectural registers is switched in the multiple architectural registers from one of the multiple MT threads Another.
13. 13. system according to any one of the preceding claims, it is characterised in that when active threads do not have switching to be activated to During different threads, each state for the physical register that the processing unit is used to will be mapped to the active threads is arranged to can With.
14. A kind of 14. method of processing register access request, it is characterised in that including：

    Receive multiple register access requests；

    Nearest use based on each multiple architectural registers in multiple multithreadings (multithreading, abbreviation MT) thread With it is at least one in access frequency, one group of register is dynamically mapped to from the multiple architectural registers at least one In multiple physical registers；

    When can not find the register of request in the mapping in the multiple physical register, in the multiple architectural registers Matching is searched for each register access request.
15. 15. according to the method for claim 14, it is characterised in that also include：By recording via at least one streamline Engine receive the multiple register access ask monitor it is described recently using and access frequency in it is at least one.