JP7217341B2 - How processors and registers are inherited - Google Patents

Description

The present disclosure relates to processors and register inheritance methods.

Cross-references to related applications

This application is based on Japanese Patent Application No. 2019-079383 filed in Japan on April 18, 2019, and claims the benefit of its priority. incorporated herein by reference.

Conventionally, processing with a large CPU (Central Processing Unit) load is sometimes divided into multiple threads and processed in parallel in order to improve response time and throughput. In heavy-load processing divided into multiple threads, each time the processing of the previous thread finishes, the result of the operation is stored from the register to memory. After that, the operation result is reloaded from the memory to the register, and processing of the subsequent thread is started (hereinafter referred to as "load/store processing").

In this load/store processing, only one PE (Processing Element) can access the memory. In particular, when there is only one memory, contention for memory access due to load/store processing frequently occurs. Therefore, load/store processing takes a long time in processing with a large number of threads and a large load. That is, load/store processing is expensive, and the greater the number of threads, the greater the impact on processing speed.

In order to eliminate memory access contention resulting from this load/store processing, it is conceivable to increase the number of memories. However, it is not a fundamental solution because it causes an increase in the area and cost of the processor and increases the complexity. For example, Patent Document 1 proposes a register content inheritance device in a processor in order to improve the above-described load/store processing problems related to scalar operations.

JP-A-2000-020326

The above-mentioned patent document 1 targets scalar operations, but unlike scalar operations, in vector operations, the area of registers used for operations is not fixed, but variable according to the vector length. Area cannot be specified. Therefore, the technique of scalar arithmetic cannot be used for vector arithmetic.

An object of the present disclosure is to provide a processor and a register inheritance method that reduce load/store processing as much as possible even in vector operations and improve processing performance.

The present disclosure employs the following technical means to solve the above problems. The symbols in parentheses described in the claims are an example showing the corresponding relationship with the specific means described in the embodiment described later as one aspect, and do not limit the technical scope of the present disclosure. .

To achieve the above object, a processor according to the present disclosure includes a plurality of arithmetic units, a thread scheduler that distributes threads to the plurality of arithmetic units, a register file shared by the plurality of arithmetic units, and , a register controller that allocates a register area used by a thread, and a management table that stores information identifying a thread and a register in association with the address of the register area to which the register is allocated, wherein the register controller allocates the previous When the registers used by a thread are to be inherited by a later thread, the area of the register to be inherited is not released even after the processing of the previous thread is completed, and the management associated with the address of the register area to be inherited is maintained. Rewrite the information in the table with information that identifies the later thread and register.

With this configuration, the register controller manages the inherited registers that are inherited from the previous thread to the subsequent threads using information that identifies the threads and registers. In vector operations, the register size (capacity) varies according to the vector length, so the register area cannot be specified simply by the register number. Later threads can inherit the register. As a result, load/store processing can be reduced as much as possible even in multithreaded vector operations, and processing performance can be improved.

FIG. 1 is a block diagram showing the configuration of a processor according to the first embodiment. FIG. 2A is a conceptual diagram of a register file before allocating registers to threads according to the first embodiment. FIG. 2B is a conceptual diagram of a register file after allocating registers to the first thread, the second thread, and the third thread according to the first embodiment. FIG. 2C is a conceptual diagram of the sizes of registers after allocating registers to the first thread according to the first embodiment. FIG. 2D is a conceptual diagram of the sizes of registers after allocating registers to the second thread according to the first embodiment. 3A is a diagram illustrating an example of a management table used by the processor according to the first embodiment; FIG. FIG. 3B is a diagram illustrating an example of a management table when inheriting the value of register number v0 from a previous thread to a subsequent thread according to the first embodiment; FIG. 4 is a flowchart of register processing performed by the processor according to the first embodiment when processing of a thread ends. FIG. 5 is a flowchart of register allocation processing performed by the processor according to the first embodiment when processing of a thread is started. FIG. 6 is a diagram for explaining saving and reloading of registers according to the second embodiment. FIG. 7 is a flow diagram of register allocation processing performed by the processor according to the second embodiment when processing of a thread is started.

