Task state snapshot method for real-time operating system

Abstract

The invention relates to the technical field of embedded operating systems, in particular to a task state snapshot method for a real-time operating system. The method comprises the following steps of S1, performing static analysis during compiling, and providing prior information for optimization during running; s2, dirty bit tracking is carried out during operation, and register dynamic modification information is recorded according to performance overhead; and S3, incremental storage is carried out during task switching, and on-demand storage of task contexts is realized. According to the task state snapshot method oriented to the real-time operating system, by establishing an accurate mathematical model used by a task register and combining static analysis during compiling and dynamic tracking during running, incremental storage of task contexts is achieved, the number of register storage operations during task switching is remarkably reduced, and the task switching efficiency is improved. And the requirements of high-real-time scenes such as a power system and the like are met.

Description

Technical Field

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

[0002] In real-time operating systems, task context switching refers to the process by which the central processing unit (CPU) switches from executing the current task to executing another task. This process essentially involves a complete migration of the processor's execution state, including the saving and restoration of hardware states such as the program counter, general-purpose registers, floating-point registers, status registers, and memory management unit configuration. Context switching latency, as a core metric for measuring the performance of a real-time operating system, directly determines the system's response speed to external events and the flexibility of task scheduling.

[0003] Real-time requirements are particularly stringent in the protection and control terminals of power systems. Taking the line protection device of a 220 kV substation as an example, the instantaneous overcurrent protection requires the total time from fault occurrence to protection action to not exceed 10 milliseconds, which includes multiple stages such as analog-to-digital conversion, digital filtering, algorithm calculation, and circuit breaker operation. If the task switching delay of the operating system is too large, it will directly encroach on the calculation time of the protection algorithm, which may lead to protection failure or malfunction, endangering the safe and stable operation of the power system. According to the technical specifications issued by the State Grid Corporation of China, the processor task switching delay of the protection device should be controlled within 5 microseconds to ensure that the entire protection process is completed within the time limit requirement.

[0004] Traditional real-time operating systems employ a conservative strategy during task switching: indiscriminately saving and restoring all processor registers. This strategy is based on a worst-case assumption that each task might use all registers, thus requiring complete saving during switching. However, real-world tasks often have well-defined functional boundaries and resource usage patterns. For example, simple data acquisition tasks primarily perform analog-to-digital conversion result reading and buffer writing operations, typically requiring only a few general-purpose registers for address calculations and data transfer, without involving floating-point operations. In contrast, complex protection algorithm tasks require Fourier transforms or phasor calculations, heavily utilizing floating-point registers. Treating these two types of tasks with the same strategy inevitably leads to significant performance waste.

[0005] Several targeted optimization solutions exist, but all have significant drawbacks. The Linux operating system employs a delayed saving mechanism for the floating-point unit. Its core idea is to temporarily refrain from saving floating-point registers during task switching, instead saving them only when an exception is triggered during the first execution of a floating-point instruction by the target task. While this method avoids unnecessary saving of floating-point registers, it is limited to the specific hardware module of the floating-point unit and is ineffective in addressing the problem of redundant saving of general-purpose registers. The QNX microkernel operating system uses a fast context switching technology based on processor mode switching, but it is limited by the hardware architecture's support, lacking hardware support on emerging architectures such as RISC-V, resulting in insufficient versatility.

[0006] Therefore, the fundamental problem with existing technologies lies in the lack of in-depth understanding and utilization of task behavior characteristics. The usage pattern of task registers is determined at compile time and can be accurately identified through control flow analysis and data flow analysis; the modification state of task registers changes dynamically at runtime and can be tracked in real time through hardware monitoring mechanisms. If we can organically combine static information at compile time and dynamic information at runtime to establish a precise snapshot model of task state, we can achieve true on-demand saving and fundamentally eliminate redundant operations. Summary of the Invention

