Real-time operating system-oriented task state increment recovery method and system

Abstract

The invention relates to a task state increment recovery method for a real-time operating system, which is characterized in that a hierarchical progressive optimization strategy is adopted, and register recovery management is decomposed into a delay recovery layer and a hardware acceleration layer; the delay recovery layer only recovers the hot register during task switching by distinguishing the hot register and the cold register, and the cold register is recovered as required through an exception mechanism when being delayed to actual access; and the hardware acceleration layer is used for realizing hardware-level switching of a register block by utilizing a shadow register of a processor or a fast mode switching mechanism aiming at a specific task pair of high-frequency switching, and eliminating the expenditure of software recovery.

Description

Technical Field

[0001] This invention relates to the field of embedded operating system technology, and in particular to a method and system for incremental recovery of task state for real-time operating systems. Background Technology

[0002] In real-time operating systems, task context switching comprises two phases: saving the current task state and restoring the target task state. The restoration phase involves reading the target task's processor state from a pre-saved register archive and loading it into the processor registers, enabling the target task to resume execution from the point of last interruption. The latency of the restoration phase directly impacts the target task's response speed and is a significant component of the total context switching latency.

[0003] Traditional recovery strategies employ a full recovery approach, loading all saved register values ​​into the processor registers during task switching. Taking the ARM Cortex-M4 processor as an example, which contains 16 32-bit general-purpose registers and 32 32-bit floating-point registers, a full recovery requires loading 48 registers, taking approximately 4 microseconds at a 168 MHz clock speed. However, the target task does not immediately use all registers after recovery; some registers may not be accessed for a long time, or even remain unused for the entire time slice. This indiscriminate full recovery strategy results in significant performance waste.

[0004] To gain a deeper understanding of the optimization space during the recovery phase, a timing model of task register accesses needs to be established. Let p be the probability of accessing a register within a time window Δt after task recovery. For most tasks, the set of registers accessed immediately after recovery (called hot registers) is fixed, including registers necessary for control flow such as the program counter, stack pointer, and link registers, as well as function parameter registers. The access probability p of other registers (called cold registers) is typically less than 0.1.

[0005] If the recovery operation can be divided into two phases, with the first phase recovering only hot registers and the second phase recovering cold registers as needed when they are actually accessed, the recovery latency can be significantly reduced. Let the number of hot registers be N. hot The number of cold registers is N cold The overhead of exception handling for on-demand recovery is T. exception The average latency of the delayed recovery strategy is: T lazy =T hot + p × N cold × T exception Because N hot Much smaller than N hot + N cold Furthermore, p is typically less than 0.1, and the delayed recovery strategy can significantly reduce the average recovery latency.

[0006] Several optimization schemes exist for the recovery phase, but they all have significant drawbacks. The Linux operating system employs a delayed recovery mechanism for the floating-point unit. Its core idea is to temporarily disable the floating-point unit during task switching, rather than restoring it initially. Recovery only occurs when an exception is triggered by the target task's first execution of a floating-point instruction. While effective, this method is limited to the specific hardware module of the floating-point unit and is ineffective for addressing redundant recovery issues with general-purpose registers.

[0007] The QNX microkernel operating system employs a fast context switching technique based on processor mode switching. It leverages the independent register sets of different processor modes in the ARM architecture to achieve hardware-level switching of register sets through mode switching. While this method offers fast switching speeds, it is limited by the hardware architecture's support. ARM's FIQ mode only provides seven shadow registers, making it unreliable for tasks with high register usage. Furthermore, this method lacks hardware support on emerging architectures like RISC-V, resulting in insufficient versatility.

[0008] Power system protection and control terminals exhibit typical real-time multitasking characteristics. These tasks exhibit distinct switching patterns: some task pairs (such as data acquisition and protection tasks) have extremely high switching frequencies due to strong functional coupling, while other task pairs switch at lower frequencies. For a typical power terminal configuration, the number of task switches per second can reach 18,000, with high-frequency task pairs potentially accounting for over 80% of the total switches. If special hardware acceleration mechanisms can be employed for high-frequency task pairs to achieve zero-overhead or near-zero-overhead switching, the system's real-time performance and throughput will be significantly improved. Summary of the Invention