Hereinafter, this embodiment will be described with reference to the drawings. In addition, this embodiment described below shows an example of the case of carrying out this invention, Comprising: It does not limit this invention to the concrete structure demonstrated below. In carrying out the present invention, a specific configuration according to the embodiment may be appropriately adopted.

(First embodiment)
[Processor configuration]
FIG. 1 is a block diagram showing the configuration of a processor according to the first embodiment. Processor 100 has cache 102 , register file 104 , arithmetic unit 106 , register controller 108 , thread scheduler 110 and local RAM 112 .

The processor 100 of the first embodiment processes a large number of threads obtained by analyzing and dividing a graph-structured program. Since multiple threads are generated by dividing the graph structure, the operation result output obtained in one thread may be used as input in the subsequent thread, so it is necessary to hand over the operation result between threads. . In addition, it is also necessary to reduce load/store processing in order to improve processing performance at the time of this handover.

Therefore, the processor 100 dynamically allocates register resources to a large number of threads and inherits the registers among the threads. As a result, the processor 100 can allocate multiple threads to the PEs 114 and execute them in parallel, even for different instruction streams, and further improve the processing performance.

Cache 102 is a cache placed between the host CPU and the computing unit 106 . Cache 102 may communicate with a system bus interface or a ROM interface.

The register file 104 is a register file that stores operation data (each register assigned to a thread is hereinafter referred to as a "register", and a plurality of registers assigned to a thread is referred to as a "register area").

This register file 104 will be specifically described with reference to FIG. In FIG. 2, description will be made with a particular focus on registers in vector operations. FIG. 2A is a conceptual diagram of the register file 104 before allocating registers to threads according to the first embodiment, and FIG. 2B shows the first thread t1, the second thread t2, FIG. 2C is a conceptual diagram of the register file 104 after allocating registers to the third thread t3, and FIG. 2C is a conceptual diagram of the size of the registers after allocating the registers to the first thread t1 according to the first embodiment; , and FIG. 2D is a conceptual diagram of the sizes of registers after the registers are allocated to the second thread t2 according to the first embodiment.

As shown in FIG. 2A, in the register file 104 before register areas are allocated to threads, register areas are allocated to all of the first thread t1, the second thread t2, and the third thread t3. do not have.

On the other hand, as shown in FIG. 2B, the register file 104 after allocating the register areas to the threads has continuous register areas for the first thread t1, the second thread t2, and the third thread t3. assigned.

Unlike scalar operations that sequentially operate on one element, vector operations simultaneously perform one operation on all data using a plurality of data as one register. The number of data elements is called vector length. The size of registers used for vector operations depends on this vector length. Therefore, the size of the registers is determined by the maximum size of the registers allocated to the threads.

For example, the first thread t1 has a larger vector length than the second thread t2. Therefore, as shown in FIG. 2C, the size of the registers v0 to v31 allocated to the first thread t1 is larger than the size of the registers v0 to v31 allocated to the second thread t2, as shown in FIG. 2D.

Returning to FIG. 1, the description continues. The arithmetic unit 106 is an execution unit that executes thread processing. The arithmetic unit 106 has multiple PEs 114 . PE 114 is a calculator. At least one of the plurality of PEs 114 is a vector calculator that performs vector calculations.

The register controller 108 is a register controller that allocates register areas to threads. The management table 116 is a table for managing registers used for thread processing. The PE 114 described above refers to the management table 116 to reserve and access registers.

The management table 116 associates and stores information identifying a thread and a register with the address of the register area to which the register is allocated. Specifically, the management table 116 associates keys with register addresses. A key has a thread ID (identifier) and a register number. That is, the management table 116 is a table for managing where in the register file the values of the registers used for the processing of the thread identified by the thread ID are stored.