[0007] To address the aforementioned issues, the present invention aims to provide a task state snapshot method for real-time operating systems. By establishing an accurate mathematical model of task register usage and combining compile-time static analysis and runtime dynamic tracing, incremental saving of task context is achieved, significantly reducing the number of register saving operations during task switching and meeting the needs of high real-time scenarios such as power systems.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: See Figure 1 As shown, the solution includes the following steps: Step S1: Compile-time static analysis provides prior information for runtime optimization. Specifically, it includes: developing a static analysis plugin based on the compiler framework, traversing the basic blocks and instructions of the task function, identifying register operands to collect register usage sets, generating a register usage bitmap and register usage map, and embedding the map into a custom segment of the executable file. Step S2: Runtime dirty bit tracking, which records the dynamic modification information of registers with performance overhead. Specifically, it includes: configuring the debug mode, watchpoints and register grouping strategy through the processor's built-in hardware debug support unit, tracking the modification status of registers during task execution in real time, maintaining the dirty bit map in the task control block and dynamically modifying the information. Step S3: Incremental saving during task switching to achieve on-demand storage of task context. Specifically, this includes: performing bitwise AND operations based on the register usage map and the dirty bitmap to obtain the register save mask and the floating-point register save mask, selectively saving the corresponding registers according to the save mask, and clearing the dirty bitmap after saving.

[0009] Furthermore, step S1 specifically includes the following steps: Step S11: Develop a static analysis plugin based on the LLVM compiler framework, which is executed in the LLVM pass form during the optimization stage of the compilation backend. The plugin receives intermediate code that has completed the mapping from virtual registers to physical registers. Step S12: Collect register usage information and include the registers involved in read / write operations and the registers saved by the callers of function calls into the usage set; Step S13: Convert the collection to bitmap format; Step S14: Modify the linker script to write the graph data into this section and establish a mapping relationship between task function names and graph addresses; Step S15: Enable the map generation function via the compiler command-line option -fgenerate-rum, and disable the function via -fno-generate-rum.

[0010] Furthermore, in step S2, configuring the debug mode through the processor's built-in hardware debug support unit is as follows: Step S21: During the operating system startup phase, configure the processor debug mode control register and enable debug monitor mode; Step S22: Assign a hardware watchpoint to each task to monitor write operations in the task stack area; Step S23: Adopt a register grouping strategy and make each group share the dirty bit flag; Step S24: Register an assembly language exception handling function to respond to exceptions triggered by watchpoints.

[0011] Furthermore, in step S2, the dirty bitmap is maintained and its information is dynamically modified in the task control block, as follows: Step S25: Calculate the offset between the stack address that triggered the exception and the base address of the task stack; Step S26: Determine the register group number based on the offset; Step S27: If group is less than the preset value, update the general-purpose register dirty bitmap; if group is greater than the preset value, update the floating-point register dirty bitmap. Step S28: Clear the exception flag and return; the time and space complexity of the algorithm are both 0.

[0012] Furthermore, step 3 specifically includes the following: Step S31: Load the general-purpose register usage bitmap and dirty bitmap from the current task control block, and perform a bitwise AND operation to obtain the general-purpose register storage mask; Step S32: Iterate through each bit of the stored mask. If it is 1, read the value from the processor register and write it to the register storage area. Step S33: After saving, clear the dirty bitmap of the current task to prepare for tracking after the next task is restored.

[0013] Furthermore, this includes modifications to the real-time operating system kernel, specifically including the following steps: Step S41: Expand the task control block to add a register usage map pointer, a general and / or floating-point register usage bitmap, a general and / or register dirty bitmap, and a register save area pointer; Step S42: Expand the task creation process, parse the executable file's custom segment to extract the graph data, allocate memory in the register storage area, and initialize the dirty bitmap to all 0s; Step S43: Rewrite the task switching function and integrate the incremental save logic described in step three; Step S44: Add a debug monitor exception handling function and register it to the corresponding position in the exception vector table.

[0014] The present invention has the following beneficial effects: 1. This invention fundamentally solves the performance waste caused by the indiscriminate saving of all registers in traditional real-time operating systems through the organic synergy of compile-time static analysis and runtime dynamic tracing. By establishing a precise model of task register usage, it achieves true on-demand saving, reducing the number of register saving operations.

