An embedded microkernel generation method and system based on semantic parsing and deterministic back end

Abstract

The application discloses a kind of based on semantic analysis and deterministic back-end's embedded microkernel generation method and system.For the redundancy of embedded task ABI register, the big language model generates the problem such as non-determinism and illusion that underlying code is easy to produce and the big overhead of RTOS context saving, the generation process is decoupled into two stages: first, in semantic analysis stage, user intent is converted into abstract task graph without physical register information;Then, in the deterministic code synthesis stage, the deterministic algorithm back-end combines atomic assembly library constraints, performs global control / data flow analysis and physical register allocation, generates target code, and verifies its consistency through static checking and dynamic differential testing.The application effectively reduces register and context handling overhead, significantly reduces code size, execution time and energy consumption, and ensures the determinism and reproducibility of the output result.

Description

Technical Field

[0001] This invention relates to the fields of computer software engineering and embedded systems technology, specifically to a method and system for generating embedded microkernels based on semantic parsing and a deterministic backend. More specifically, this invention relates to a method and system for using a semantic parser (such as a large language model) to perform high-level task intent understanding, and combining the Standard Atomic Assembly Library (SAAL) to generate a deeply optimized embedded microkernel through a deterministic algorithm.

[0002] This invention is particularly applicable to Internet of Things (IoT) edge devices, sensor nodes, smart wearable devices, and ultra-low power microcontroller units (MCUs) that have extremely strict constraints on hardware resources (storage space, power consumption, computing power). Background Technology

[0003] With the arrival of the post-Moore's Law era, Internet of Things (IoT) devices are facing an increasingly severe "scissors gap" challenge: On the demand side: Edge devices need to handle increasingly complex tasks, including but not limited to: High-frequency sensor data fusion (such as multimodal data acquisition from IMU + GPS + temperature and humidity sensors); End-side encryption verification (such as AES-128 encryption, CRC32 checksum, digital signature); Lightweight machine learning inference (such as decision trees, forward propagation of convolutional neural networks); Real-time control logic (such as PWM signal generation, PID closed-loop control).

[0004] On the resource side: To ensure battery life (e.g., powering for several years with a coin cell battery) and reduce deployment costs, the hardware resources of these devices are extremely limited. Memory capacity: Typically only a few thousand bytes (KB) to tens of kilobytes of SRAM are provided; Computing power: Employs low-frequency microcontrollers (e.g., tens to hundreds of MHz); Power consumption constraint: Average power consumption needs to be controlled in the range of milliwatts (mW) to microwatts (μW).

[0005] To bridge the gap between complex tasks and limited resources, traditional embedded software development stacks have long used a layered architecture: 1. Developers use high-level languages ​​(such as C / C++) to write source code; 2. Compile into machine code for the target platform using a general-purpose optimizing compiler (such as GCC, LLVM / Clang); 3. It runs on a real-time operating system (RTOS, such as FreeRTOS, Zephyr, RT-Thread).

[0006] While this architecture provides the necessary development abstraction and portability, this classic "compiler-centric" paradigm introduces a significant performance penalty. This invention defines it as the "Generic Penalty".

[0007] Specifically, existing technologies have the following three core flaws: Defect 1: The overhead of compiler application of binary interface (ABI) ("compiler wall") To ensure modular development and independent compilation of software modules, modern compilers must strictly adhere to platform-specific Application Binary Interface (ABI) specifications. Taking the RISC-V architecture as an example, its psABI (Procedure Standard ABI) specification strictly divides the 32 general-purpose registers into two categories: Caller-saved registers include a0-a7 (parameter registers) and t0-t6 (temporary registers). The caller function must save the values ​​of these registers onto the stack before calling other functions (if they will be needed later).

[0008] Callee-saved registers include s0-s11 (saved registers) and ra (return address register). The called function must save the original values ​​of these registers onto the stack before modifying them and restore them before returning.

[0009] To ensure program correctness, the compiler is forced to generate a "defensive" sequence of register save / push and restore / pop instructions at the boundary of each function call, namely the function prologue and epilogue.

[0010] Example: The assembly code for a simple RISC-V function might include: function_start: addi sp, sp, -16 # Allocate stack space ra, 12(sp) # Save the return address s0, 8(sp) # Save the s0 register # ... Function body... s0, 8(sp) # Restore register s0 ra, 12(sp) # Restore return address addi sp, sp, 16 # Release stack space ret # Return Even with Link-Time Optimization (LTO), the compiler is still constrained by the ABI contract and cannot "see through" function boundaries to perform global register optimizations. This means that even if saving certain registers is completely redundant from a global perspective (e.g., a function never modifies the s0 register), the compiler must still generate these redundant instructions. This mechanism constitutes the so-called "Compiler Wall," hindering cross-function global register optimizations.

[0011] In a typical IoT control task, function preamble / final instructions account for 15%-25% of the total number of instructions, of which about 60% of register save operations are redundant.

[0012] Defect 2: Redundancy in context switching of general-purpose RTOS Existing mainstream RTOS kernels (such as FreeRTOS and Zephyr) typically employ conservative, general strategies when performing task scheduling and context switching. To accommodate any possible task behavior, the kernel must maintain a fixed, full context stack frame.

[0013] Taking the implementation of FreeRTOS on the RISC-V architecture as an example, its context switching code typically includes: All general-purpose registers (s0-s11, a total of 12 registers) saved by all callees. Critical control status registers (CSRs), such as mepc (exception return address) and mstatus (machine status); Floating-point registers (if floating-point extension is enabled).

[0014] This "one-size-fits-all" mechanism fails to detect the actual register usage of a specific task (context-unnaware). For many simple IoT sensing tasks that only use a few temporary registers (such as t0-t2), saving the full context means that the CPU needs to execute dozens of useless push instructions.

[0015] This mechanism has the following performance impacts: 1. Additional instructions: Approximately 30-50 redundant instructions are added with each context switch; 2. Memory access overhead: Each context switch generates approximately 20-40 high-energy-consuming memory bus transactions (Load / Store operations), which is particularly detrimental in low-power scenarios.

[0016] Measured on the ESP32-C3 platform, FreeRTOS's context switching latency is approximately 8-12 microseconds, with about 60% of the time consumed in redundant register save / restore operations.

[0017] Defect 3: The unreliability of existing AI code generation In recent years, code generation technologies based on Large Language Models (LLMs) (such as GitHub Copilot, OpenAI Codex, and Amazon CodeWhisperer) have developed rapidly. While LLMs excel at generating high-level logic code like Python or Java, they have serious limitations in generating low-level embedded assembly code, making them unsuitable for direct application in industrial-grade embedded systems. Question 1: Hallucination problem. The LLM may generate non-existent hardware instructions, reference incorrect register names, or access illegal memory addresses.

[0018] Example: When some large language models generate RISC-V assembly code, they may output non-existent instructions such as movra0, a1 (the correct one should be mv a0, a1), or use incorrect CSR addresses.

[0019] Question 2: The output of a non-deterministic LLM is inherently probabilistic; for the same input prompt, different code implementations may be generated at different times. This randomness is unacceptable for industrial embedded systems that require 100% reproducibility and high reliability.