[0009] To address the aforementioned problems, the present invention aims to provide a method and system for incremental task state recovery for real-time operating systems.

[0010] To achieve the above objectives, the present invention adopts the following technical solution: An incremental task state recovery method for real-time operating systems employs a layered and progressive optimization strategy, decomposing register recovery management into two layers: a delayed recovery layer and a hardware acceleration layer. The delayed recovery layer distinguishes between hot and cold registers, recovering only hot registers during task switching, while cold registers are recovered on demand through an exception mechanism when they are actually accessed. The hardware acceleration layer, for specific task pairs with high-frequency switching, utilizes the processor's shadow registers or fast mode switching mechanism to achieve hardware-level switching of register groups, eliminating the overhead of software recovery.

[0011] Furthermore, the hot registers specifically include: control flow essential registers: the program counter, stack pointer, and link registers are registers that are used immediately after task resumption and must be included in the hot register set; function call convention registers: according to the application binary interface specification, function parameters are passed through registers; startup code used registers: analyze the startup code after task resumption, identify the registers used by these instructions, and add them to the hot register set.

[0012] Furthermore, the delayed recovery of floating-point registers is achieved by disabling the floating-point arithmetic unit. The specific implementation steps are as follows: Step 1: Disable the floating-point unit during task switching. During the recovery phase of task switching, only the general-purpose registers in the hot register set are restored, and the floating-point registers are not restored. At the same time, the floating-point coprocessor control register is configured to disable the access permissions of the floating-point unit. Step 2: Register exception handling functions. This registers dedicated handling functions for exceptions caused by the disabling of floating-point units. On the ARM architecture, this is a Usage Fault exception; on the RISC-V architecture, this is an Illegal Instruction exception. Step 3: Restore floating-point registers as needed. When a task executes a floating-point instruction, the processor triggers an exception and enters the exception handling function because the floating-point unit is disabled. The exception handling function reads the values ​​of all floating-point registers from the register storage area of ​​the current task control block, restores them to the floating-point register file using a batch load instruction, and finally enables access permissions to the floating-point unit, clears the exception flag, and returns. The processor then re-executes the floating-point instruction that triggered the exception. Step 4: Update the recovery status flag. Maintain a floating-point register recovery flag in the task control block. After the exception handling function recovers the floating-point register, set the flag to 1. In subsequent task switching, if the flag is 1, the floating-point register needs to be saved; if it is 0, it means that the floating-point register has not been used and does not need to be saved.

[0013] Furthermore, the delayed recovery employs the following correctness guarantee mechanism, as detailed below: Mechanism 1: Accurate identification of exception types. Exception handling functions must accurately distinguish between exceptions caused by unrecovered floating-point registers and other types of exceptions. For ARM architecture, read the NOCP bit of the Usage Fault Status Register; for RISC-V architecture, read the machine trap cause register mcause. Mechanism 2: Atomicity guarantee. The recovery operation of floating-point registers must be atomic and cannot be interrupted by other interrupts or exceptions. In the exception handling function, all interrupts are first disabled, then the register recovery operation is performed, and finally the interrupts are re-enabled. Mechanism 3: Nested exception handling. An exception nesting level counter is added to the task control block. It is incremented when entering the exception handling function and decremented when exiting. When the counter is greater than 1, the register recovery operation is not performed to avoid repeated recovery or state chaos. Mechanism 4: Recovery failure handling. Before accessing the save area, the exception handling function checks the validity of the address and the memory protection attributes. If an exception is detected, an error log is recorded and the system protection mechanism is triggered.

[0014] Furthermore, the specific task pairs undergoing high-frequency switching are identified through statistical task switching frequency, and hardware shadow register resources are allocated to them, as follows: Step 1: Frequency matrix initialization, maintaining a two-dimensional array F in the operating system kernel. [N][N] , where N is the total number of tasks in the system. Array element F [i][j] This represents the cumulative number of times the user switches from task i to task j. Step 2: Switch event logs. In the task switching function, each time you switch from task i to task j, set F... [i][j] Increment by 1, using atomic increment instructions to ensure the atomicity of the operation; Step 3: Periodic analysis. Set up a low-priority background task to perform frequency matrix analysis every 1 second, find the top K task pairs with the highest frequency values, and record these task pairs in the high-frequency task pair list. Step 4: Dynamically adjust the threshold, set a frequency threshold F. th Only when the switching frequency of a certain task pair is greater than F th Only when a certain condition is met will it be considered for inclusion in the high-frequency list. The threshold is dynamically adjusted based on system load.