[0015] 2- 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. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the present invention; Figure 2 This is a general framework diagram of the present invention; Figure 3 This is a schematic diagram of the data structure of the register usage spectrum of the present invention; Figure 4 This is a schematic diagram showing the data structure extension of the task control block of the present invention; Figure 5 A schematic diagram of the hardware-assisted mechanism for filth location tracking. Detailed Implementation

[0017] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments: See Figure 1 As shown, the solution includes the following steps: Step S1: Develop a static analysis plugin based on the compiler framework, traverse the basic blocks and instructions of the task function, identify register operands to collect register usage sets, generate a register usage bitmap and register usage map, and embed the map into a custom segment of the executable file; Step S2: Configure the debug mode, watchpoints, and register grouping strategy through the processor's built-in hardware debug support unit, track the modification status of registers during task execution in real time, maintain the dirty bitmap in the task control block, and dynamically modify the information. Step S3: Perform a bitwise AND operation based on the register usage map and the dirty bitmap to obtain the register save mask and the floating-point register save mask. Selectively save the corresponding registers according to the save mask, and clear the dirty bitmap after saving.

[0018] Furthermore, step S1 specifically includes the following steps: Step S11: Develop a static analysis plugin based on the LLVM compiler framework. Execute it in the LLVM pass form during the compilation backend optimization stage. The plugin receives intermediate code that has completed the mapping from virtual registers to physical registers. The plugin also receives intermediate code after register allocation. At this point, the virtual registers have been mapped to the physical registers, and the usage of the physical registers can be directly analyzed. Step S12: Collect register usage information and include the registers involved in read / write operations and the registers saved by the callers of function calls into the usage set; Step S13: Convert the usage set to bitmap format; for general-purpose registers, create a 16-bit integer, initialized to 0, and then set the i-th bit to 1 for each register number i in the usage set. For floating-point registers, create a 32-bit integer bitmap using a similar method. Count the number of bits with a value of 1 in the bitmap, and use this count as the value of the required register count field.

[0019] Step S14: Modify the linker script to write the graph data into this segment and establish a mapping relationship between task function names and graph addresses; modify the linker script to define a custom segment named ".rum", specifying the load address and attributes of this segment. For each task function, allocate 6 bytes of space in the ".rum" segment to store its register usage graph. Simultaneously, establish a mapping relationship between task function names and register usage graph addresses in the executable file's symbol table for easy lookup by the operating system at runtime.

[0020] Step S15: Enable the graph generation function via the compiler command-line option -fgenerate-rum, and disable it via -fno-generate-rum. When generating assembly code, the compiler automatically inserts assembly instruction declarations for the ".rum" section and writes the graph data.

[0021] Specifically, to ensure the accuracy of the generated register usage map, this embodiment, in debug mode, generates additional debug information to record the usage location and context of each register. During runtime, the system monitors actual register accesses and compares them with the map generated at compile time. If a task accesses an unmarked register in the map, the system records an alarm and updates the map to ensure the correctness of subsequent task switching.

[0022] The verification method is implemented as follows: First, register access tracing is enabled for each task during compilation, with the compiler inserting logging code before each instruction that accesses a register. Second, when a task runs for the first time, the system collects the actual register access records and compares them with a pre-generated graph. Finally, if inconsistencies are found, the system automatically corrects the graph and regenerates the executable file. This verification mechanism is only used during the development phase; the officially released system does not include tracing code to avoid performance overhead.

[0023] Furthermore, in step S2, configuring the debug mode through the processor's built-in hardware debug support unit is as follows: Step S21: During the operating system startup phase, configure the processor debug mode control register and enable debug monitor mode; for ARM Cortex-M4, set the MON_EN bit of the DEMCR register of the system control block to 1. For RISC-V processors, configure the debug control status register dcsr and set the debug mode to debug monitor mode instead of debug entry mode.