[0020] Example: For the same task "add 1 to the value of register a0", LLM may generate adddi a0,a0, 1 ​​the first time and add a0, a0, t0 the second time, which can lead to debugging difficulties and instability in the production environment.

[0021] Question 3: Disorganized resource management. When generating long sequence assembly code, LLM has difficulty maintaining accurate register allocation in a long context, which can easily lead to register clobbering or data overwriting.

[0022] Example: An LLM might assign t0 to variable A in the first half of the code, but forget this fact in the second half and reassign t0 to variable B, causing the value of variable A to be accidentally overwritten.

[0023] The existing related technologies are as follows: Related technology 1: Traditional compiler optimization techniques such as GCC's -O3 optimization and LLVM's multi-level intermediate representation (IR) optimization. However, these techniques are still limited by ABI constraints and cannot achieve global register optimization across functions.

[0024] Related technology 2: Custom RTOS kernels. Commercial RTOS such as uC / OS-III and embOS offer a certain degree of configurability, but still use a general context switching mechanism, which cannot be dynamically optimized for specific tasks.

[0025] Related technology 3: Code generation based on domain-specific languages ​​(DSLs) such as Esterel and Lustre, but these technologies are mainly aimed at control logic modeling and lack the ability to optimize the allocation of underlying registers.

[0026] Related technology 4: Neural network-assisted compilation optimization, such as DeepMind's AlphaDev and MIT's Halide, but these technologies mainly focus on the optimization of specific operators and do not involve the generation of a complete operating system kernel.

[0027] This invention is the first complete kernel generation system that combines "LLM semantic parsing" with "deterministic backend synthesis". It not only utilizes the high-level understanding capabilities of AI, but also ensures security and reproducibility through deterministic algorithms, and breaks through the ABI limitations of traditional compilers.

[0028] Therefore, the industry urgently needs a new paradigm for building embedded systems that meets the following four key requirements: 1. Security and determinism: It can leverage the semantic understanding capabilities of large models, but it is essential to eliminate the risk of "illusion" and ensure 100% reproducibility. 2. Breakthrough in performance limits: It can bypass the ABI limitations of traditional compilers and achieve global register optimization across tasks; 3. Significantly reduced energy consumption: It can eliminate redundant register save / restore operations and memory accesses, significantly reducing power consumption; 4. Lowered development threshold: Allows developers to define underlying hardware logic using natural language or high-level descriptions, realizing "intent as code". Summary of the Invention

[0029] The purpose of this invention is to address the shortcomings of existing technologies by providing an embedded microkernel generation method and system based on semantic parsing and a deterministic backend. This aims to solve the technical problems of high compiler ABI overhead, redundant RTOS context switching, and unreliability of directly using large models to generate assembly code in existing technologies.

[0030] The objective of this invention is achieved through the following technical solution: an embedded microkernel generation method based on semantic parsing and a deterministic backend, comprising the following steps: S1: Constructing the Standard Atomic Assembly Library (SAAL): A database containing multiple atomic primitives is pre-built and stored. Each atomic primitive is a manually written or verified, single-function assembly code snippet containing an assembly body and semantic metadata describing its hardware behavior. The semantic metadata is structured data describing the hardware behavior of the primitive, including at least a list of input interface registers, a list of output interface registers, and a list of temporary registers contaminated during execution. Each atomic primitive contains two key pieces of information: the sequence of machine instructions that the assembly body implements for a specific function. S2: Intent Parsing and Task Decomposition: Receive user input of a task intent description (such as natural language or pseudocode), use a semantic parser (such as a large language model) as the semantic parser to extract and map features from the task intent description, generate an abstract task graph, analyze the user intent and decompose it into a logical sequence composed of SAAL atomic primitives; the abstract task graph is a directed acyclic graph data structure, where nodes represent computational tasks and edges represent data dependencies, and the data flow in the abstract task graph is represented by symbolic variables and does not contain physical register allocation information; S3: Primitive matching: Based on the semantic features (functional constraints and input / output symbolic variable constraints) of each node in the abstract task graph, vector retrieval technology is used to retrieve the most matching candidate atomic primitives and their corresponding semantic metadata from the Standard Atomic Assembly Library (SAAL).

[0031] S4: Deterministic Code Synthesis: The retrieved candidate atomic primitives and their metadata are input into a deterministic algorithm backend. This backend performs global control flow and data flow analysis, and performs global register allocation based on the interface constraints and pollution list in the semantic metadata. This ensures that the generated code meets the constraints of the target processor's instruction set architecture, register set, and calling convention, outputting microkernel target code or bare-metal binary (such as an ELF file) for execution on the target processor. The calling convention refers to "interface rules" or "contracts," which specify the specific operational procedures that must be followed when one piece of code (the caller) calls another piece of code (the callee, such as a function or task) in a program. S5: Static compliance check: Perform static constraint checks on the microkernel target code or bare-metal binary, including at least register usage compliance checks and calling convention consistency checks; if the checks fail, refuse to output or return to the deterministic algorithm backend for resynthesis.

[0032] Furthermore, in S1, the number of atomic primitives in SAAL is determined according to the target application scenario, with a typical size of 128-512 primitives; Furthermore, in S1, the granular design of primitives follows the "single responsibility principle," with each primitive performing only one specific function (such as integer addition, memory loading, bit shifting, etc.). Furthermore, in S1, metadata is stored in JSON or XML format, supporting efficient retrieval and parsing.

[0033] Furthermore, in S2, the semantic parser is strictly limited to outputting only the Abstract Task Graph (ATG). The ATG defines the execution order and data dependencies of task nodes, uses symbolic variables to represent data flow, and does not allocate any physical registers.

[0034] Furthermore, in S2, the semantic parser can be a large language model (such as a certain type of large language model, a certain type of large language model, a certain type of large language model, etc.) or a rule-based symbolic reasoning system; Furthermore, in S2, in order to improve the accuracy of parsing, the Retrieval-Augmented Generation (RAG) technique is adopted to retrieve primitive information in SAAL in real time as context during inference; Furthermore, in S2, the output ATG uses JSON or a similar structured format to facilitate subsequent algorithm processing.

[0035] Furthermore, in S3, a vector database (such as FAISS, Milvus) is used to store the semantic embeddings of SAAL primitives, and similarity matching is performed through cosine similarity or Euclidean distance; Furthermore, in S3, for each task node, Top-K candidate primitives are retrieved, and the semantic parser selects the most suitable one; Furthermore, S3 supports the dynamic addition of user-defined primitives (through a hybrid synthesis mechanism).

[0036] Furthermore, in S4, the backend adopts a multi-stage pipeline architecture: control flow analysis → activity analysis → register allocation → code generation; Furthermore, in S4, the register allocation algorithm can be selected from graph coloring, linear scan, or integer linear programming, depending on the target architecture and performance requirements; Furthermore, in S4, the generated machine code conforms to the ELF format specification of the target architecture and can be directly burned into hardware or loaded into an emulator.

[0037] Furthermore, in step S4, the deterministic backend synthesis employs a context-aware optimization strategy: By analyzing the data dependencies (output-input dependencies) between adjacent preceding and succeeding task nodes in the abstract task graph, if it is determined that there is a direct data path between the output symbolic variable (output register) of the preceding task node and the input symbolic variable (input register) of the succeeding task node, and the physical register carrying the data does not belong to the polluted register list of any executed atomic primitive between the two nodes (i.e., the register is not polluted by the intermediate process), then the physical register is directly locked, and the data loading instruction is skipped when generating the code of the succeeding task node, and the register value of the preceding task node is directly reused to achieve zero-copy register forwarding.