[0015] Furthermore, for the ARM architecture, zero-overhead switching of high-frequency task pairs can be achieved using shadow registers in FIQ mode: Step 1: Task mode configuration. When creating a task, specify the processor mode attribute for the task. For critical tasks in high-frequency task pairs, set their mode attribute to FIQ mode; for ordinary tasks, set them to user mode or system mode. Step 2: Register usage restrictions. In order to make full use of the 7 shadow registers in FIQ mode, register usage for FIQ mode tasks is restricted. During the compilation phase, a special register allocation strategy is specified for this task, giving priority to the use of r8 to r14. Step 3: Mode switching implementation. In the task switching function, check the mode attributes of the source and target tasks. If their modes are different, use the CPS instruction to directly modify the mode bit of the current program status register (CPSR). After mode switching, the processor hardware automatically maps r8 to r14 to the shadow register of FIQ mode, without software intervention. Step 4: Residual Register Processing. For registers outside the shadow register range, saving and restoring are still required. Calculate the set of residual registers and perform save and restore operations only on the registers within it; Step 5: Permissions and security management. Since FIQ mode is a privileged mode, the memory access range of FIQ mode tasks is restricted through the memory protection unit, allowing access only to their own code segment, data segment, and stack area.

[0016] Furthermore, for the RISC-V architecture, the shadow register function is implemented through chip-level custom extensions, as follows: Step 1: Hardware implementation of multiple register files. In the register file module of the RISC-V processor core, the storage capacity is expanded to accommodate multiple register files; each file contains 32 general-purpose registers and 32 floating-point registers; 4 register files are implemented, for a total of 256 registers; Step 2: Register group selection logic. Add a register group selection signal with a width of 2 bits and a value range of 0-3, representing the currently active register group number; the register access logic calculates the physical register number based on the group selection signal and the logical register number; Step 3: Define a custom CSR. Define a custom control status register with address 0x800; the lower 2 bits of this register store the current register group number. Step 4: Register bank switching during task switching. In the task switching function, if the source task and the target task use different register banks, the CSRRW instruction is executed to switch the register banks. The switching operation has a delay of 1 clock cycle, achieving zero-overhead switching. Step 5: Register group resource management. The operating system kernel maintains a register group allocation table, recording which task each group is currently assigned to. When a new high-frequency task pair is identified, if there is a free group, it is directly allocated; if there is no free group, the lowest frequency task pair is eliminated based on usage frequency. Step 6: Evaluation of chip implementation area and power consumption. Adding 3 sets of register files requires an additional 12 kilobytes of register memory.

[0017] A task state incremental recovery system for a real-time operating system includes a processor, a memory, and a computer program stored in the memory. When the processor executes the computer program, it specifically performs the steps in the task state incremental recovery method for a real-time operating system as described above.

[0018] The present invention has the following beneficial effects: 1. This invention fundamentally solves the performance waste problem caused by the indiscriminate restoration of all registers in traditional real-time operating systems through the organic synergy of delayed recovery strategies and hardware acceleration mechanisms. At the delayed recovery level, by restoring only hot registers (7 registers) instead of all registers (48 registers), the recovery latency is reduced from 4 microseconds in the traditional method to approximately 1.2 microseconds, an optimization of 70%. For tasks that do not use floating-point operations, floating-point registers do not need to be restored at all, further saving latency. At the hardware acceleration level, for high-frequency switching task pairs, zero-overhead or near-zero-overhead switching is achieved by utilizing ARM's FIQ mode shadow registers or RISC-V's custom multi-set register files. Switching latency is reduced from the microsecond level to the nanosecond level, resulting in a significant improvement in system performance for high-frequency task pairs that account for 80% of switching operations. 2. The method of this invention achieves consistent optimization results on different processor architectures such as ARM and RISC-V through abstract data structures and a unified algorithm framework, and has good cross-platform versatility. This method can be used in conjunction with task state snapshot technology to optimize both the saving and restoring stages simultaneously, thereby maximizing performance improvement. Attached Figure Description

