JP2011008617A - Multithread execution device, method of generating object program, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a multithread execution device, capable of adjusting the execution completion frequency of instructions per unit time by a CPU, a method for generating an object program, and a program.SOLUTION: The multithread execution device 100 includes a program storage means 26 which stores an object program generated from a source program; an instruction issuing means 11 which issues an instruction of the object program; and an instruction execution means 15 which executes the instruction. An adjustment code is inserted to the object program, the adjustment code adjusting so that execution completion speed information of the instruction is substantially matched to target execution speed information for each program read from a target execution rate information storage means 80.

Description

  More particularly, the present invention relates to a multithread execution device, an object program generation method, and a program that can adjust an instruction issue rate for each thread.

  Various methods for efficiently executing a program have been considered. Many of the conventional approaches for improving the execution efficiency try to reduce the time during which the arithmetic circuit of the CPU is not executing the program. For example, a technique for reducing waiting for confirmation of processing contents due to branching or user operation (see, for example, Patent Documents 1 and 3) and a technique for reducing software overhead due to input / output interrupts (for example, see Patent Document 2). A technique for reducing hardware overhead such as context switching has been proposed (see, for example, Patent Document 4).

  Patent Document 1 discloses a heterogeneous multiprocessor in which a portion of a program whose processing order can be determined statically is arranged according to the characteristics of a PU (Processing Unit) at the time of compilation. Patent Document 2 discloses an input / output subsystem call instruction control method for controlling intervention by a hypervisor by masking subsystem calls for accessing shared resources. The input / output subsystem call instruction control method described in Patent Document 2 aims to suppress overhead due to interrupts by controlling intervention by a hypervisor. Patent Document 3 discloses a thread that controls thread execution start and end, execution state switching, and data transfer between threads in a multithread processing apparatus that speculatively issues instructions to a plurality of processors. A multi-thread processing device having a manager is disclosed. The multi-thread processing device described in Patent Document 3 aims to improve the prediction accuracy of speculative execution by simultaneously executing a plurality of program paths. Patent Document 4 discloses a multi-thread execution method in which a program counter and a register set are fixedly assigned to a thread and a thread in a standby state and a thread in an execution state are switched in a multi-thread computer having a plurality of hardware threads. Has been. The multi-thread execution method described in Patent Document 4 aims to improve the processing speed because the time required for thread preparation can be reduced.

JP 2007-328416 A JP-A-6-35731 JP 2000-47887 A JP 2004-234123 A

  However, there is a problem that simply improving the execution efficiency as in the conventional techniques represented by Patent Documents 1 to 4 may affect a system having an execution timing dependency between two programs. .

  FIG. 1A is an example for explaining the relationship between the execution timing of the program # 0 and the execution timing of the program # 1. Program # 0 is executed by CPU_A1, and program # 1 is executed by CPU_B1. CPU_A1 and CPU_B1 are generally mounted in different microcomputers.

  Program # 0 executes process a, and program # 1 executes process b1 and process b2. The process b2 is executed using the processing result of the process a. In FIG. 1A, since the execution timings of the program # 0 and the program # 1 are designed to be synchronized, the CPU_B1 can execute the process b2 using the process result of the process a.

  FIG. 1B is a diagram illustrating an example of the relationship between the execution timing of the program # 0 and the execution timing of the program # 1 when the CPU_B2 executes the program # 1. CPU_B2 is a CPU having an IPC (Instructions Per Clock cycle) larger than that of CPU_B1 or a smaller number of execution cycles of unit processing, that is, a CPU having a higher execution speed. The execution timing of the process b1 is advanced by the CPU_B2 executing the program # 1. On the other hand, when the process b1 is completed, the CPU_A1 has not completed the process a. For this reason, when the CPU_B2 executes the process b2, the process result of the process a cannot be used. For example, the CPU_B2 executes the process b2 using the process result of the previous process a. Occurs.

  By the way, it has become possible to use a CPU equipped with hardware multithread technology and a multicore CPU in which a plurality of cores are mounted on one CPU. Therefore, it is considered that the program # 0 that has been executed by the plurality of CPU_A1 and the program # 1 that has been executed by the CPU_B1 are transplanted to one CPU and executed. Such a technique can be used, for example, when integrating a plurality of ECUs (Electronic Control Units) connected to the in-vehicle LAN into a smaller number of ECUs.

  However, since the CPU mounted on the ECU after integration has a different architecture from the CPU mounted on the ECU before integration, the program # 0 and the program # 1 that depend on execution timing are simply used as the ECU after integration. Just transplanting causes the same inconvenience as in FIG.

For such inconvenience, when different programs # 0 and # 1 are ported to the integration CPU, it is conceivable to adjust the instruction issue ratio.
FIG. 2A is an example of a diagram illustrating the relationship between CPU_A1 and CPU_B1 before integration and the CPU for integration. The operation clock of CPU_A1 is 60 MHz, and the operation clock of CPU_B1 is 180 MHz. In order to simplify the explanation, both IPCs are the same (IPC = 1), but both IPCs may be different. The operation clock of the integration CPU is 180 MHz. Therefore, the execution speed of CPU_B1 is three times that of CPU_A1. Note that vCPU_A1 and vCPU_B1 included in the integration CPU mean virtual CPUs.