[0038] Furthermore, in step S4, the deterministic backend synthesis also includes the generation of a minimum context set (Cmin): Scan all called atomic primitives in the entire task flow, extract the register pollution list from their semantic metadata, and calculate their union to obtain the full pollution set Ctotal; Obtain the callee saved register set CABI as defined in the Application Binary Interface (ABI) specification of the target hardware architecture; Calculate the intersection of the full contamination set and the set of callee saved registers to obtain the minimum context switching set: Cmin = Ctotal ∩ CABI; At the entry and exit points of the generated microkernel, only instruction sequences for saving and restoring the registers in the minimum context switching set are generated, eliminating redundant register saving operations that are forcibly generated by traditional compilers.

[0039] Furthermore, the standard atomic assembly library supports a hybrid synthesis extension mechanism: Receive user input of custom high-level language code snippets; The compiler is invoked to compile the code snippet into assembly code; The assembly code's input / output register dependencies and register usage are automatically extracted through static analysis, generating corresponding semantic metadata. The assembly code and its semantic metadata are encapsulated into a user-defined primitive (UDP) and added to the standard atomic assembly library so that it can participate in the global register allocation process in step S4.

[0040] Furthermore, the physical register allocation algorithm used in the deterministic algorithm backend is selected from one or more of the following: graph coloring, linear scan, or optimization allocation algorithm based on integer linear programming (ILP); Under the same conditions of standard atomic assembler library version, deterministic algorithm backend parameter configuration and target hardware architecture constraints, the deterministic algorithm backend generates the same physical register allocation scheme and machine code output for the same abstract task graph input, ensuring the reproducibility of the system.

[0041] Furthermore, the present invention also includes a verification pipeline, comprising: Static constraint check: Scan the generated microkernel machine code and check whether the register operations of each instruction exceed the scope of the interface and pollution list declared in the semantic metadata (violate the register usage contract declared in the SAAL metadata). If a violation is detected, the generation will be rejected and an error will be reported. Differential Testing: The generated microkernel machine code is executed in parallel on the target physical hardware with the same input vector in an instruction set simulator (ISS) (such as QEMU, Spike). The consistency of the architectural status register values ​​and memory side effects between the two is compared. The verification is considered successful only when the two are completely consistent, thus ensuring functional correctness.

[0042] The verification pipeline ensures the security of the generated code, completely eliminates the "illusion" risk of LLM, provides a high degree of confidence in functional correctness, and is suitable for industrial applications.

[0043] On the other hand, the present invention also provides an embedded microkernel generation system based on semantic parsing and a deterministic backend, comprising: Knowledge base subsystem: used to store the standard atomic assembly library SAAL and a vector database that supports semantic retrieval. The vector database pre-embeds and encodes the functional description of each atomic primitive to support efficient semantic similarity retrieval. Semantic parsing subsystem: Used to run the semantic parser, receive task intent descriptions input by the user in natural language or pseudocode form, and output a structured abstract task graph (ATG); Deterministic synthesis subsystem: used to execute global activity analysis and physical register allocation algorithms, realize zero-copy register forwarding optimization and minimal context switching code generation, and finally output the microkernel binary file of the target architecture; Verification subsystem: Used to perform static constraint checks and dynamic differential tests on the generated microkernel code to ensure the security and functional correctness of the code.

[0044] Furthermore, the semantic parsing subsystem further includes: Intent understanding module: Uses a large language model to perform semantic parsing of user input and extract high-level functional requirements of the task; Primitive matching module: Through retrieval enhancement generation RAG technology, it retrieves a set of candidate atomic primitives from the standard atomic assembly library that are most semantically similar to the task nodes; Task graph construction module: Based on the data dependencies of the tasks, construct an abstract task graph with a directed acyclic graph structure, and assign symbolic input and output variables to each node.

[0045] Furthermore, the deterministic synthesis subsystem adopts a multi-stage pipeline architecture, including: Control flow analysis phase: Analyze the execution order of nodes and branch jump logic in the abstract task graph; Activity analysis phase: Calculate the lifetime range of each symbolic variable and determine its first definition and last use in the code; Register allocation phase: Allocate physical registers for each symbolic variable and employ a register overflow strategy when the lifetimes of symbolic variables overlap; Code generation stage: Based on the register allocation results, the assembly instruction bodies of the atomic primitives are concatenated and necessary register transfer instructions are inserted to finally generate a complete machine code sequence.

[0046] The beneficial effects of this invention are: 1. Security and controllability: By strictly limiting the role of LLM to "generating abstract graphs" and transferring the allocation of resources involving hardware security to deterministic algorithms, the risk of register conflicts or illegal memory access caused by the "illusion" of LLM is completely eliminated, and the 100% reproducibility (determinism) of the system generation is guaranteed.

[0047] Quantitative data: After 1000 repeated generation tests, the present invention consistently produces byte-level consistent output for the same input, while the code generated directly using LLM showed 3 functional errors and 7 performance differences in 10 tests.

[0048] 2. Breaking through performance limits: By bypassing the ABI limitations of traditional compilers, global register optimization across tasks is achieved.

[0049] Experimental data: On a RISC-V-based physical hardware platform (ESP32-C3, 160MHz), compared to a highly optimized C code baseline (GCC-O3 + LTO): The number of instructions has been reduced: by 62.0% under the "Smart Sensing" load (from 246,014 to 93,572). Improved execution speed: Hardware execution time is reduced by 62.5% (from 1580μs to 592μs), achieving a 2.66x speedup; Average performance improvement: The number of instructions is reduced by an average of 37.0% across three typical workloads (smart sensing, secure communication, and feature extraction).

[0050] 3. Significantly reduced energy consumption: Up to 60.6% energy consumption reduction was achieved by reducing the total number of instructions and energy-intensive memory bus transactions (Load / Store).

[0051] Experimental data: Under the "intelligent sensing" load, the energy consumption per task execution decreased from 45.2 μJ to 17.8 μJ, resulting in energy savings of 60.6%. This is crucial for battery-powered IoT devices: assuming 10,000 tasks are performed per day, a 60% energy saving can extend battery life from approximately 2 years to over 5 years.

[0052] 4. Significantly saves storage space: The generated microkernel code segment (.text) is 63.7% smaller than the optimized C binary (from 4,820 bytes to 1,750 bytes).

[0053] Application value: This allows the invention to be deployed on extremely low-cost MCUs (such as MCUs equipped with only 16KB Flash), significantly reducing hardware costs.

[0054] 5. Improved development efficiency: Allows developers to define underlying hardware logic using natural language, lowers the threshold for embedded assembly development, and realizes "Intent-to-Code".

[0055] User feedback: In internal testing, the time for developers who are not embedded system experts to generate sensor control code using this invention was reduced from an average of 8 hours to 30 minutes, improving development efficiency by 16 times.

[0056] 6. Zero-copy register forwarding optimization: Reduces memory access frequency, decreases memory bus transactions, improves data locality, and improves CPU cache hit rate; experiments show that this technique can reduce Load / Store instructions by 15%-30%.