[0019] Figure 1 This is a schematic diagram illustrating the data structure extension of the task control block in one embodiment of the present invention; Figure 2 This is a flowchart of the delayed recovery exception handling in one embodiment of the present invention; Figure 3 This is a schematic diagram of the on-demand recovery mechanism for floating-point registers in one embodiment of the present invention; Figure 4 This is a schematic diagram of the shadow register switching mechanism in ARM architecture FIQ mode according to an embodiment of the present invention; Figure 5 This is a bar chart comparing the recovery latency optimization effects in one embodiment of the present invention; Figure 6 This is a schematic diagram of hardware expansion of multiple register files in a RISC-V architecture according to an embodiment of the present invention. Figure 7 This is a timing diagram of task switching in a typical power terminal application scenario according to an embodiment of the present invention. Detailed Implementation

[0020] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments: refer to Figure 1In this embodiment, a task state incremental recovery method for real-time operating systems is provided. It employs a layered, progressive optimization strategy, decomposing register recovery management into two layers: a delayed recovery layer and a hardware acceleration layer. The delayed recovery layer distinguishes between hot and cold registers, recovering only hot registers during task switching, while cold registers are recovered on demand through an exception mechanism when actually accessed. This optimization is applicable to all tasks and can significantly reduce average recovery latency. The hardware acceleration layer, for specific task pairs with high-frequency switching, utilizes the processor's shadow registers or fast mode switching mechanism to achieve hardware-level switching of register groups, eliminating the overhead of software recovery.

[0021] In this embodiment, the hot registers specifically include: Control flow essential registers: The program counter, stack pointer, and link register are registers used immediately after task resumption and must be included in the hot register set; for the ARM architecture, these registers are r13 (stack pointer), r14 (link register), and r15 (program counter); Function call convention registers: According to the application binary interface specification, function parameters are passed through registers; these registers may be accessed in the entry code after task resumption and should be included in the hot register set; for the ARM architecture, this includes four parameter registers from r0 to r3. Startup code used registers: Analyze the startup code after task resumption (usually the first 10 instructions of the task entry function), identify the registers used by these instructions, and add them to the hot register set. Based on the above principles, for the ARM architecture, the hot register set is defined as {r0, r1, r2, r3, r13, r14, r15}, a total of 7 registers. For the RISC-V architecture, the hot register set is {x0, x1, x2, x10, x11, x12, x13}, a total of 7 registers.

[0022] In this embodiment, the delayed recovery of the floating-point register is achieved by disabling the floating-point arithmetic unit. The specific implementation steps are as follows: Step 1: Disable the floating-point unit during task switching. During the task switching recovery phase, only general-purpose registers in the hot register set are restored, not floating-point registers. Simultaneously, configure the floating-point coprocessor control register to disable access permissions for the floating-point unit. For ARM Cortex-M4, clear bits CP10 and CP11 of the coprocessor access control register CPACR. For RISC-V processors, set the FS field of the machine status register mstatus to the Off state. Step 2: Register exception handling functions. This registers dedicated handling functions for exceptions caused by the disabling of floating-point units. On the ARM architecture, this is a Usage Fault exception; on the RISC-V architecture, this is an Illegal Instruction exception. Step 3: Restore floating-point registers as needed. When a task executes a floating-point instruction, the processor triggers an exception and enters the exception handling function because the floating-point unit is disabled. The exception handling function reads the values ​​of all floating-point registers from the register storage area of ​​the current task control block, restores them to the floating-point register file using a batch load instruction, and finally enables access permissions to the floating-point unit, clears the exception flag, and returns. The processor then re-executes the floating-point instruction that triggered the exception. Step 4: Update the recovery status flag. Maintain a floating-point register recovery flag in the task control block. After the exception handling function recovers the floating-point register, set the flag to 1. In subsequent task switching, if the flag is 1, the floating-point register needs to be saved; if it is 0, it means that the floating-point register has not been used and does not need to be saved.