FIG. 3A is a diagram showing an example of the management table 116 used by the processor 100 according to the first embodiment. As shown in FIG. 3A, the register with register number v0 of thread 0 is allocated an area starting at address 0xaaaa1234 (line 202), the register with register number v1 is allocated an area starting with address 0xbbbb1234 (line 204), The register with register number v2 is allocated an area starting at address 0xcccc1234 (line 206).

The register controller 108 releases the registers, for example, after processing of the thread is finished. Specifically, when terminating the processing of a thread, the register controller 108 sets a flag indicating that the area secured by the thread is available for use, thereby releasing the area.

Further, in the first embodiment, the register controller 108 does not release the register area even after the processing of the thread ends, and the register used in the thread can be inherited by the subsequent thread. Specifically, the register controller 108 sets a disabled flag so as not to release the register to be inherited. At the same time, the register controller 108 rewrites the information in the management table 116 associated with the address of the register area to be inherited to the later thread ID and register number. As a result, the register number and the address of the register are linked, and inheritance of the register can be performed even if the size of the register is variable.

Rewriting of the management table 116 will be specifically described with reference to FIG. 3B. FIG. 3B is a diagram showing an example of the management table 116 when inheriting the value of the register number v0 from the previous thread to the subsequent thread according to the first embodiment.

As shown in FIG. 3B, since the register number v0 of the previous thread 0 is inherited by the subsequent thread 1, a flag is set to disable the register number v0 of the previous thread 0, and the register area is retained without being released. . The key of the management table 116 is changed from "thread 0_v0" to "thread 1_v0" (row 302). As a result, the PE 114 that processes thread 1 refers to address 0xaaaa1234 as the register number v0 of thread 1 . Then, since this area is held as unusable, the value of the register with the register number v0 used by the previous thread 0 can be read from this area.

In this way, even in the vector operation, the operation result of the previous thread stored in register v0 at address 0xaaaa1234 is inherited by the subsequent thread without being saved in memory. It goes without saying that the value of the register v0 may be rewritten after the processing of the subsequent thread 1 is started.

On the other hand, since the register numbers v1 and v2 in FIG. 3A are not inherited by the subsequent thread 1, the allocated areas are released. Specifically, flags are set to indicate that these areas are usable.

As shown in FIG. 3B, register number v1 and register number v2 of thread 1 are not inherited from thread 0, so new areas are allocated. The area of address 0xbbbb5678 is allocated to register number v1 of subsequent thread 1 (line 304), and address 0xcccc5678 is allocated to register number v2 (line 306).

Returning to FIG. 1, the description continues. The thread scheduler 110 is a scheduler that allocates threads to the PEs 114 . Specifically, thread scheduler 110 passes the thread to PE 114 . The PE 114 refers to the management table 116 of the register controller 108, secures a register for processing this thread, and processes the thread.

Further, when there is register inheritance, the thread scheduler 110 designates to the register controller 108 the correspondence relationship between the subsequent thread succeeding the preceding thread and the register numbers inherited by the subsequent thread. The designated register controller 108 rewrites the management table 116 so that the later thread inherits the registers used by the earlier thread.

The local RAM 112 is a read/write volatile memory. It stores the calculation result of the calculation unit 106 and communicates with the system bus interface. It is also used to store all data saved from the register file 104, which will be described later.

[Processor operation]
Below, the flow which shows operation|movement of the processor 100 mentioned above is demonstrated. FIG. 4 is a flowchart of register processing performed by the processor 100 according to the first embodiment at the end of thread processing. Flow begins when the PE 114 has processed the previous thread.

First, the thread scheduler 110 designates a later thread to the register controller 108, and the register controller 108 determines whether or not there is a register inherited by the later thread (step S102).

When the register controller 108 determines that there is a register inherited by the subsequent thread (step S102: Yes), the inherited register is flagged as unusable (step S104).