[0024] Step S22: Assign a hardware watchpoint to each task to monitor write operations in the task stack area. Since register values ​​are saved on the stack during task switching, monitoring stack write operations can indirectly track register modifications. For ARM Cortex-M4, configure the comparator register DWT_COMPn of the DWT unit, set the monitoring address to the top address of the task stack, and set the mask to cover a range of 256 bytes. For RISC-V processors, configure the tdata1 and tdata2 registers of the triggers, set the trigger type to address matching, and the action to generate a breakpoint exception.

[0025] Step S23: Employ a register grouping strategy, ensuring each group shares a dirty flag. Specifically, divide the 16 general-purpose registers into 4 groups of 4 registers each; divide the 32 floating-point registers into 8 groups of 4 registers each. Each group shares a dirty flag. Based on the address offset of the registers saved to the stack, configure watchpoints to monitor the corresponding stack address range. When a certain address range is written to, mark all registers in the corresponding group as dirty.

[0026] Step S24: Register an assembly language exception handling function to respond to exceptions triggered by watchpoints. This function has the highest priority to ensure timely response to exceptions triggered by watchpoints. The exception handling function is written in assembly language, directly accessing hardware registers to avoid the overhead of C language function calls. The function code length is controlled to within 50 instructions, ensuring execution time does not exceed 1 microsecond.

[0027] Furthermore, in step S2, the dirty bitmap is maintained and its information is dynamically modified in the task control block, as follows: Step S25: Calculate the offset between the stack address that triggered the exception and the task stack base address; the offset calculation formula is: offset = addr - tcb->stack_base; Step S26: Determine the register group number based on the offset; the group number calculation formula is: group = offset / 16; Step S27: If group is less than 4 (total number of general-purpose register groups), update the dirty bitmap of general-purpose registers; if group is greater than 4, update the dirty bitmap of floating-point registers. Step S28: Clear the exception flag and return; the time and space complexity of the algorithm are both 0.

[0028] Specifically, this embodiment uses a combination of techniques to control the performance overhead of dirty bit tracking to within 1%, as follows: First, through a register grouping strategy, the tracking requirements of 48 registers are compressed into 12 groups, with a maximum of 12 exception triggers. For a task with an execution time of 1 millisecond, even if each exception handling takes 1 microsecond, the total overhead is only 1.2%. Second, the exception handling function is implemented in assembly language to avoid overhead such as register stack pushing and function calls. The function directly reads and writes hardware registers, using bitwise operations to quickly update the dirty bitmap. Through loop unrolling and instruction pipeline optimization, the processing time is compressed to within 500 nanoseconds. Dirty bit tracking is only enabled for critical real-time tasks; low-priority non-real-time tasks use a traditional full-data saving strategy; tasks of different priorities share hardware observation point resources, and the monitoring address is dynamically reconfigured when a high-priority task preempts it.

[0029] Furthermore, step 3 specifically includes the following: Step S31: Load the general-purpose register use bitmap B_gpr_use and the dirty bitmap B_gpr_dirty from the current task control block, and perform a bitwise AND operation to obtain the general-purpose register save mask B_gpr_save = B_gpr_use & B_gpr_dirty. Perform the same operation on the floating-point registers to obtain B_fpr_save.

[0030] Step S32: Iterate through each bit of the storage mask. If a bit is 1, read the value from the processor register and write it to the register storage area. For cases where multiple consecutive bits are 1, use ARM's STMIA batch store instruction or RISC-V's sequential store instruction to save multiple registers at once, improving efficiency.

[0031] Step S33: After saving, clear the dirty bitmap of the current task to prepare for tracking after the next task is restored.

[0032] Furthermore, this includes modifications to the real-time operating system kernel, specifically including the following steps: Step S41: Expand the task control block to add a register usage map pointer, a general and / or floating-point register usage bitmap, a general and / or register dirty bitmap, and a register save area pointer; Step S42: Expand the task creation process, parse the executable file's custom segment to extract the graph data, allocate memory in the register storage area, and initialize the dirty bitmap to all 0s; Step S43: Rewrite the task switching function and integrate the incremental save logic described in step three; Step S44: Add a debug monitor exception handling function and register it to the corresponding position in the exception vector table.