[0023] In this embodiment, the delayed recovery employs the following correctness guarantee mechanism, as detailed below: Mechanism 1: Accurate identification of exception types. Exception handling functions must accurately distinguish between exceptions caused by unrecovered floating-point registers and other types of exceptions. For ARM architecture, read the NOCP bit of the Usage Fault Status Register; for RISC-V architecture, read the machine trap cause register mcause. Mechanism 2: Atomicity guarantee. The recovery operation of floating-point registers must be atomic and cannot be interrupted by other interrupts or exceptions. In the exception handling function, all interrupts are first disabled, then the register recovery operation is performed, and finally the interrupts are re-enabled. Mechanism 3: Nested exception handling. An exception nesting level counter is added to the task control block. It is incremented when entering the exception handling function and decremented when exiting. When the counter is greater than 1, the register recovery operation is not performed to avoid repeated recovery or state chaos. Mechanism 4: Recovery failure handling. Before accessing the save area, the exception handling function checks the validity of the address and the memory protection attributes. If an exception is detected, an error log is recorded and the system protection mechanism is triggered.

[0024] In this embodiment, the specific task pair with high-frequency switching is identified by statistical task switching frequency, and hardware shadow register resources are allocated to it, as follows: Step 1: Frequency matrix initialization, maintaining a two-dimensional array F in the operating system kernel. [N][N] , where N is the total number of tasks in the system. Array element F [i][j] This represents the cumulative number of times the user switches from task i to task j. Step 2: Switch event logs. In the task switching function, each time you switch from task i to task j, set F... [i][j] Increment by 1, using atomic increment instructions to ensure the atomicity of the operation; Step 3: Periodic analysis. Set up a low-priority background task to perform frequency matrix analysis every 1 second, find the top K task pairs with the highest frequency values, and record these task pairs in the high-frequency task pair list. Step 4: Dynamically adjust the threshold, set a frequency threshold F. th Only when the switching frequency of a certain task pair is greater than F th Only when a certain condition is met will it be considered for inclusion in the high-frequency list. The threshold is dynamically adjusted based on system load.

[0025] In this embodiment, for the ARM architecture, zero-overhead switching of high-frequency task pairs is achieved using shadow registers in FIQ mode: Step 1: Task mode configuration. When creating a task, specify the processor mode attribute for the task. For critical tasks in high-frequency task pairs, set their mode attribute to FIQ mode; for ordinary tasks, set them to user mode or system mode. Step 2: Register usage restrictions. In order to make full use of the 7 shadow registers (r8 to r14) in FIQ mode, register usage is restricted for FIQ mode tasks. During the compilation phase, a special register allocation strategy is specified for this task, giving priority to the use of r8 to r14. Step 3: Mode switching implementation. In the task switching function, check the mode attributes of the source and target tasks. If their modes are different, use the CPS instruction to directly modify the mode bit of the current program status register (CPSR). After mode switching, the processor hardware automatically maps r8 to r14 to the shadow register of FIQ mode, without software intervention. Step 4: Residual Register Processing. For registers outside the shadow register range (r0 to r7), saving and restoring are still required. Calculate the set of residual registers and perform save and restore operations only on the registers within it; Step 5: Permissions and security management. Since FIQ mode is a privileged mode, the memory access scope of FIQ mode tasks is restricted through the Memory Protection Unit (MPU), allowing access only to their own code segment, data segment, and stack area.

[0026] In this embodiment, for the RISC-V architecture, since the standard instruction set does not provide a shadow register mechanism, the shadow register function is implemented through a chip-level custom extension, as follows: Step 1: Hardware implementation of multiple register files. In the register file module of the RISC-V processor core, the storage capacity is expanded to accommodate multiple register files; each file contains 32 general-purpose registers and 32 floating-point registers; 4 register files are implemented, for a total of 256 registers; Step 2: Register group selection logic. Add a register group selection signal with a width of 2 bits and a value range of 0-3, representing the currently active register group number; the register access logic calculates the physical register number based on the group selection signal and the logical register number; Step 3: Define a custom CSR. Define a custom control status register with the address 0x800 (user-defined CSR space). The lower 2 bits of this register store the current register group number. Step 4: Register bank switching during task switching. In the task switching function, if the source task and the target task use different register banks, the CSRRW instruction is executed to switch the register banks. The switching operation has a delay of 1 clock cycle, achieving zero-overhead switching. Step 5: Register group resource management. The operating system kernel maintains a register group allocation table, recording which task each group is currently assigned to. When a new high-frequency task pair is identified, if there is a free group, it is directly allocated; if there is no free group, the lowest frequency task pair is eliminated based on usage frequency. Step 6: Chip implementation area and power consumption assessment. Adding 3 sets of register files requires an additional 12 kilobytes of register memory. Based on the 28nm process parameters, this occupies approximately 0.5 square millimeters of chip area. Dynamic power consumption is approximately 10 picojoules per switch. For a system with 18,000 switches per second, the total power consumption is approximately 0.18 milliwatts, which is negligible.