After that, the register controller 108 rewrites the key of the management table 116 from the key of the previous thread to the key of the subsequent thread (step S106), sets a usable flag to the register other than the inherited register (step S108), Flow ends.

On the other hand, when the thread scheduler 110 does not designate a later thread to the register controller 108 and the register controller 108 determines that there is no register to be inherited by the later thread (step S102: No), the process ends. A usable flag is set in the register used by the thread (step S110), and the flow ends.

FIG. 5 is a flowchart of register allocation processing performed by the processor 100 according to the first embodiment at the start of thread processing. Flow begins when thread scheduler 110 assigns a later thread to PE 114 .

First, the register controller 108 allocates a register to a register area for which a usable flag is set in the management table 116 (step S202). Note that registers inherited from the previous thread need not be allocated here. The register controller 108 rewrites the key and address of the management table 116 with the key of the subsequent thread and the address of the register that processes the subsequent thread.

After that, the PE 114 refers to the management table 116, processes subsequent threads (step S204), and the flow ends.

In this way, processor 100 can inherit values obtained by processing a previous thread to subsequent threads by using register inheritance. This eliminates the load/store processing for the target data and improves the processing performance of the processor 100 .

Also, the processor 100 manages inherited registers using register addresses in addition to register numbers. As a result, register inheritance can be used even in vector operations in which the capacity of a register changes according to the vector length.

(Second embodiment)
[Processor configuration]
Next, the processor 100 according to the second embodiment will be explained. The basic configuration of the processor 100 according to the second embodiment is the same as the processor 100 of the first embodiment (see FIG. 1), but the processor 100 of the second embodiment has Unlike the processor 100, when fragmentation occurs in the register file 104, a process of allocating continuous register areas is performed.

Specifically, the register controller 108 determines, for example, whether or not a register area contiguous to the register file 104 can be secured in the register file 104 . When the register controller 108 determines that a continuous register area cannot be secured in the register file 104 due to fragmentation, the register data stored in the register file 104 is temporarily saved in the local RAM 112 .

Then, by reloading the data saved in the local RAM 112 into the register file 104 and allocating continuous areas to the registers, fragmentation is eliminated and the address of the register to be inherited in the management table 116 is updated.

Saving and reloading of this register will be specifically described with reference to FIG. FIG. 6 is a diagram for explaining saving and reloading of registers. As shown in FIG. 6, the area of register file 104 represents the capacity of register file 104 . The register controller 108 reserves a register area for processing threads in the register file 104 . The register controller 108, for example, secures a register area for operations of the thread t1 and the thread t2.

Register file 104 has an empty area sufficient to secure the registers required for thread t3. However, empty areas of registers are subject to fragmentation. Therefore, it may not be possible to secure a continuous register free area for processing the thread t3.

In particular, repeated register inheritance frees up space for registers only partially. Therefore, fragmentation of the register area is likely to occur. This makes it difficult for the register controller 108 to secure a continuous register area capable of processing threads.

When a continuous area cannot be secured for the registers required for the thread, the register controller 108 saves all the data stored in the register file 104 to the local RAM 112 .

The register controller 108 reloads all data from the local RAM 112 and reallocates a register area for each thread. At this time, the register controller 108 secures a register area for processing the thread t1 and the thread t2 so that there is no empty register area as much as possible. As a result, a contiguous register area is secured as a register necessary for subsequent processing of thread t3.

When reloading all the data from the local RAM 112 , the register controller 108 writes in the management table 116 the correspondence between threads, registers, and register area addresses. As a result, even when the registers are reassigned and the addresses of the registers are changed, the threads can access the registers based on the keys in the management table 116, so there is no effect on processing. In the first place, when the free space of the register file 104 is insufficient, the thread being processed is completed, the target register area is released, and at the time when the free space required for the next thread can be secured, the above-mentioned register can be restored. Allocation processing is performed.

[Processor operation]
The operation of the processor 100 according to the second embodiment differs from the second flow according to the first embodiment described above only for the second flow. Only this difference will be described below.