[0057] 7. Minimal Context Switching Set Generation: Reduces context switching latency, lowers task scheduling overhead, reduces stack space usage, and saves valuable RAM resources; experiments show that this technique can reduce context switching instructions by 40%-60%. Attached Figure Description

[0058] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0059] Figure 1 The diagram shows the overall system architecture of the embedded microkernel generation method based on semantic parsing and deterministic backend provided in this embodiment of the invention.

[0060] Figure 2 This is a schematic diagram of the data structure of atomic primitives in the Standard Atomic Assembly Library (SAAL) in an embodiment of the present invention.

[0061] Figure 3This is a flowchart illustrating the semantic parsing and intent translation stage based on LLM in an embodiment of the present invention.

[0062] Figure 4 This is a schematic diagram of the structure of the Abstract Task Graph (ATG) generated for an embodiment of the present invention.

[0063] Figure 5 This is a flowchart of the algorithm for the deterministic backend synthesis engine in an embodiment of the present invention.

[0064] Figure 6 This is a logic block diagram of the verification pipeline (static inspection and differential testing) in an embodiment of the present invention. Detailed Implementation

[0065] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0066] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other.

[0067] like Figure 1 As shown, this invention provides an embedded microkernel generation method based on semantic parsing and a deterministic backend. The specific implementation process is as follows: Example 1: Construction and Organization of the Standard Atomic Assembly Library (SAAL) This embodiment describes how to build and organize the Standard Atomic Assembly Library (SAAL), which is a fundamental component of this invention. Figure 2 As shown, SAAL adopts a hierarchical organizational structure.

[0068] 1.1 Design Principles of Atomic Primitives Each atomic primitive follows the following design principles: Principle 1: Single Responsibility. Each primitive performs only one well-defined, indivisible function. For example: ADD_I32: Performs addition of two 32-bit integers; LOAD_MEM_I32: Loads a 32-bit integer from a memory address into a register; CMP_LT_I32: Compares two 32-bit integers and sets condition flags.

[0069] Principle 2: Clearly Define the Input and Output Interfaces of Each Primitive. These interfaces are explicitly declared through semantic metadata, including: Input Interface Registers: Lists which registers the primitive reads data from; Output Interface Registers: Lists which registers the primitive writes the result to; Clobbered Registers: Lists temporary registers that the primitive modifies during execution but are not output.

[0070] Principle 3: Hardware Independence (Optional) For general-purpose computational operations (such as arithmetic and logical operations), the semantic description of primitives should be as independent as possible from specific hardware architectures to facilitate cross-platform portability. Hardware-dependent instruction encoding is implemented in the assembly instruction body.

[0071] 1.2 Data Structures of Atomic Primitives like Figure 2 As shown, each atomic primitive is stored in the following JSON format: { "primitive_id": "ADD_I32", "description": "Performs addition of two 32-bit signed integers", "assembly_body": [ "add ${out_reg}, ${in_reg1}, ${in_reg2}" ], "metadata": { "input_interface": ["in_reg1", "in_reg2"], "output_interface": ["out_reg"], "clobbered_registers": [], "memory_access": "none", "control_flow": "sequential" }, "target_architecture": "RISC-V RV32I", "constraints": { "register_constraints": { "in_reg1": ["a0-a7", "t0-t6", "s0-s11"], "in_reg2": ["a0-a7", "t0-t6", "s0-s11"], "out_reg": ["a0-a7", "t0-t6", "s0-s11"] } }, "semantic_embedding": [0.12, -0.34, 0.56, ...], / / Semantic vector (used for RAG retrieval) "verification_status": "verified", "author": "system", "created_at": "2025-01-15T10:00:00Z" } primitive_id: The unique identifier of the primitive; Description: Functional description of primitives (natural language), used for LLM understanding; assembly_body: The assembly instruction body, using placeholders (such as ${out_reg}) to represent registers to be allocated; metadata: semantic metadata, including interface declarations, pollution lists, etc.; semantic_embedding: The semantic embedding vector (generated by a pre-trained embedding model) that describes the primitive function and is used for RAG retrieval; verification_status: Verification status (verified / pending verification).

[0072] 1.3 SAAL's classification organization like Figure 2 As shown, SAAL is divided into several categories according to function, with typical classifications as follows: Category 1: Arithmetic Operations, including addition, subtraction, multiplication, division, and modulo. For example: ADD_I32, SUB_I32, MUL_I32, DIV_I32, MOD_I32 ADD_F32, SUB_F32, MUL_F32, DIV_F32 (floating-point operations) Category 2: Logical Operations, including AND, OR, NOT, XOR, bitwise shift, etc. For example: AND_I32, OR_I32, XOR_I32, NOT_I32 SHL_I32, SHR_I32, SAR_I32 (arithmetic right shift) Category 3: Memory Access includes loading, storing, and address calculation. For example: LOAD_MEM_I32, STORE_MEM_I32 LOAD_MEM_OFFSET_I32, STORE_MEM_OFFSET_I32 (Access with offset) Category 4: Control Flow includes comparisons, jumps, function calls, etc. For example: CMP_EQ_I32, CMP_LT_I32, CMP_GT_I32 BRANCH_IF_ZERO, BRANCH_IF_NOT_ZERO CALL_FUNC, RETURN Category 5: Special Instructions include atomic operations, interrupt handling, and hardware peripheral control. For example: ATOMIC_ADD, ATOMIC_CAS (Compare-And-Swap) ENABLE_INTERRUPT, DISABLE_INTERRUPT GPIO_SET, GPIO_CLEAR (GPIO control) 1.4 SAAL's extended mechanism: Hybrid Synthesis To support complex user-defined functions, this invention provides a hybrid synthesis mechanism that allows users to compile and encapsulate high-level language code snippets into new atomic primitives.

[0073] The process is as follows: Step 1: User inputs advanced code: The user provides a C / C++ code snippet, for example: / / User-defined function: Calculate CRC32 checksum uint32_t crc32_update(uint32_t crc, uint8_t data) { crc ^= data; for (int i = 0; i<8; i++) { if (crc&1) crc = (crc>>1) ^ 0xEDB88320; else crc = crc>>1; } return crc; } Step 2: Compile to assembly code: The system call compiler (such as GCC) compiles the code snippet into assembly code for the target architecture (using the -O3 -S option): crc32_update: xor a0, a0, a1 # crc ^= data li t0, 8 # Cyclic counter loop: andi t1, a0, 1 ​​# Check the least significant bit beqz t1, skip_xor srli a0, a0, 1 lui t2, 0xEDB88 ori t2, t2, 0x320 xor a0, a0, t2 j continue skip_xor: srli a0, a0, 1 continue: addi t0, t0, -1 bnez t0, loop ret Step 3: Automatic Metadata Extraction: The system automatically extracts the semantic metadata of the assembly code using static analysis tools (such as LLVM-based Analysis Pass). Input interface: [a0, a1] (based on function parameters) Output interface: [a0] (based on return value) Polluted registers: [t0, t1, t2] (based on instruction analysis) Step 4: Encapsulation into a User-Defined Primitive (UDP): The system encapsulates the assembly code and its metadata into a new atomic primitive named CRC32_UPDATE_UDP and adds it to SAAL. This primitive participates in the subsequent global register allocation process.