[0027] A task state incremental recovery system for a real-time operating system includes a processor, a memory, and a computer program stored in the memory. When the processor executes the computer program, it specifically performs the steps in the task state incremental recovery method for a real-time operating system as described above.

[0028] Example 1: Implementation plan for a power protection terminal based on an ARM Cortex-M4 processor This embodiment implements the method of the present invention on an STM32F407 microcontroller based on an ARM Cortex-M4 core.

[0029] Step 1: Task Control Block Expansion and Hot Register Set Configuration like Figure 1 As shown, fields related to this invention are added to the task control block structure. These include a recovered register bitmap (6 bytes), processor mode attribute (1 byte), register set number (1 byte), floating-point register recovered flag (1 byte), and exception nesting level counter (1 byte).

[0030] The hot register set is configured as {r0, r1, r2, r3, r13, r14, r15}, a total of 7 registers. These registers must be restored immediately upon task resumption to ensure correct program execution.

[0031] Step 2: Implementing Delay Recovery During Task Switching like Figure 2 As shown, only the hot register set is restored during the recovery phase. The values ​​of these seven registers are loaded from the target task's register store and restored to the processor registers using the LDMIA bulk load instruction. The target task's recovered bitmap is updated to mark these seven registers as recovered.

[0032] Configure the floating-point coprocessor control register, clearing CP10 and CP11 bits to disable floating-point unit access. This will trigger a usage error exception when the task subsequently executes floating-point instructions.

[0033] Step 3: On-demand recovery of floating-point registers like Figure 3 As shown, on-demand restoration of floating-point registers is implemented within the error exception handling function. When a task executes a floating-point instruction, the processor triggers a usage error exception because the floating-point unit is disabled.

[0034] The exception handling function first reads the usage error status register and checks if the coprocessor disable bit is set. If it is confirmed to be a floating-point access exception, it loads the register save pointer from the current task control block and uses the VLDMIA (Volume Load Array) instruction to restore all 32 single-precision floating-point registers at once.

[0035] After recovery, configure the coprocessor access control register to enable floating-point unit access. Update the floating-point register recovery flag in the task control block to true. Clear the usage error status register, clear the exception flag, and return.

[0036] Step 4: Optimization of shadow registers for high-frequency task pairs like Figure 4 As shown, for the task pairs with the highest switching frequency, zero-overhead switching is achieved using FIQ mode shadow registers. The task switching frequency matrix is ​​maintained in the operating system scheduler, and the corresponding elements are updated each time a switch occurs.

[0037] For identified high-frequency task pairs, the processor mode attribute of the critical task is set to FIQ mode. FIQ mode has seven independent shadow registers r8 to r14, which are physically independent of their counterparts in user mode.

[0038] In the task switching function, the mode attributes of the source and target tasks are checked. If their modes differ, the CPS instruction is used to directly modify the mode bit in the current program status register. After the mode switch, the processor hardware automatically maps r8 to r14 to the shadow register of the FIQ mode, eliminating the need for software saving and restoration. The switching latency is only a few clock cycles.

[0039] Step 5: System Performance Testing and Verification Use a cycle counter to measure task recovery latency. For example... Figure 5 As shown, for data acquisition task recovery, the traditional method has a latency of 4.0 microseconds (recovering all 48 registers). After applying latency recovery optimization, the latency is reduced to 1.2 microseconds (recovering only 7 hot registers). For high-frequency tasks, after applying FIQ mode shadow register optimization, the latency is reduced to 0.1 microseconds, representing an optimization of 97.5% compared to the traditional method.

[0040] Example 2: Implementation plan for an industrial control system based on a RISC-V processor This embodiment implements the method of the present invention on the Pingtouge XuanTie C910 processor based on the RISC-V RV64GC instruction set.