FIG. 7 is a flowchart of register allocation processing performed by the processor 100 according to the second embodiment at the start of thread processing. Unlike the flow according to the first embodiment, the flow according to the second embodiment saves all data from the register file 104 to the local RAM 112 when a continuous register area cannot be secured, and stores all the data again in the registers. Including reloading to file 104 . Flow begins when thread scheduler 110 assigns a later thread to PE 114 .

First, the register controller 108 determines whether or not a continuous register area for processing subsequent threads can be secured (step S302).

When the register controller 108 determines that a continuous register area for processing subsequent threads can be secured (step S302: Yes), the PE 114 allocates a register to the register area for which the available flag is set (step S304).

After that, the register controller 108 updates the key and address of the management table 116 to the key of the subsequent thread and the address of the register that processes the subsequent thread (step S310).

On the other hand, when the register controller 108 determines that a continuous register area for processing subsequent threads cannot be secured (step S302: No), it saves all data from the register file 104 to the local RAM 112 (step S306), All the data is reloaded from the local RAM 112 to the register file (step S308), and a continuous register area is reallocated for each thread.

After that, the register controller 108 updates the key and address of the management table 116 to the key of the subsequent thread and the address of the register that processes the subsequent thread (step S310).

After the registers are secured in the register area by the register controller 108 and the information of the registers and their addresses are stored in the management table 116, the PE 114 processes subsequent threads (step S312), and the flow ends.

As described above, in the second flow according to the second embodiment, unlike the second flow according to the first embodiment, all data is transferred from the register file 104 to the local register when a continuous register area cannot be secured. It has a step of saving to the RAM 112 and reloading all the data to the register file 104 again. As a result, the register controller 108 can eliminate the fragmentation of the register area, which tends to occur due to the use of register inheritance, and maintain high computational efficiency of the vector computation.

Claims (6)

a plurality of calculators (114);
a thread scheduler (110) that distributes threads to the plurality of computing units;
a register file (104) shared by the plurality of computing units;
a register controller (108) allocating a register area used by the thread to the register file;
a management table (116) storing information identifying the thread and the register in association with the address of the register area to which the register is allocated;
with
When the register used in the previous thread is to be inherited by the subsequent thread, the register controller does not release the area of the register to be inherited even after the process of the previous thread is completed. A processor (100) that rewrites the information in the management table associated with the address of the area to the information that identifies the subsequent thread and register. The register file processes not only single data but also vector registers capable of collectively handling a plurality of data,
2. The processor according to claim 1, wherein said plurality of calculators include calculators capable of processing vector registers as well. The register controller obtains information on the previous thread and registers to be inherited by the subsequent thread from the thread scheduler, and converts the information on the previous thread and registers to be inherited, stored in the management table, into the 3. A processor according to claim 1 or 2, which rewrites to later thread and register information. The register controller, when ending the processing of the previous thread, can use a register area other than the registers inherited by the subsequent thread, out of the register areas reserved in the previous thread. 4. The processor according to any one of claims 1 to 3, wherein the area is released by setting a flag indicating that it is. When the register controller cannot secure a continuous area in the register file for the registers used in the thread, the register controller temporarily saves the data of the registers stored in the register file to the memory, and saves the data in the memory. 5. The processor according to any one of claims 1 to 4, wherein data is reloaded into a register file to allocate contiguous areas to each register, and the management table is updated. a plurality of calculators (114);
a thread scheduler (110) that distributes threads to the plurality of computing units;
a register file (104) shared by the plurality of computing units;
a register controller (108) allocating a register area used by the thread to the register file;
a management table (116) storing information identifying the thread and the register in association with the address of the register area to which the register is allocated;
In a processor (100) comprising:
The register controller does not release the register area to be inherited by the subsequent thread even after the processing of the thread is completed, and stores the information in the management table associated with the address of the register area to be inherited. A register inheritance method that rewrites information that identifies later threads and registers.

Images