[0074] This invention allows users to reuse optimized C code while enjoying the performance advantages of global register allocation, lowering the barrier to entry for hand-written assembly and improving development efficiency.

[0075] 1.5 SAAL's Vector Retrieval Support To support RAG retrieval during the semantic parsing phase, a semantic embedding vector is pre-computed for each primitive in SAAL.

[0076] Implementation method: Step 1: Generate a text representation of the primitive description: Concatenate the primitive_id and description fields of the primitive into a text, for example: Primitive ID: ADD_I32 Description: Performs addition of two 32-bit signed integers. Step 2: Calculate semantic embeddings. Encode the text into a high-dimensional vector (e.g., 768-dimensional) using a pre-trained embedding model (such as OpenAI's text-embedding-ada-002 or open-source sentence-transformers).

[0077] Step 3: Store in a vector database. Store the embedded vector and its corresponding primitive ID in a vector database (such as FAISS, Milvus) to support efficient approximate nearest neighbor (ANN) retrieval.

[0078] Retrieval process: When the semantic parser needs to match a certain task node, it encodes the functional description of the task into a vector, and then retrieves the Top-K most similar primitive candidate set from the vector database for the model to select.

[0079] Example 2: Semantic Parsing and Abstract Task Graph Generation Based on Large Language Model This embodiment describes how to use a Large Language Model (LLM) as a semantic parser to translate a user's task intent into an Abstract Task Graph (ATG). For example... Figure 3 As shown, the process consists of three key steps.

[0080] 2.1 User Intent Input and Preprocessing Input format: Users can describe their task intent in any of the following ways: Natural language explanation: "Read sensor data from the ADC, perform FIR filtering, and then detect the threshold." pseudocode: sensor_data = adc_read(); filtered_data = fir_filter(sensor_data, coeffs); if (filtered_data > threshold) trigger_alarm(); Structured description: Task description in JSON format Preprocessing steps: Step 1: Intent Normalization The system first normalizes the user input, including: Remove irrelevant modifiers (such as "please help me", "can you", etc.); Extract key verbs and operation objects (such as "read ADC", "filter", "detection threshold").

[0081] Step 2: Context Enhancement If the user input involves a specific hardware peripheral or protocol (such as "ADC", "UART", "SPI"), the system will retrieve relevant background information from the knowledge base and provide it to the LLM as context.

[0082] 2.2 Primitive Matching and Task Graph Construction Based on RAG like Figure 3 As shown, the semantic parsing process adopts a combination strategy of "constrained reasoning process + RAG".

[0083] Step 1: High-Level Intent Decomposition The LLM first decomposes the user intent into a series of high-level steps. For example, for the input "Read sensor data from ADC, perform FIR filtering, and then detect the threshold", the LLM output is: { "high_level_steps": [ {"step": 1, "action": "Read ADC data", "input": [], "output": ["sensor_data"]}, {"step": 2, "action": "FIR filtering", "input": ["sensor_data", "coeffs"], "output": ["filtered_data"]}, {"step": 3, "action": "threshold detection", "input": ["filtered_data", "threshold"], "output": ["alarm_flag"]} ] } Step 2: Primitive Matching (RAG Retrieval) For each high-level step, LLM retrieves a set of matching atomic primitive candidates from SAAL via the RAG mechanism.

[0084] Example: For step 1 "Read ADC data", the system performs the following operations: 1) Generate query vector: Encode the step description "Read ADC data" into an embedded vector v_query.

[0085] 2) Vector Retrieval: Retrieves the top-5 most similar primitives from SAAL's vector database, for example: [ {"primitive_id": "ADC_READ_SINGLE", "similarity": 0.92}, {"primitive_id": "ADC_READ_CONTINUOUS", "similarity": 0.87}, {"primitive_id": "GPIO_READ", "similarity": 0.45}, {"primitive_id": "UART_READ", "similarity": 0.32}, {"primitive_id": "I2C_READ", "similarity": 0.28} ] 3) Primitive selection: LLM selects the most appropriate primitive based on the task context, such as ADC_READ_SINGLE.

[0086] Step 3: Construct the Abstract Task Graph (ATG) as follows Figure 4 As shown, LLM organizes the matched primitives into a directed acyclic graph (DAG) structure.

[0087] 1) Node Creation: Create a task node for each primitive, containing the following information: { "node_id": "node_1", "primitive_id": "ADC_READ_SINGLE", "symbolic_inputs": [], "symbolic_outputs": ["var_sensor_data"] } 2) Edge Creation (Data Dependency): If the input symbolic variable of node B comes from the output of node A, then a directed edge is created from A to B. For example: { "edge": { "from": "node_1", "to": "node_2", "data_flow": {"var_sensor_data": "input_0"} } } 3) Symbolic representation: In ATG, all data streams are represented using symbolic variables (such as var_sensor_data) and are not bound to physical registers (such as a0, t1). This allows the LLM to focus only on the logical relationship of "where the data comes from and where it goes" without having to manage the underlying register allocation.

[0088] 2.3 Output Format and Constraints The output of LLM is strictly constrained to the following JSON format: { "task_graph": { "nodes": [ { "node_id": "node_1", "primitive_id": "ADC_READ_SINGLE", "symbolic_inputs": [], "symbolic_outputs": ["var_sensor_data"], "description": "Read sensor data from ADC channel 0" }, { "node_id": "node_2", "primitive_id": "FIR_FILTER_I32", "symbolic_inputs": ["var_sensor_data", "var_coeffs"], "symbolic_outputs": ["var_filtered_data"], "description": "Processing sensor data using an FIR filter" }, { "node_id": "node_3", "primitive_id": "CMP_GT_I32", "symbolic_inputs": ["var_filtered_data", "var_threshold"], "symbolic_outputs": ["var_alarm_flag"], "description": "Detects whether the filtered data exceeds the threshold" } ], "edges": [ {"from": "node_1", "to": "node_2", "data_flow": {"var_sensor_data": "input_0"}}, {"from": "node_2", "to": "node_3", "data_flow": {"var_filtered_data": "input_0"}} ] } } The code above defines a structured computation task graph (TaskGraph / Data Flow Graph) generated by a large language model (LLM), which is a standard data interface connecting high-level natural language intents with low-level executable instructions (or hardware signals).