[0041] Configure the hot register set as {x0, x1, x2, x10, x11, x12, x13}, a total of 7 registers. During the task switch recovery phase, only these 7 hot registers are restored. Set the FS field of the machine status register mstatus to the Off state to disable the floating-point unit.

[0042] Implement on-demand recovery of floating-point registers within the illegal instruction exception handling function. Read the instruction content pointed to by the machine exception program counter, analyze the instruction code to determine if it is a floating-point instruction. If it is confirmed to be a floating-point access exception, load all floating-point registers from the register storage area in batches, set the FS field to the Dirty state, update the recovery flag, and return.

[0043] Implement a custom extension in the hardware design of a RISC-V processor to support multiple register files. Extend the register file module to implement four register files. Define a custom register set number (CSR) to store the current register set number. During task switching, use the CSRRW instruction to switch register sets, achieving zero-overhead switching.

[0044] Comparing the test data of the ARM and RISC-V platforms, the optimization results are highly consistent, verifying the cross-platform universality of the method of this invention.

[0045] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0046] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the 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 program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0047] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0048] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0049] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for incremental task state recovery for a real-time operating system, characterized in that, A layered optimization strategy is adopted, decomposing register recovery management into two layers: a delayed recovery layer and a hardware acceleration layer. The delayed recovery layer distinguishes between hot and cold registers, and only recovers hot registers during task switching, while cold registers are recovered as needed through an exception mechanism when they are actually accessed. The hardware acceleration layer, for specific task pairs with high-frequency switching, utilizes the processor's shadow register or fast mode switching mechanism to achieve hardware-level switching of register groups, eliminating the overhead of software recovery.

2. The method for incremental task state recovery for a real-time operating system according to claim 1, characterized in that, The hot registers specifically include: control flow essential registers: the program counter, stack pointer, and link registers are registers that are used immediately after task recovery and must be included in the hot register set; function calling convention registers: according to the application binary interface specification, function parameters are passed through registers; startup code used registers: analyze the startup code after task recovery, identify the registers used by these instructions, and add them to the hot register set.

3. The method for incremental task state recovery for a real-time operating system according to claim 2, characterized in that, Delayed recovery of floating-point registers is achieved by disabling the floating-point arithmetic unit. The specific implementation steps are as follows: Step 1: Disable the floating-point unit during task switching. During the recovery phase of task switching, only the general-purpose registers in the hot register set are restored, and the floating-point registers are not restored. At the same time, the floating-point coprocessor control register is configured to disable the access permissions of the floating-point unit. Step 2: Register exception handling functions. This registers dedicated handling functions for exceptions caused by the disabling of floating-point units. On the ARM architecture, this is a Usage Fault exception; on the RISC-V architecture, this is an Illegal Instruction exception. Step 3: Restore floating-point registers as needed. When a task executes a floating-point instruction, the processor triggers an exception and enters the exception handling function because the floating-point unit is disabled. The exception handling function reads the values ​​of all floating-point registers from the register storage area of ​​the current task control block, restores them to the floating-point register file using a batch load instruction, and finally enables access permissions to the floating-point unit, clears the exception flag, and returns. The processor then re-executes the floating-point instruction that triggered the exception. Step 4: Update the recovery status flag. Maintain a floating-point register recovery flag in the task control block. After the exception handling function recovers the floating-point register, set the flag to 1. In subsequent task switching, if the flag is 1, the floating-point register needs to be saved; if it is 0, it means that the floating-point register has not been used and does not need to be saved.

4. The method for incremental task state recovery for a real-time operating system according to claim 2, characterized in that, The delayed recovery employs the following correctness guarantee mechanism, as detailed below: Mechanism 1: Accurate identification of exception types. Exception handling functions must accurately distinguish between exceptions caused by unrecovered floating-point registers and other types of exceptions. For ARM architecture, read the NOCP bit of the Usage Fault Status Register; for RISC-V architecture, read the machine trap cause register mcause. Mechanism 2: Atomicity guarantee. The recovery operation of floating-point registers must be atomic and cannot be interrupted by other interrupts or exceptions. In the exception handling function, all interrupts are first disabled, then the register recovery operation is performed, and finally the interrupts are re-enabled. Mechanism 3: Nested exception handling. An exception nesting level counter is added to the task control block. It is incremented when entering the exception handling function and decremented when exiting. When the counter is greater than 1, the register recovery operation is not performed to avoid repeated recovery or state chaos. Mechanism 4: Recovery failure handling. Before accessing the save area, the exception handling function checks the validity of the address and the memory protection attributes. If an exception is detected, an error log is recorded and the system protection mechanism is triggered.