In order to match the execution timings of the program # 0 executed by the CPU_A1 and the program # 1 executed by the CPU_B1, the instruction issue ratio in the integration CPU may be changed according to the original execution speed.
FIG. 2B is a diagram illustrating an example of the relationship between the instruction issue ratio and the number of execution completions. If the execution speed is three times different, the integration CPU issues an instruction to vCPU_A1 once every time the instruction is issued to vCPU_B1 three times. By doing so, the execution timings of the program # 0 executed by the CPU_A1 before the integration and the program # 1 executed by the CPU_B1 may be adjusted to some extent even in the integration CPU.

  However, the integration CPU and CPU_A1 and CPU_B1 differ not only in the operating frequency but also in the number of instruction execution completions per unit time such as an instruction set and IPC. If the integration CPU has a pipeline with a large number of stages or a plurality of pipelines, the number of instruction execution completions per unit time will change due to hazards or stalls. Even if it is determined, the desired instruction execution ratio cannot be obtained.

  Therefore, only by controlling the instruction issue rate, the number of instruction execution completions per unit time of vCPU_A1 and the number of instruction execution completions per unit time of CPU_A1, and the number of instruction execution completions per unit time of vCPU_B1 and CPU_B1 The number of instruction execution completions per unit time cannot be matched. For example, even if the instruction issue ratio is controlled, the number of instruction execution completions of programs # 0 and # 1 in a unit time repeatedly fluctuate, and the execution timings of program # 0 and program # 1 are greatly different in the end. turn into.

  That is, when a plurality of programs # 0, # 1 are integrated using conventional multi-thread technology or multi-core, there is a problem that the execution timing of the plurality of programs # 0, # 1 before integration cannot be guaranteed. .

  In view of the above problems, an object of the present invention is to provide a multithread execution device, a method for generating an object program, and a program that can adjust the number of execution completions of instructions per unit time by a CPU.

  A multi-thread execution device comprising: a program storage unit that stores an object program generated from a source program; an instruction issue unit that issues an instruction of an object program generated from the source program; and an instruction execution unit that executes the instruction In the object program, an adjustment code for adjusting the instruction execution completion speed information so as to substantially match the target execution speed information for each program read from the target execution speed information storage means is inserted. It is characterized by being.

  It is possible to provide a multi-thread execution device, an object program generation method, and a program that can adjust the number of execution completions of instructions per unit time by a CPU.

FIG. 10 is an example of a diagram illustrating the relationship between the execution timing of program # 0 and the execution timing of program # 1. It is an example of the figure explaining the relationship between CPU_A1 before integration, CPU_B1, and CPU for integration. 1 is an example of a schematic configuration diagram of a multi-thread execution device 100. FIG. It is a figure which shows typically an example of the relationship between thread | sled # 0-# 2 and a hardware resource. It is an example of the schematic block diagram of an execution condition monitoring apparatus. It is an example of the figure which illustrates insertion of the code for adjustment by a compiler typically. It is an example of the figure which shows an application execution profile typically. It is a figure which shows an example of the calculation procedure of target IPC. It is an example of the figure which shows typically the relationship between target IPC (execution timing before integration) and application execution profile. An example of the scheduling ratio table which registered whether the execution ratio of application execution program # 0-2 should be decreased, should be increased, or should maintain the present condition is shown. It is an example of the figure explaining adjustment of an execution ratio. It is an example of the figure explaining the effect of a multithread execution apparatus. It is an example of the flowchart figure which shows the procedure in which a multithread execution apparatus adjusts the execution ratio of a thread. It is an example of the schematic block diagram of a multithread execution apparatus. It is an example of the schematic block diagram of a multithread execution apparatus. It is an example of the schematic block diagram of a multithread execution apparatus.

Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings.
FIG. 3 shows an example of a schematic configuration diagram of the multithread execution apparatus 100. The multi-thread execution device 100 includes a microcomputer 200 in which, for example, three pre-integration ECUs (Electronic Control Units) are integrated.

First, an outline of a procedure in which the multi-thread execution device 100 adjusts the number of execution times of instructions of each program in a unit time (hereinafter sometimes simply referred to as an execution speed) will be described. By adjusting the number of executions of instructions of each program, the execution ratio of each program is also adjusted.
(1) Application execution programs # 0 to # 2 are stored in the memory 26. The application execution programs # 0 to # 2 are obtained by compiling, for example, three programs (program # 0, program # 1, and program # 2). The pre-compiled programs # 0 to # 2 are stored in the application source storage unit 80.
The application source storage unit 80 also stores pre-integration execution speed information (the number of instruction execution completions of each program per unit time or the number of execution cycles per unit process) of each program # 0 to # 2 in the CPU before integration. It is remembered.
(2) The execution status monitoring device 14 monitors the execution status of each application execution program # 0 to # 2 (hardware / multithread). Specifically, the number of instruction execution completions of each application execution program # 0 to # 2 per unit time or the number of execution cycles per unit process is counted.
(3) The profiler 12 generates an application execution profile from the number of instruction execution completions per unit time or the number of execution cycles per unit process monitored by the execution status monitoring device. The application execution profile is a file in which the actual execution state of each application execution program # 0 to # 2 is recorded with time.
(4) The compiler 24 compares the application execution profile with the pre-integration execution speed information before the integration, and provides an adjustment code for adjusting the instruction issue frequency to any one or more of the application execution programs # 0 to # 2. insert.
(5) If the above process is repeated several times, the actual execution speed of the application execution programs # 0 to # 2 will be approximately the same as the execution speed before integration.

  Therefore, even if a plurality of ECU programs # 0 to # 2 are integrated and installed in the multi-thread execution device 100, the execution speed of the application execution programs # 0 to # 2 is substantially the same as that executed by the CPU before the integration. be able to. As a result, the execution ratio of the application execution programs # 0 to # 2 can be made substantially the same as when executed by the CPU before integration.

  Further, since it is not necessary to recode the programs # 0 to 2 before and after the integration, the cost can be reduced. In addition, since it is not necessary to examine the timing dependence of the programs # 0 to # 2, software distribution is greatly improved. Further, by using the number of execution cycles of unit processing for feedback control, integration into different types of microcomputers becomes possible.