[0033] Specifically, this embodiment is implemented on an STM32F407 microcontroller (ARM Cortex-M4 core, 168 MHz), running a self-developed real-time operating system that supports preemptive priority scheduling.

[0034] First, using the ARM GNU toolchain (optimization level 2), a static analysis plugin (LLVM Pass form) based on the LLVM compiler framework is developed and executed during the compilation backend optimization stage. The plugin traverses all basic blocks and instructions of the task function, identifies register operands, and includes the registers involved in read and write operations, as well as the caller's save registers (r0 to r3, r12) corresponding to function calls, into the usage set. A register usage map of triplet structure is generated. The general-purpose register bitmap is a 16-bit integer, and the floating-point register bitmap is a 32-bit integer. The total number of bits with a value of 1 in the bitmap is counted as the number of required save registers. The entire map occupies 6 bytes of space. Taking the data acquisition task as an example, its map is a general-purpose register bitmap 0xE00F, a floating-point register bitmap 0x00000000, and a required save count of 8. The linker script is modified to define a custom segment named ".rum" (located in the Flash read-only area), the map data is written to this segment, and a mapping relationship between the task function name and the map address is established. The map generation function is enabled by the "-fgenerate-rum" option.

[0035] Secondly, the DEMCR register of the ARM Cortex-M4 is configured, with MON_EN set to 1 to enable debug monitor mode; the 16 general-purpose registers are divided into 4 groups (4 registers per group), and the 32 floating-point registers are divided into 8 groups (4 registers per group), with each group sharing a dirty bit flag; the 4 comparators of the DWT unit are configured to monitor different address ranges of the task stack (each group corresponds to 16 bytes of space), and the comparator functions are set to data address value matching, generating debug monitor exceptions, and matching write operations; an exception handling function written in assembly language (≤50 instructions) is registered with the highest priority; when the task is executed, register values ​​are pushed onto the stack to trigger an exception, the exception handling function calculates the offset offset=addr - tcb->stack_base and the group number group=offset / 16, updates the dirty bitmap of the corresponding group, and the processing time is about 500 nanoseconds. Through coarse-grained grouping and exception handling optimization, the tracing overhead is controlled to within 1%.

[0036] Finally, during task switching, the general-purpose / floating-point register use bitmap and dirty bitmap are loaded from the current task control block; the save mask is calculated: B_gpr_save=B_gpr_use&B_gpr_dirty, B_fpr_save=B_fpr_use&B_fpr_dirty; the save mask is traversed, and the registers corresponding to consecutive bits of 1 are saved at once using ARM's STMIA bulk store instruction; after saving, the dirty bitmap of the current task is cleared.

[0037] Specifically, this embodiment is implemented on the Pingtouge XuanTie C910 processor (RV64GC instruction set, 1.2 GHz) and runs the RT-Thread operating system.

[0038] This embodiment implements the method of this embodiment on the Pingtouge XuanTie C910 processor based on the RISC-V RV64GC instruction set. This processor operates at a frequency of 1.2 GHz and supports 64-bit address space and floating-point operations. The system runs the RT-Thread real-time operating system, which has been customized to support the optimization techniques of this invention.

[0039] The RISC-V GNU toolchain is used, and compilation options are configured to support the RV64GC instruction set. The LLVM static analysis plugin is adjusted to support the RISC-V architecture, replacing the 16 general-purpose registers of ARM with the 32 general-purpose registers x0 to x31 of RISC-V. According to the RISC-V application binary interface specification, the caller-saved registers (x1, x5 to x7, x10 to x17, x28 to x31) and the callee-saved registers (x8 to x9, x18 to x27) are identified.

[0040] The register use map's data structure needs to be adjusted to accommodate more registers. The general-purpose register bitmap is expanded to 32-bit integers, while the floating-point register bitmap remains 32-bit integers. The entire map data structure occupies 9 bytes of space.

[0041] Register modification tracing is implemented using the RISC-V trigger module. During operating system startup, the CSR select instruction is used to select the trigger number. Trigger data register 1 is configured, setting the trigger type to address or data match control type, and configuring the debug mode bit, execute bit, and memory bit. Trigger data register 2 is configured with the stack top address of the current task. A register grouping strategy similar to that of the ARM platform is adopted, dividing the 32 general-purpose registers into 8 groups of 4 registers each.