5. The method for incremental task state recovery for a real-time operating system according to claim 1, characterized in that, The specific task pairs that switch at high frequencies are identified by statistical task switching frequency, and hardware shadow register resources are allocated to them, as follows: Step 1: Frequency matrix initialization, maintaining a two-dimensional array F in the operating system kernel. [N][N] , where N is the total number of tasks in the system. Array element F [i][j] This represents the cumulative number of times the user switches from task i to task j. Step 2: Switch event logs. In the task switching function, each time you switch from task i to task j, set F... [i][j] Increment by 1, using atomic increment instructions to ensure the atomicity of the operation; Step 3: Periodic analysis. Set up a low-priority background task to perform frequency matrix analysis every 1 second, find the top K task pairs with the highest frequency values, and record these task pairs in the high-frequency task pair list. Step 4: Dynamically adjust the threshold, set a frequency threshold F. th Only when the switching frequency of a certain task pair is greater than F th Only when a certain condition is met will it be considered for inclusion in the high-frequency list. The threshold is dynamically adjusted based on system load.

6. The method for incremental task state recovery for a real-time operating system according to claim 5, characterized in that, For the ARM architecture, zero-overhead switching of high-frequency task pairs can be achieved using shadow registers in FIQ mode: Step 1: Task mode configuration. When creating a task, specify the processor mode attribute for the task. For critical tasks in high-frequency task pairs, set their mode attribute to FIQ mode; for ordinary tasks, set them to user mode or system mode. Step 2: Register usage restrictions. In order to make full use of the 7 shadow registers in FIQ mode, register usage for FIQ mode tasks is restricted. During the compilation phase, a special register allocation strategy is specified for this task, giving priority to the use of r8 to r14. Step 3: Mode switching implementation. In the task switching function, check the mode attributes of the source and target tasks. If their modes are different, use the CPS instruction to directly modify the mode bit of the current program status register (CPSR). After mode switching, the processor hardware automatically maps r8 to r14 to the shadow register of FIQ mode, without software intervention. Step 4: Residual register processing. For registers that are outside the range of the shadow registers, they still need to be saved and restored. Calculate the set of residual registers and perform save and restore operations only on the registers in it. Step 5: Permissions and security management. Since FIQ mode is a privileged mode, the memory access range of FIQ mode tasks is restricted through the memory protection unit, allowing access only to their own code segment, data segment, and stack area.

7. The method for incremental task state recovery for a real-time operating system according to claim 5, characterized in that, For the RISC-V architecture, the shadow register function is implemented through chip-level custom extensions, as follows: Step 1: Hardware implementation of multiple register files. In the register file module of the RISC-V processor core, the storage capacity is expanded to accommodate multiple register files; each file contains 32 general-purpose registers and 32 floating-point registers; 4 register files are implemented, for a total of 256 registers; Step 2: Register group selection logic. Add a register group selection signal with a width of 2 bits and a value range of 0-3, representing the currently active register group number; the register access logic calculates the physical register number based on the group selection signal and the logical register number; Step 3: Define a custom CSR. Define a custom control status register with address 0x800; the lower 2 bits of this register store the current register group number. Step 4: Register bank switching during task switching. In the task switching function, if the source task and the target task use different register banks, the CSRRW instruction is executed to switch the register banks. The switching operation has a delay of 1 clock cycle, achieving zero-overhead switching. Step 5: Register group resource management. The operating system kernel maintains a register group allocation table, recording which task each group is currently assigned to. When a new high-frequency task pair is identified, if there is a free group, it is directly allocated; if there is no free group, the lowest frequency task pair is eliminated based on usage frequency. Step 6: Evaluation of chip implementation area and power consumption. Adding 3 sets of register files requires an additional 12 kilobytes of register memory.

8. A task state incremental recovery system for a real-time operating system, characterized in that, It includes a processor, a memory, and a computer program stored in the memory. When the processor executes the computer program, it specifically performs the steps in the task state incremental recovery method for a real-time operating system as described in any one of claims 1-7.

Images