[0089] The code structure forms a directed acyclic graph (DAG), which mainly consists of two parts: 1. Node set (nodes: Defines three atomic operation primitives that are executed sequentially, including ADC data acquisition (ADC_READ_SINGLE), FIR filtering (FIR_FILTER_I32), and threshold comparison alarm (CMP_GT_I32). Each node uses "symbolic variables" (such as var_sensor_data) as data placeholders, which not only achieves decoupling but also reserves optimization space for subsequent physical register allocation by the underlying compiler.

[0090] 2. Edges: Accurately map the data flow and temporal dependencies between these three primitive nodes, clarifying how upstream outputs serve as downstream inputs.

[0091] Overall, this code deterministically transforms the unstructured "data reading -> filtering -> alarm" pipeline task into a symbolic topology that can be directly parsed by the underlying neural compiler. It effectively shields the complexity of the physical hardware and serves as the core data carrier for achieving automated hardware-software co-compilation.

[0092] Constraints: Physical register names are prohibited in the LLM output. The output must not contain physical register names such as a0, t1, s0, etc. Symbolic variable naming conventions: All symbolic variables must begin with var_ for easier subsequent parsing; For data flow integrity, the input symbolic variables of each node must come from the output of the preceding node or be the initial input.

[0093] Technical effect: Through this constraint, even if the LLM experiences "illusions" (such as generating incorrect register names), it will not affect the subsequent deterministic code synthesis stage, because all physical resource allocation is handled by the backend algorithm.

[0094] Example 3: Global Register Allocation and Code Synthesis in a Deterministic Backend This embodiment describes how a deterministic backend receives the Abstract Task Graph (ATG) and generates highly optimized machine code through global register allocation. For example... Figure 5 As shown, the process comprises four core stages.

[0095] 3.1 Phase 1: Global Control Flow and Activity Analysis Input: Abstract Task Graph (ATG) + SAAL metadata Step 1: Control Flow Graph (CFG) Construction. Based on the node execution order and branching logic of the ATG, construct the control flow graph. For task graphs containing conditional branches (such as if-else structures), the CFG will contain multiple basic blocks.

[0096] Step 2: Symbolic variable activity analysis. For each symbolic variable, calculate its lifespan interval, which is the position of the variable's first definition and last use in the code.

[0097] Example: Suppose the symbolic variable var_sensor_data is defined on node 1 and used on nodes 2 and 3, then its lifetime is [node_1, node_3].

[0098] Step 3: Interference Graph Construction If the lifetimes of two symbolic variables overlap (i.e., both are "alive" at some point), an edge is added to the interference graph to indicate that they cannot be assigned to the same physical register.

[0099] Technical details: This invention employs the classic "graph coloring" algorithm for register allocation. If the interferogram can be colored with K colors (K being the number of available registers), then all symbolic variables can be allocated to registers; otherwise, some variables need to spill into memory.

[0100] 3.2 Phase Two: Zero-Copy Register Forwarding Optimization like Figure 5 As shown, the deterministic backend performs zero-copy optimization during the register allocation phase.

[0101] Optimization strategy: Condition 1: The data path has a direct data dependency between the output symbolic variable var_A of the preceding node and the input symbolic variable var_B of the following node (i.e., there is an edge A -> B in the ATG).

[0102] Condition 2: The register is not contaminated between node A and node B, and no intermediate node modifies (contaminates) the physical register carrying var_A.

[0103] Optimization operation: If the above two conditions are met, var_A and var_B will be allocated to the same physical register (e.g., a0), and subsequent nodes will directly reuse the value of this register, skipping the load instruction.

[0104] Example: Before optimization: # Node 1: ADC Readout li t0, 0x40000000 # ADC register address a0, 0(t0) # Read ADC data into a0 sw a0, 0(sp) # Save a0 to the stack (var_sensor_data) # Node 2: FIR Filter lw a1, 0(sp) # Load var_sensor_data from the stack into a # ... Filtering calculation... Optimized (zero copy): # Node 1: ADC Readout lii t0, 0x40000000 # ADC register address lw a0, 0(t0) # Read ADC data into a0 # Node 2: FIR Filter # (Use a0 directly, skip loading instructions) # ... Filtering calculation (input is a0)... Performance gains: Reduce two memory access instructions (sw and lw); Reduce memory bus power consumption; Improve data locality and increase cache hit rate.

[0105] Actual test data: In the "intelligent sensing" workload, zero-copy optimization eliminates about 40% of Load / Store instructions, and reduces energy consumption per task execution by about 25%.

[0106] 3.3 Phase Three: Generation of the Minimal Context Switching Set (Cmin) Background: Traditional RTOS saves all the callee's save registers (such as s0-s11 in RISC-V) during task switching, which introduces a lot of redundant operations.

[0107] Optimization strategy: This invention dynamically generates a minimum context switching set by analyzing the actual register usage of a task.

[0108] Calculation formula: Cmin** = Ctotal ∩ C**ABI in: Ctotal: The union of the polluted register lists of all atomic primitives in the entire task flow; CABI: The set of callee saved registers specified by the target architecture ABI.

[0109] Example: Assume the task flow contains three primitives: Primitive 1 pollutes the register: {t0, t1, a0} Primitive 2 pollutes the register: {t2, s0, a1} Primitive 3 pollutes the register: {t0, s1} but: Ctotal = {t0, t1, t2, a0, a1, s0, s1} CABI (RISC-V) = {s0, s1, s2, ..., s11, ra} Cmin = {s0, s1} Generated context switching code: Entry (Save): task_entry: addi sp, sp, -8 # Allocate only 8 bytes of stack space (to store 2 registers) s0, 0(sp) # Save s0 s1, 4(sp) # Save s1 # ... Task execution... Exports (Resumption): task_exit: s0, 0(sp) # Restore s0 s1, 4(sp) # Restore s1 addi sp, sp, 8 # Release stack space ret Performance gains: Compared to traditional RTOS that save all 12 S registers, this only saves 2 registers; Reduce 20 instructions (10 sw instructions + 10 lw instructions); Context switching latency was reduced from approximately 12 μs to approximately 3 μs, a reduction of 75%.

[0110] Real-world test data: In the "secure communication" workload, this optimization reduced context switching overhead from 18% to 4% of total execution time.

[0111] 3.4 Phase Four: Code Generation and ELF File Packaging Step 1: Assembly code generation. Based on the register allocation results, replace the placeholders (such as ${out_reg}) in the assembly instruction body of each atomic primitive with the actual allocated physical registers.

[0112] Example: Primitive template: add ${out_reg}, ${in_reg1}, ${in_reg2} Register allocation: out_reg=a0, in_reg1=a1, in_reg2=a2 Generated code: add a0, a1, a2 Step 2: Instruction Assembly and Optimization. Assemble the assembly code of all nodes according to the CFG order and perform the following post-processing optimizations: Redundant instruction elimination: Remove invalid nop instructions or duplicate register transfer instructions (such as consecutive mv a0,a0). Instruction scheduling: Reordering instructions without changing their semantics to reduce pipeline stalls.

[0113] Step 3: ELF File Packaging. The generated machine code is packaged into an ELF format file conforming to the target architecture, including: Code segment (.text): Executable machine instructions; Data segment (.data / .bss): Global variables and uninitialized data; Symbol table (.symtab): Symbol information used for debugging and linking.

[0114] Step 4: Binary Optimization (Optional) Perform further optimizations on the generated ELF file, such as: Code compression: Reduce code size using Thumb-2 (ARM) or RVC (RISC-V compression instruction set); Constant pool merging: Merges identical constants into a single copy.

[0115] Example 4: Verification of the pipeline and actual performance testing This embodiment describes how to ensure the security and functional correctness of generated code through a multi-level verification pipeline. For example... Figure 6 As shown, the verification pipeline consists of two independent stages.

[0116] 4.1 Phase 1: Static Constraint Check Objective: To detect potential errors, including register usage violations and memory access violations, through static analysis before code execution.

[0117] Inspection rules: Rule 1: Register usage compliance checks verify that the registers actually modified by each atomic primitive are fully included in the pollution list of its metadata declaration.

[0118] Implementation method: Use static analysis tools (such as LLVM-based disassemblers) to parse the generated machine code, extract the registers modified by each instruction, and compare them with SAAL metadata.

[0119] Example: If the metadata declaration of the primitive ADD_I32 has a pollution list of [] (no pollution), but the generated code contains add t0, a1, a2 (modifying t0), the inspector will report an error: Error: Primitive 'ADD_I32' at node_2 violated register contract. Expected clobbered: [] Actual clobbered: [t0] Rule 2: Memory access boundary checks verify that the target addresses of all memory load and store instructions are within the legal memory regions.

[0120] Implementation method: Add an assertion to each memory access instruction to check at runtime whether the address is within the predefined boundary (e.g., SRAM address range: 0x20000000 - 0x20010000).

[0121] Rule 3: Data flow integrity check verifies whether the read / write dependencies of each symbolic variable are consistent with the data flow defined in the abstract task graph after the physical register is allocated.

[0122] Implementation method: Construct the data flow graph of the actual code, compare it with ATG for graph isomorphism, and detect whether there is illegal data overwriting or undefined use.

[0123] 4.2 Phase Two: Dynamic Difference Test Objective: To ensure functional correctness by comparing the consistency of states between a reference model (instruction set simulator) and the object under test (target hardware or cycle-accurate simulator) by executing the same test vectors in parallel.

[0124] like Figure 6 As shown, the differential testing procedure is as follows: Step 1: The test vector generation system generates multiple sets of test vectors, covering the following scenarios: Boundary value testing: Testing the maximum, minimum, and zero values ​​of the input data; Random testing: A large number of random inputs are generated using a pseudo-random number generator, covering a wide range of numerical values; Targeted testing: Generate targeted input based on the control flow branches of the code to ensure that all code paths are executed at least once.

[0125] Example: For the "intelligent sensing" task, test vectors might include: { "test_vector_1": {"adc_input": 0, "threshold": 100}, "test_vector_2": {"adc_input": 4095, "threshold": 100}, "test_vector_3": {"adc_input": 2048, "threshold": 2048}, "test_vector_random_1": {"adc_input": 1537, "threshold": 892}, ... } Step 2: Parallel execution loads the generated microkernel code into two execution environments: Reference Model (ISS): Instruction set simulators (such as QEMU and Spike) provide a "Golden Reference". Object under test (DUT): Target physical hardware (such as ESP32-C3) or periodic precision simulator.

[0126] For each set of test vectors, the microkernel code is executed in parallel in both environments.

[0127] Step 3: State Comparison After execution, the system compares the architectural states of the two systems, including: General purpose registers: a0-a7, t0-t6, s0-s11, ra, sp, etc.; Control Status Registers (CSRs): mepc, mstatus, mcause, etc.; Memory contents: The contents of the data segment (.data) and the stack (.stack).

[0128] Step 4: Verification and Reporting. If the two states are completely consistent, the verification is successful; otherwise, the system outputs a detailed difference report. Differential Test FAILED for test_vector_5: Register Mismatch: - a0: Expected 0x000012AB, Got 0x000012AC - t1: Expected 0x00000000, Got 0x00000001 Memory Mismatch: - Address 0x20000100: Expected 0x42, Got 0x43 Technical safeguards: Through differential testing, this invention can capture all functional errors before deployment, including: Data overwriting caused by register allocation error; A control flow error caused a jump target error; Illegal read / write caused by a memory access error.

[0129] 4.3 Actual Performance and Energy Consumption Data This embodiment provides complete experimental data on a real hardware platform to demonstrate the beneficial effects of the present invention.

[0130] Experimental environment: Hardware platform: ESP32-C3 development board Processor: RISC-V RV32IMC single-core, 160MHz Memory: 400KB SRAM, 4MB Flash Power consumption measurement: Nordic PPK2 power analyzer (sampling rate 100kHz) Baselines: Baseline A (Bare-metal C code, no optimization): Compiled using GCC v13.2.0, optimization level -O0. Baseline B (Highly optimized C code): Compiled using GCC v13.2.0, optimization level -O3, with `-flto -fomit-frame-pointer` and manual loop unrolling and inlining optimizations. Baseline C (FreeRTOS): Running FreeRTOS v10.5.1 real-time operating system, using standard preemptive scheduling (100Hz Tick). Test workloads: W1 (Smart Sensing): Simulates the typical IoT control flow of "ADC sampling → FIR filtering → threshold detection".

[0131] ADC sampling: Read data from 10 channels of a 12-bit ADC; FIR filtering: Data is processed using an 8th-order FIR filter; Threshold detection: Compare the filtering result with the preset threshold and trigger an alarm.

[0132] W2 (Secure Communication): A communication protocol stack that executes "data packaging → CRC32 checksum → XOR encryption".

[0133] Data Packaging: Pack the data from the 8 sensors into a 128-byte data packet; CRC32 checksum: Calculates the CRC32 checksum of the data packet; XOR encryption: Encrypts data packets using an XOR key.

[0134] W3 (Feature Extraction): Performs statistical feature extraction by performing "data normalization → mean calculation → variance calculation".

[0135] Data normalization: Mapping 100 original data points to the interval [0, 1]; Mean calculation: Calculate the mean of normalized data; Variance calculation: Calculate the variance of normalized data.

[0136] The performance improvement (number of instructions and execution time) is shown in Table 1: Table 1

[0137] Cause analysis: W1 benefits the most: This workload involves a large number of memory access operations (ADC read, filter coefficient loading), and zero-copy register forwarding optimization eliminates approximately 40% of Load / Store instructions.

[0138] W2 benefits are relatively small: This workload is computationally intensive (CRC32 calculation involves a large number of bit operations), and the optimization space is relatively limited. The main benefit comes from minimal context switching.

[0139] W3 benefits moderately: The workload is memory intensive (batch processing of 100 data points), and the deterministic backend-generated code forces the use of a register pair loading strategy, improving spatial locality.

[0140] The energy consumption reduction effect is shown in Table 2: Table 2

[0141] Cause analysis: The reduction in energy consumption is mainly due to two factors: 1. Reduced instruction count: Fewer instructions mean the CPU is active for a shorter period of time; 2. Reduced memory access: Load / Store operations consume approximately 10-20 times more energy than register operations, and zero-copy optimization significantly reduces memory bus power consumption.

[0142] Practical application value: Assuming an IoT sensor node performs 10,000 "smart sensing" tasks per day: Baseline B: Daily energy consumption approximately 452 mJ → Approximately 3,311 days (about 9 years) with a 500mAh button cell battery (3.0V, 1.5Wh). DNS-OS: Daily energy consumption approximately 178 mJ → Can operate for approximately 8,427 days (approximately 23 years). Conclusion: This invention can extend battery life by approximately 2.5 times, which has significant commercial value for deployment in remote areas or difficult-to-maintain scenarios (such as field environmental monitoring and underground pipeline monitoring).

[0143] Resource usage optimization is shown in Table 3: Table 3

[0144] Cause analysis: 1. The microkernel generated by this invention does not require the C runtime library (CRT) or dynamic heap manager (HeapManager). 2. The minimum context switching strategy reduces stack space requirements; 3. Zero-copy optimization reduces the storage requirements for temporary variables.

[0145] Application value: The significant reduction in code segment size enables this invention to be deployed on extremely low-cost MCUs (such as MCUs equipped with only 16KB Flash), further reducing hardware costs.

[0146] The above embodiments are used to explain and illustrate the present invention, but not to limit the present invention. Any modifications and changes made to the present invention within the spirit and scope of the claims shall fall within the protection scope of the present invention.

Claims

1. An embedded microkernel generation method based on semantic parsing and a deterministic backend, characterized in that, Includes the following steps: S1: Construct a standard atomic assembly library: Pre-build and store a database containing multiple atomic primitives, wherein the atomic primitives contain assembly instruction bodies and semantic metadata describing their hardware behavior, wherein the semantic metadata includes at least an input interface register list, an output interface register list, and a temporary register list that is polluted during execution; S2: Intent parsing and task decomposition: Obtain the natural language task instructions input by the user, and use the semantic parsing module based on the pre-trained large language model to extract and map the features of the natural language task instructions to generate an abstract task graph; the abstract task graph is a directed acyclic graph data structure, where nodes represent computational tasks and edges represent data dependencies, and the data flow in the abstract task graph is represented by symbolic variables and does not contain physical register allocation information. S3: Primitive matching: Based on the functional constraints and input / output symbolic variable constraints of each node in the abstract task graph, retrieve the candidate atomic primitives and their corresponding semantic metadata that match them from the standard atomic assembly library; S4: Deterministic code synthesis: The retrieved candidate atomic primitives and their semantic metadata are input into the deterministic algorithm backend. The deterministic algorithm backend performs global control flow and data flow analysis, and performs physical register allocation according to the interface constraints and pollution list in the semantic metadata, so that the generated code meets the constraints of the target processor instruction set architecture, register set and calling convention, and outputs microkernel target code or bare-metal binary for execution by the target processor. S5: Static compliance check: Perform static constraint checks on the microkernel target code or bare-metal binary, including at least register usage compliance checks and calling convention consistency checks; if the checks fail, refuse to output or return to the deterministic algorithm backend for resynthesis.

2. The method according to claim 1, characterized in that, The deterministic code synthesis described in step S4 includes zero-copy register forwarding processing: analyzing the data dependencies between adjacent preceding and succeeding task nodes in the abstract task graph; if it is determined that there is a direct data path between the output symbolic variable of the preceding task node and the input symbolic variable of the succeeding task node, and the physical register carrying the data does not belong to the polluted register list of any executed atomic primitive between the two nodes; then the physical register is locked, and when generating the code of the succeeding task node, the data loading instruction is skipped, and the register value of the preceding task node is directly reused to achieve register-level data forwarding.

3. The method according to claim 1, characterized in that, The deterministic code synthesis described in step S4 also includes the generation of the minimum context switching set Cmin: Scan all called atomic primitives in the entire task flow, extract the register pollution list from their semantic metadata, and calculate their union to obtain the full pollution set Ctotal; Obtain the callee saved register set CABI as defined in the Application Binary Interface (ABI) specification of the target hardware architecture; Calculate the intersection of the full contamination set and the set of callee saved registers to obtain the minimum context switching set: Cmin = Ctotal ∩ CABI; At the entry and exit points of the generated microkernel, only instruction sequences for saving and restoring the registers in the minimum context switching set are generated, eliminating redundant register saving operations that are forcibly generated by traditional compilers.

4. The method according to claim 1, characterized in that, In step S1, the standard atomic assembly library supports a hybrid synthesis extension mechanism: Receive user input of custom high-level language code snippets; The compiler is invoked to compile the code snippet into assembly code; The assembly code's input / output register dependencies and register usage are automatically extracted through static analysis, generating corresponding semantic metadata. The assembly code and its semantic metadata are encapsulated into user-defined primitives and added to the standard atomic assembly library so that they can participate in the global register allocation process in step S4.

5. The method according to claim 1, characterized in that, The physical register allocation algorithm used in the deterministic algorithm backend is selected from one or more of the following: graph coloring, linear scan, or optimization allocation algorithm based on integer linear programming (ILP). Under the same conditions of standard atomic assembler library version, deterministic algorithm backend parameter configuration and target hardware architecture constraints, the deterministic algorithm backend generates the same physical register allocation scheme and machine code output for the same abstract task graph input, ensuring the reproducibility of the system.

6. The method according to claim 1, characterized in that, It also includes a verification pipeline step, which is executed after step S4, including: Static constraint check: Scan the generated microkernel machine code and check whether the register operations of each instruction exceed the scope of the interface and pollution list declared in the semantic metadata. If a violation is detected, the generation will be rejected and an error will be reported. Differential testing: The generated microkernel machine code is executed in parallel on the instruction set simulator and the target physical hardware with the same input vector. The consistency of the architecture status register values ​​and memory side effects of the two is compared. The verification is considered successful only when the two are completely consistent.

7. The method according to claim 6, characterized in that, The differential test further includes: Multiple sets of test vectors are randomly generated to cover the boundary conditions and typical working scenarios of the microkernel; For each set of test vectors, the generated microkernel code is executed on both the instruction set simulator and the target hardware. The execution trajectory is compared instruction by instruction, and snapshots of the general-purpose registers, control status registers (CSR), and memory states are recorded. If any inconsistency is found, a detailed discrepancy report is output, including the inconsistent register number, expected value and actual value, and the verification process is terminated.

8. An embedded microkernel generation system that implements the embedded microkernel generation method based on semantic parsing and deterministic backend as described in any one of claims 1-7, characterized in that, include: Knowledge base subsystem: used to store the standard atomic assembly library SAAL and a vector database that supports semantic retrieval. The vector database pre-embeds and encodes the functional description of each atomic primitive to support efficient semantic similarity retrieval. Semantic parsing subsystem: Used to run the semantic parser, receive task intent descriptions input by the user in natural language or pseudocode form, and output a structured abstract task graph (ATG); Deterministic synthesis subsystem: used to execute global activity analysis and physical register allocation algorithms, realize zero-copy register forwarding optimization and minimal context switching code generation, and finally output the microkernel binary file of the target architecture; Verification subsystem: Used to perform static constraint checks and dynamic differential tests on the generated microkernel code to ensure the security and functional correctness of the code.

9. The system according to claim 8, characterized in that, The semantic parsing subsystem further includes: Intent understanding module: Uses a large language model to perform semantic parsing of user input and extract high-level functional requirements of the task; Primitive matching module: Through retrieval enhancement generation RAG technology, it retrieves a set of candidate atomic primitives from the standard atomic assembly library that are most semantically similar to the task nodes; Task graph construction module: Based on the data dependencies of the tasks, construct an abstract task graph with a directed acyclic graph structure, and assign symbolic input and output variables to each node.

10. The system according to claim 8, characterized in that, The deterministic synthesis subsystem adopts a multi-stage pipeline architecture, including: Control flow analysis phase: Analyze the execution order of nodes and branch jump logic in the abstract task graph; Activity analysis phase: Calculate the lifetime range of each symbolic variable and determine its first definition and last use in the code; Register allocation phase: Allocate physical registers for each symbolic variable and employ a register overflow strategy when the lifetimes of symbolic variables overlap; Code generation stage: Based on the register allocation results, the assembly instruction bodies of the atomic primitives are concatenated and necessary register transfer instructions are inserted to finally generate a complete machine code sequence.

Images