[Hardware Configuration of Multi-Thread Execution Device 100]
As shown in FIG. 3, the multi-thread execution device 100 includes a microcomputer 200 and a development environment 300. The microcomputer 200 includes a processor 50, a memory 26 connected via the instruction-side memory bus 22, and a data storage unit 27 connected via the data-side memory bus 23. The development environment 300 includes a profiler 12, an application execution profile storage unit 70, an application execution program storage unit 60, a compiler 24, and an application source storage unit 80. Of course, the development environment 300 becomes unnecessary at the stage of being mounted on the vehicle. The application execution profile storage unit 70, the application execution program storage unit 60, and the application source storage unit 80 have, for example, an HDD (Hard Disk Drive) or an SSD (Solid State Drive) as an entity. There is no need to provide these three members separately.

  The processor 50 has a hardware multithread type execution environment. The hardware multithread means a structure in which a plurality of instruction buffers 17 and a register file 16 (system registers or the like) are provided, and instructions are executed by appropriately switching these. Note that a program, a part of the function, and the like may be referred to as a thread as a process execution unit, but the thread in this embodiment refers to a hardware instruction supply / execution means. In FIG. 3, since the three instruction buffers 17 and the three register files 16 are included, the multi-thread execution device 100 includes three threads # 0 to # 2.

  FIG. 4 is a diagram schematically illustrating an example of the relationship between threads # 0 to # 2 and hardware resources. Since the multi-thread execution device 100 executes different programs by switching each thread in one clock, the multi-thread execution device 100 behaves as having a plurality of virtual CPUs by one processor 50 that physically exists. Therefore, the instruction buffer # 0 to the arithmetic circuit 15 are referred to as thread # 0, the instruction buffer # 1 to the arithmetic circuit 15 are referred to as thread # 1, and the instruction buffer # 2 to the arithmetic circuit 15 are referred to as thread # 2. The threads # 0 to # 2 and other peripheral circuits are collectively referred to as vCPUs (virtual CPU) # 0 to # 2. In this way, by having a plurality of virtual vCPUs # 0 to # 2, different application execution programs # 0 to # 2 that have been independently executed by the ECU before integration can be executed independently.

  Although the present embodiment will be described for hardware and multi-thread, the execution speed of each program can be adjusted even for the multi-core microcomputer 200. In this case, it is only necessary to have a thread schedule device common to the multi-cores.

  The instruction buffers # 0 to # 2 are connected to the instruction-side memory bus 22, respectively. The instruction-side memory bus 22 is connected to a memory 26 such as an EEPROM that stores application execution programs # 0 to # 2. The thread schedule device 11 outputs the address of a program counter (not shown) provided for each of the instruction buffers # 0 to # 2 to the instruction-side memory bus 22, and stores the application execution programs # 0 to # 0 in the instruction buffers # 0 to # 2. Read instruction # 2 one by one. The instruction buffers # 0 to # 2 are connected to the changeover switch 19. The changeover switch 19 is a switch that connects only one instruction buffer 17 to the instruction decoder 18 at the same time.

  The thread schedule device 11 is a device that selects instruction buffers # 0 to # 2 that issue instructions. As will be described later, the thread schedule device 11 adjusts a thread that issues an instruction in accordance with a signal from the arithmetic circuit 15. By doing so, the IPC (Instructions Per Clock cycle) can be controlled independently for each program, and the instruction issue ratio can be controlled.

  The thread schedule device 11 is connected to two changeover switches 19 and 21, respectively. The instruction buffer # connected to the instruction decoder 18 is switched by switching the connection destination of the changeover switch 19 to one of the instruction buffers # 0 to # 2. Switch between 0 and # 2. Instructions of threads # 0 to # 2 selected by the thread schedule device 11 are read from the instruction buffers # 0 to # 2 and sent to the instruction decoder 18. The thread schedule device 11 can also disconnect all of the instruction buffers # 0 to # 2 from the instruction decoder 18. Similarly, the thread schedule device 11 switches the register file # 0 to # 2 used by the instruction decoder 18 and the arithmetic circuit 15 by switching the connection destination of the changeover switch 21 to one of the register files # 0 to # 2. .

  The instruction decoder 18 decodes the instruction, transfers the decoded result to the register file # 0 to # 2 of the thread, and sends it to the pipeline control circuit 13. The register files # 0 to # 2 are a group of registers that temporarily store the calculation result of the calculation circuit 15 and the data read from the data storage unit 27 connected to the data-side memory bus 23. The result of decoding by the instruction decoder 18 is, for example, the type of operation, one or more source operands, the result storage location, and the like. Since the source operand is supplied to the register file 16, the register used by the arithmetic circuit 15 for the operation is specified.

  When the instruction decoder 18 sends the type of operation to the pipeline control circuit 13, the pipeline control circuit 13 specifies the operation to be executed by the operation circuit 15. The arithmetic circuit 15 performs an operation on the data stored in the register file 16 according to the type of operation. Various types of calculation contents are prepared according to the calculation circuit 15 such as store, load, addition, multiplication, division, and branch. In the case of a store or load instruction, the arithmetic circuit 15 designates the calculated address and fetches data from the data-side memory bus 23. Then, the arithmetic circuit 15 writes back the operation result such as addition or the read data to the register designated by the result storage location in the register file 16.

  The pipeline control circuit 13 controls each stage of the above pipeline control (instruction fetch, instruction decode, instruction execution, operand fetch, write back, etc.) based on the operation clock. In pipeline processing, hazards (factors that hinder the completion of processing in each stage within a fixed time) are unavoidable, so the pipeline control circuit 13 refers to the type of operation, source operand, etc. Processing such as causing a stall in the line, inserting a NOP instruction, or flushing the contents of each stage that has become unnecessary due to branching is performed. For example, when a hazard such as waiting for I / O occurs in a certain thread (for example, thread # 0), the pipeline control circuit 13 causes the thread scheduling device 11 to stop the thread # 0, and another thread (for example, thread # 0). Request to execute 1).

  The pipeline control circuit 13 is connected to the execution status monitoring device 14. The execution status monitoring device 14 counts the number of instruction execution completions per unit time or the number of execution cycles of unit processing for each thread (hereinafter simply referred to as “count value” when they are not distinguished from each other).

[Execution status monitoring device 14]
FIG. 5 shows an example of a schematic configuration diagram of the execution status monitoring device 14. The execution status monitoring device 14 includes an execution status monitoring unit 141 and a counter unit 142. The number of instruction execution completions per unit time or the number of execution cycles of unit processing represents the instruction execution speed in a broad sense. The number of instruction execution completions per unit time is one or more of the application execution programs # 0 to # 2 when the compiler before the integration and the instruction set architecture (ISA) of the vCPUs # 0 to # 2 are the same. Used when inserting the adjustment cord into The number of execution cycles of unit processing is used when the compiler 24 inserts the adjustment code into any one or more of the application execution programs # 0 to # 2 when the ISA is different.

  ISA means a set of instruction formats (binary opcodes) implemented in the CPU. Therefore, if the ISA is the same, the number of execution cycles until execution of a certain instruction is completed is the same for the CPU before integration and the vCPUs # 0 to # 2. In this case, the difference in the number of instruction execution completions per unit time can be attributed only to the operating frequency. On the other hand, if the ISA is different, the number of execution cycles until execution of a certain instruction is completed differs between the CPU before integration and the vCPU, so the number of instruction execution completions per unit time does not match the progress of instruction execution completion on the source code. . For this reason, when the CPU before integration and the ISAs of the vCPUs # 0 to # 2 are different, the compiler 24 uses the number of execution cycles of unit processing so that the execution progress on the source code matches. Insert the code.

-Number of instruction execution completions per unit time First, the count of instruction execution completions per unit time will be described. The pipeline control circuit 13 sends data to a circuit or a register while changing one instruction to each stage of pipeline processing. Therefore, it is known to the pipeline control circuit 13 that execution of one instruction has been completed (for example, when writing back to the register file 16). Further, it is clear from the state of the thread schedule device 11 and the changeover switch 19 which thread # 0 to # 2 has executed the instruction. The pipeline control circuit 13 outputs instruction execution completion information to the execution state monitoring device 14 when execution of one instruction is completed. Specifically, the pipeline control circuit 13 and the execution status monitoring device 14 are connected by signal lines as many as the number of threads, and the pipeline control circuit 13 outputs a High signal to the signal line corresponding to the thread that has completed execution. .

  When acquiring the instruction execution completion information, the execution status monitoring unit 141 requests the counter unit 142 to count up. Specifically, a High signal is output to count circuits # 0 to # 2 provided for each thread. Accordingly, the counter unit 142 can count the number of execution completion instructions that have been executed for each thread. The larger the number of instruction execution completions per unit time, the higher the execution speed.

  The counter unit 142 outputs a count value to the profiler 12 every unit time. The execution status monitoring unit 141 resets (returns to zero) the counter unit 142 immediately after the counter unit 142 outputs the count value to the profiler 12. Therefore, the counter unit 142 can output the instruction execution completion number per unit time to the profiler 12. The unit time is, for example, about x10 to 1000 of the operation clock. If the unit time is too short, the variation of the count value is large, and if the unit time is too long, it is difficult to control the execution time ratio. Therefore, the number of execution cycles that is not extremely short as the unit time is set in the execution status monitoring device 14.

-Number of execution cycles of unit processing The counting of the number of execution cycles of unit processing will be described. The unit process is a function that summarizes a series of processes, for example. For example, in C language, “function name˜ {Return;}” is one unit process. When the processor 50 executes the compiled object code, a predetermined code for initialization and post-processing of the stack pointer is described in the object code by the compilation at the beginning and end of the function, respectively. When the pipeline control circuit 13 detects a code indicating the start and end of these functions from the instruction decoder 18, it outputs a High signal to the execution status monitoring device 14.

  The execution status monitoring unit 141 requests the counter unit 142 to start counting the operation clock when the high signal at the start of the function is acquired, and causes the counter unit 142 to output the count value to the profiler 12 when the high signal at the end is acquired. . In addition, the execution status monitoring unit 141 resets (returns to zero) the counter unit 142 every time a High signal is acquired. Therefore, the counter unit 142 can count and output the number of execution cycles (the number of execution cycles for each unit process) necessary for completing the execution of the function. The larger the number of execution cycles per unit process, the slower the execution speed.

  By using the number of execution cycles of unit processing for feedback control, for example, a plurality of programs # 0 to # 2 can be ported to different types of microcomputers having different ISAs.

  As will be described later, the adjustment of the execution speed is facilitated by inserting the adjustment code every unit time in which the instruction execution completion count is counted or every execution cycle number of the unit processing. For this reason, if the execution speed is adjusted for each number of execution cycles of unit processing, an adjustment code is inserted for each execution cycle number of basic block units if the adjustment of the execution speed is delayed. A basic block is a group of instructions that are executed in succession except for special situations such as interrupts. For example, it is a series of instructions from the branch destination by the branch instruction to the next branch. Since the basic block is a unit smaller than the task, the execution speed can be adjusted at an appropriate timing. The break of the basic block can be detected from the instruction by the pipeline control device 13.

[Inserting adjustment code by compiler 24]
FIG. 6 is an example of a diagram for schematically explaining the insertion of the adjustment code by the compiler 24. First, generation of an application execution profile by the profiler 12 will be described.
FIG. 7A is an example of a diagram schematically illustrating an application execution profile. Although the horizontal axis represents time and the vertical axis represents IPC, the number of execution cycles per unit process may be used. When the execution status monitoring device 14 outputs the number of instruction execution completions per unit time to the profiler 12 for each of the application execution programs # 0 to # 2, the profiler 12 generates an application execution profile as shown in FIG. And stored in the application execution profile storage unit 70.

  FIG. 7B shows an example of an application execution profile in which the application execution profiles of the application execution programs # 0 to # 2 are superimposed on time. FIG. 7B shows the execution ratio of each of the application execution programs # 0 to # 2 at a certain time, and the area ratio is equal to the execution time ratio of the application execution programs # 0 to # 2. The multi-thread execution device 100 of the present embodiment is characterized in that the execution ratio of such application execution programs # 0 to # 2 is set to the same level as before integration.

<Execution speed information before integration>
FIG. 7C shows an example of the IPC of the application execution programs # 0 to # 2 by the CPUs # 0 to # 2 before integration. If such an execution speed of the three application execution programs # 0 to # 2 in FIG. 7C can be maintained by the multithread execution device 100, the instruction issue ratio of the application execution programs # 0 to # 2 is appropriate. It will be.

  However, when porting the programs # 0 to # 2 to the microcomputer 200, the application execution programs # 0 to # 2 executed by the CPUs # 0 to # 2 before the integration are transferred to the vCPUs # 0 to # 2 having a high processing capability. Often run. For this reason, if the application execution programs # 0 to # 2 are executed by maximizing the processing capability of the vCPUs # 0 to # 2, the amount of calculation per unit time increases. That is, the execution speed of the application execution programs # 0 to # 2 by the vCPUs # 0 to # 2 cannot be guaranteed.

  Therefore, a method for determining the target IPC in the vCPUs # 0 to # 2 from the IPCs of the application execution programs # 0 to # 2 by the CPUs # 0 to # 2 before integration will be described.

FIG. 8A is a diagram illustrating an example of a target IPC calculation procedure. As shown in the figure, the target IPC is calculated by the following equation.
Target IPC = IPC of CPU before integration / ratio of CPU operating frequency before integration and vCPU operating frequency (1)
If the CPU before integration and the ISAs of vCPUs # 0 to # 2 are the same, the execution speed may be determined by the operating frequency. Therefore, if the target IPC is obtained from the ratio of the operating frequency of the CPU before integration and the operating frequency of the vCPU. Good. The operating frequency of the CPU before the integration and the operating frequency of the vCPU are known to the compiler 24, for example.

  In general, since the operating frequency of the vCPU is higher than that of the CPU before integration, the ratio between the operating frequency of the CPU before integration and the operating frequency of the vCPUs # 0 to # 2 is often 1 or more. For example, when the IPC of the CPU before integration is “0.8”, for example, and the ratio between the operating frequency of the CPU before integration and the operating frequency of the vCPUs # 0 to # 2 is “2”, the target IPC is “0. 4 ". As shown in FIG. 7C, the target IPC is obtained by dividing the IPC of the application execution programs # 0 to # 2 by the CPUs # 0 to # 2 before integration by the operating frequency ratio “2”.

Further, the pre-integration execution speed information may be calculated from the number of execution cycles of unit processing instead of the IPC. FIG. 8B is a diagram showing an example of a procedure for calculating the target number of cycles as pre-integration execution speed information. As shown in the figure, the target number of execution cycles is calculated by the following equation.
Target execution cycle number = number of execution cycles of unit processing in CPU before integration × ratio of CPU operating frequency before integration and vCPU operating frequency (2)
When the CPUs before integration and the ISAs of the vCPUs # 0 to # 2 are not the same, the number of execution cycles of the same unit process is different between them, and therefore the number of execution cycles of the unit process may be adjusted by the ratio of the operating frequencies.

  For example, when the number of execution cycles of the unit processing of the CPU before integration is “100” and the ratio between the operating frequency of the CPU before integration and the operating frequency of the vCPUs # 0 to # 2 is “2”, the target number of execution cycles Becomes “200”. That is, since the vCPUs # 0 to # 2 are faster than the CPUs before integration, it is necessary to increase the number of execution cycles of unit processing.

  Similarly to FIG. 7C, the target number of executions of the application execution programs # 0 to # 2 by the CPUs # 0 to # 2 before integration is multiplied by the operation frequency ratio “2”. The number of execution cycles is obtained.

<Adjustment code>
Returning to FIG. 6, the adjustment code will be described. The pre-integration execution speed information of each program is obtained in the application source storage unit 80, and the application execution profile is stored in the application execution profile storage unit 70. In this state, the compiler 24 inserts an adjustment code for adjusting the instruction issue ratio into the application execution programs # 0 to # 2 while comparing the two for each unit time or for each unit process.

  FIG. 9 is an example of a diagram schematically illustrating the relationship between the target IPC and the application execution profile. In FIG. 9, the ratio between the operating frequency of the CPU before integration and the operating frequency of the vCPU is “2”. Therefore, if the IPC of the CPU before integration is “0.8”, the target IPC is “0.4”, and if the IPC of the CPU before integration is “0.75”, the target IPC is “0.35”. It has become.

  For example, when comparing IPC for each task, the average IPC of task 1 (time T0 to T99) in the application execution profile is “0.28”. Since the target IPC is “0.4”, the compiler 24 determines that the execution speed needs to be increased because the execution speed of this program (any one of # 0 to # 2) is low.

  Also, for example, the average IPC of task 2 (time T100 to T199) in the application execution profile is “0.45”. Since the target IPC is “0.4”, the compiler 24 determines that the execution speed needs to be reduced because the execution speed of the program (any one of # 0 to # 2) is high.

  The compiler 24 compares the IPC of the application execution profile with the target IPC for each unit process (for each task) or for each basic block. This is performed for each of the application execution programs # 0 to # 2. By doing so, it is possible to determine whether the execution speed of the application execution programs # 0 to # 2 should be increased, decreased, or maintained for each task and each basic block.

  FIG. 10 shows an example of a scheduling ratio table that registers whether the execution speed of the application execution programs # 0 to # 2 should be reduced, increased, or maintained. The time zone represents, for example, one task or basic block. Therefore, the adjustment code inserted into the application execution programs # 0 to # 2 does not always have the same timing when executing the application execution programs # 0 to # 2.

There are the following two modes in which the compiler 24 inserts the adjustment code for adjusting the execution speed into the application execution programs # 0 to # 2.
(A) A mode in which an adjustment code corresponding to the scheduling ratio table is added to the head of the task code. (B) A task for scheduling adjustment (the entire task becomes the adjustment code) and the entire scheduling ratio table. Aspect of storing in the application source storage unit 80 and adding as an object to the application execution program storage unit 60 In any of the aspects, the adjustment code is compiled by the compiler 24, so the processor 50 together with the application execution program # 0-2 Executed. The compiler 24 may insert the adjustment code together with the compilation, or may insert the adjustment code into the object code after the compilation.

  In the aspect of (A), when the adjustment code is executed by the arithmetic circuit 15, the processor 50 calls the scheduler of the OS, for example, and sets the execution speed of the application execution programs # 0 to # 2 to “large”, “small”, “ The speed adjustment information on how to adjust the “current” is set in the thread schedule device 11. Actually, the speed adjustment information is realized by a flag or the like. For example, when the speed adjustment information of the application execution program # 0 is “large”, the thread schedule device 11 increases the issuance ratio of the instructions of the application execution program # 0 than before. Further, for example, when the speed adjustment information of the program # 1 is “small”, the thread schedule device 11 decreases the issuance ratio of instructions of the program # 1 than before. When “large” speed adjustment information is set from two or more of the plurality of application execution programs # 0 to # 2, the thread schedule device 11 issues instructions from the application execution programs # 0 to # 2 having the highest priority. Adjust the ratio. It is assumed that the processing capacity of the processor 50 has a margin in advance so that the execution speed can be adjusted even in such a situation. That is, the processor 50 has more processing capacity than the total of the CPUs before integration.

  Also, the adjustment code is not a binary value of “many” or “small”, but a multi-stage numerical value of “+5” to “+1” for “many”, and “−5” to “−1” for “small”. Multi-stage numerical values may be used. Such a numerical value is determined by the compiler 24 according to the difference between the target IPC and the IPC of the application execution profile. Then, the OS sets multi-value speed adjustment information in the thread schedule device 11. In this case, the thread schedule device 11 adjusts the issue frequency of each instruction of the programs # 0 to # 2 according to the multivalued value.

  In the aspect of (A), it is not necessary for the OS to set the speed adjustment information in the thread schedule device 11, and the application execution programs # 0 to # 2 may directly set the driver adjustment program. May be set by calling.

  In the aspect of (B), the task for scheduling adjustment reads the scheduling ratio table at the start of execution of each of the application execution programs # 0 to # 2, and the speed adjustment information according to the progress of the application execution programs # 0 to # 2. Is set in the thread schedule device 11. The adjustment of the scheduling ratio by the thread schedule device 11 is the same as in the aspect (A).

  As described above, the adjustment code for adjusting the execution speed is inserted into one or more of the application execution programs # 0 to # 2.

[Adjustment of execution speed]
FIG. 11 is an example of a diagram illustrating adjustment of execution speed. When the arithmetic circuit 15 executes the adjustment code, the arithmetic circuit 15 sets the speed adjustment information of each program in the thread schedule device 11.

  The thread schedule device 11 controls the changeover switch 19 to switch the connection between the instruction buffers # 0 to # 2 and the instruction decoder 18. In this way, the threads # 0 to # 2 that execute the application execution programs # 0 to # 2 whose execution speed is to be increased are connected with the instruction decoder 18 at a high frequency, and the application execution programs # 0 to # 0 whose execution speed is to be decreased are set. The threads # 0 to # 2 executing # 2 are less frequently connected to the instruction decoder 18. Therefore, the processor 50 can bring the application execution profile closer to the pre-integration execution speed information.

  FIG. 12 is an example of a diagram for explaining the effect of the multi-thread execution device 100. The actually measured IPC in FIG. 12A is an IPC when the application execution programs # 0 to # 2 in a state where no adjustment code is inserted are executed by the microcomputer 200. As shown in the figure, the measured IPC is larger than the target IPC.

  FIG. 12B shows an example of the relationship between the measured IPC and the target IPC when executed by the microcomputer 200 with the adjustment code inserted. By adjusting the execution speed of the application execution programs # 0 to # 2, the difference between the target IPC and the IPC when executed by the microcomputer 200 can be reduced as shown in FIG.

  Also, as shown in FIG. 12B, if the measured IPC is larger than the target IPC, the execution speed can be further adjusted by inserting an adjustment code, and if the measured IPC is smaller than the target IPC. The execution speed can be further adjusted by inserting an adjustment code.

[Operation procedure]
FIG. 13 shows an example of a flowchart showing a procedure for adjusting the thread execution speed by the multi-thread execution device 100. Before the procedure of FIG. 13, the adjustment code is inserted into the application execution programs # 0 to # 2. The flowchart of FIG. 13 starts when the multithread execution apparatus 100 is activated.

  Immediately after the activation, the thread schedule device 11 connects the instruction buffers # 0 to # 2 and the instruction decoder 18 according to the instruction issue ratio of the initial thread (for example, with the same issue ratio).

  When the adjustment code inserted into the application execution programs # 0 to # 2 is executed by the arithmetic circuit 15, for example, the scheduler of the OS sets the speed adjustment information in the thread schedule device 11 (S10).

  Since the speed adjustment information is also set in the thread schedule device 11 from other application execution programs, the thread schedule device 11 refers to the priorities of the three application execution programs # 0 to # 2 (S20).

  Since the thread schedule device 11 adjusts the execution speed in order from the application execution programs # 0 to # 2 having the highest priority, the thread scheduling apparatus 11 determines the order in which the execution speed of the application execution program is adjusted based on the priority (S30). .

  Further, since there may be application execution programs # 0 to # 2 having the same priority, the thread schedule device 11 determines whether there are application execution programs # 0 to # 2 having the same priority (S40). ). When there is no application execution program # 0 to # 2 having the same priority (No in S40), the execution speed of the application execution programs # 0 to # 2 having the highest priority is adjusted (S50). When there are application execution programs # 0 to # 2 having the same priority (Yes in S40), for example, the thread schedule device 11 switches an application execution program for adjusting the execution speed each time an instruction is executed (S60). . First, application execution programs # 0 to # 2 in which speed adjustment information is set may be prioritized.

  Then, the thread schedule device 11 determines whether or not the application execution programs # 0 to # 2 with the next lowest priority set the speed adjustment information after the adjustment of the application execution programs # 0 to # 2 with the higher priority is completed. Is determined (S70). Next, when the application execution programs # 0 to # 2 with the lowest priority set speed adjustment information (Yes in S70), the processor 50 repeats the processing from step S40. As described above, the execution speed is adjusted with priority from the application execution program having a higher priority.

  As described above, the multi-thread execution device 100 according to the present embodiment inserts the adjustment code for adjusting the instruction execution speed into the application execution program by the compiler 24, so that each of the threads # 0 to # 2 The execution speed can be adjusted. Therefore, when a plurality of ECUs are integrated into one, the execution speed of each ECU before integration can be maintained without recoding. In addition, even if the programs # 0 to # 2 are ported to another CPU, the CPU at the porting destination behaves in the same manner as before the porting, so that it is not necessary to redesign the programs # 0 to # 2. Distribution of # 0 to # 2 is improved. In particular, if an adjustment code is generated according to the number of execution cycles of unit processing, integration into different types of microcomputers becomes possible.

[Preferred modification]
Multi-thread execution device 100 with one thread
Although the description has been made on the assumption that the multi-thread execution device 100 has a plurality of threads, the multi-thread execution device 100 may have only one thread.
FIG. 14 shows an example of a schematic configuration diagram of the multi-thread execution device 100. 14, the same parts as those in FIG. 3 are denoted by the same reference numerals, and the description thereof is omitted. When there is one thread, the instruction buffer 17 and the register file 16 are also one. Since a thread schedule is unnecessary, an instruction issue control circuit 28 is connected to the instruction buffer 17 instead of the thread schedule device 11. The instruction issuance control circuit 28 controls the timing at which an instruction is fetched to the instruction buffer 17 according to the speed adjustment information set by the arithmetic circuit 15 executing the adjustment code. That is, when the speed adjustment information is “small”, the instruction issuance control circuit 28, for example, disconnects the connection between the instruction buffer 17 and the instruction decoder 18 once every two clocks, or causes a stall in the pipeline. Insert a NOP instruction. By doing so, the number of instruction execution completions per unit time can be reduced, or the number of execution cycles of unit processing can be increased, and the execution speed of the application execution program by the CPU before integration can be reproduced. When the speed adjustment information is “large”, the instruction issuance control circuit 28 increases the connection ratio, for example, by connecting the instruction buffer 17 and the instruction decoder 18 three times in four clocks. By doing this, the number of instruction execution completions per unit time can be increased, or the number of execution cycles of unit processing can be reduced, and an execution speed comparable to that of the CPU before integration can be reproduced.

FIG. 15 illustrates an example of a schematic configuration diagram of the multi-thread execution device 100. FIG. In FIG. 15, the same parts as those in FIG. The multi-thread execution device 100 of FIG. 15 does not have the execution status monitoring device 14, the application source storage unit 80 is the compiler 24, the compiler 24 is the application execution program storage unit 60, and the application execution program storage unit 60 is the simulator 29. The simulator 29 is connected to the standard profile storage unit 71, and the standard profile storage unit 71 is connected to the compiler 24.

  In the multithread execution device 100 of FIG. 15, the simulator 29 generates a standard profile instead of the application execution profile instead of the execution status monitoring device 14. The application execution profile is execution speed information when the application execution programs # 0 to # 2 are executed by the microcomputer 200, whereas the standard profile is execution speed information set artificially or mechanically. In the standard profile, for example, the designer sets a certain number of execution cycles of IPC or unit processing as the approximate number of execution cycles of IPC or unit processing of the multithread execution apparatus 100. By doing so, the simulator 29 can generate an IPC per unit time or the number of execution cycles of unit processing for each application execution program. Alternatively, each instruction may be weighted by the number of clocks for each type of calculation of the application execution program, and the IPC and the number of execution cycles of each instruction when the CPU of the multithread execution apparatus 100 executes the program may be calculated. Since the simulator 29 simulates the existing multithread execution device 100, the number of clocks required for each type of operation can be easily specified, and the execution result by the multithread execution device 100 can be accurately simulated.

The form without the execution status monitoring device 14 can also be applied to the multi-thread execution device 100 with one thread.
FIG. 16 shows an example of a schematic configuration diagram of the multi-thread execution device 100. In FIG. 16, the same parts as those in FIG. 15 are denoted by the same reference numerals, and the description thereof is omitted. The multi-thread execution device 100 of FIG. 16 has an instruction issue control circuit 28 instead of the thread schedule device, and has a simulator 29 instead of the profiler 12. Since the simulator 29 generates the IPC per unit time or the number of execution cycles of unit processing of the application execution program, the execution state of the CPU before integration can be reproduced as in FIG.

  The configuration without the execution status monitoring device 14 as in the multi-thread execution device 100 of FIGS. 15 and 16 makes it easy to suppress an increase in cost although the simulator 29 is required.

DESCRIPTION OF SYMBOLS 11 Thread schedule apparatus 12 Profiler 13 Pipeline control circuit 14 Execution condition monitoring apparatus 15 Arithmetic circuit 16 Register file 17 Instruction buffer 18 Instruction decoder 19, 21 Changeover switch 50 Processor 60 Application execution profile memory | storage part 100 Multithread execution apparatus

Claims (10)

Program storage means for storing an object program generated from a source program;
An instruction issuing means for issuing an instruction of the object program;
An instruction execution means for executing the instruction, and a multi-thread execution device comprising:
The object program includes
An adjustment code is inserted for adjusting the execution completion speed information of the instruction to substantially match the target execution speed information of the program read from the target execution speed information storage means.
A multi-thread execution device. The instruction execution means that has executed the adjustment code includes:
Requesting the instruction issuing means to adjust the frequency of issuing instructions of the object program in accordance with the adjustment code;
The multi-thread execution device according to claim 1. The adjustment code is inserted by a compiler that compiles the source program.
The multi-thread execution device according to claim 1 or 2, The execution speed monitoring means for monitoring the execution completion speed of the instruction;
The execution completion speed information is generated from an execution situation when the object program is actually executed, which is monitored by the execution speed monitoring means.
The multi-thread execution device according to claim 1, wherein the multi-thread execution device is provided. The execution completion speed information is generated by a simulator that simulates the execution status of the object program.
The multi-thread execution device according to claim 1, wherein the multi-thread execution device is provided. It has a multi-thread execution environment that executes multiple object programs in a time-sharing manner.
The command issuing means adjusts the command issue rate of the plurality of object programs by switching threads.
6. The multi-thread execution device according to claim 1, wherein The instruction issuing means selects the object program for adjusting the issue frequency according to the priority order of a plurality of object programs.
The multi-thread execution device according to claim 1, wherein The target execution completion number information is a target execution completion number per unit time of an instruction or a target execution cycle number per unit processing of a program.
8. The multi-thread execution device according to claim 1, wherein An object program generation method executed by an information processing apparatus including: an instruction issue unit that issues an instruction of an object program generated from a source program; and an instruction execution unit that executes the instruction,
An execution speed monitoring unit or a simulator generating execution completion speed information for each source program;
The compiler reading the source program from the program storage means;
A step of the compiler reading target execution speed information for each source program from the target execution speed information storage means;
A step of reading execution completion speed information for each source program from the execution completion speed information storage means;
A compiler converts the source program into an object program, and adjusts the execution completion speed information so as to substantially match the target execution speed information, and inserts adjustment code into the object program;
A method for generating an object program, comprising: On the computer,
Reading the source program from the program storage means;
Reading target execution speed information for each source program from the target execution speed information storage means;
Reading execution completion speed information for each source program from the execution completion speed information storage means;
Converting the source program into an object program and adjusting the execution completion speed information so as to substantially match the target execution speed information; and inserting adjustment code into the object program;
A program characterized by having executed.