[0042] Tests were conducted on the RISC-V platform using the same task set as the ARM platform. Comparison of test data from the ARM and RISC-V platforms showed highly consistent optimization results.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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 taking snapshots of task states in a real-time operating system, characterized in that, Includes the following steps: Step S1: Develop a static analysis plugin based on the compiler framework, traverse the basic blocks and instructions of the task function, identify register operands to collect register usage sets, generate a register usage bitmap and register usage map, and embed the map into a custom segment of the executable file; Step S2: Configure the debug mode, watchpoints, and register grouping strategy through the processor's built-in hardware debug support unit, track the modification status of registers during task execution in real time, maintain the dirty bitmap in the task control block, and dynamically modify the information. Step S3: Perform a bitwise AND operation based on the register usage map and the dirty bitmap to obtain the register save mask and the floating-point register save mask. Selectively save the corresponding registers according to the save mask, and clear the dirty bitmap after saving.

2. The task state snapshot method for a real-time operating system according to claim 1, characterized in that, Step S1 specifically includes the following steps: Step S11: Develop a static analysis plugin based on the LLVM compiler framework, which is executed in the LLVM pass form during the optimization stage of the compilation backend. The plugin receives intermediate code that has completed the mapping from virtual registers to physical registers. Step S12: Collect register usage information and include the registers involved in read / write operations and the registers saved by the callers of function calls into the usage set; Step S13: Convert the collection to bitmap format; Step S14: Modify the linker script to write the graph data into this section and establish a mapping relationship between task function names and graph addresses; Step S15: Enable the map generation function via the compiler command-line option -fgenerate-rum, and disable the function via -fno-generate-rum.

3. The task state snapshot method for a real-time operating system according to claim 1, characterized in that, In step S2, the debugging mode is configured through the processor's built-in hardware debugging support unit, as follows: Step S21: During the operating system startup phase, configure the processor debug mode control register and enable debug monitor mode; Step S22: Assign a hardware watchpoint to each task to monitor write operations in the task stack area; Step S23: Adopt a register grouping strategy and make each group share the dirty bit flag; Step S24: Register an assembly language exception handling function to respond to exceptions triggered by watchpoints.

4. The task state snapshot method for a real-time operating system according to claim 1, characterized in that, In step S2, the dirty bitmap is maintained and its information is dynamically modified in the task control block, as follows: Step S25: Calculate the offset between the stack address that triggered the exception and the base address of the task stack; Step S26: Determine the register group number based on the offset; Step S27: If group is less than the preset value, update the general-purpose register dirty bitmap; If the group is greater than the preset value, then update the floating-point register dirty bitmap; Step S28: Clear the exception flags and return; The algorithm has a time complexity and a space complexity of 0.

5. The task state snapshot method for a real-time operating system according to claim 1, characterized in that, Step 3 is specifically as follows: Step S31: Load the general-purpose register usage bitmap and dirty bitmap from the current task control block, and perform a bitwise AND operation to obtain the general-purpose register storage mask; Step S32: Iterate through each bit of the stored mask. If it is 1, read the value from the processor register and write it to the register storage area. Step S33: After saving, clear the dirty bitmap of the current task to prepare for tracking after the next task is restored.

6. The task state snapshot method for a real-time operating system according to claim 1, characterized in that, It also includes modifications to the real-time operating system kernel, specifically including the following steps: Step S41: Expand the task control block to add a register usage map pointer, a general and / or floating-point register usage bitmap, a general and / or register dirty bitmap, and a register save area pointer; Step S42: Expand the task creation process, parse the executable file's custom segment to extract the graph data, allocate memory in the register storage area, and initialize the dirty bitmap to all 0s; Step S43: Rewrite the task switching function and integrate the incremental save logic described in step three; Step S44: Add a debug monitor exception handling function and register it to the corresponding position in the exception vector table.

Images