Signal processing methods for heterogeneous user instruction sets

Abstract

This invention discloses a signal processing method for heterogeneous user instruction sets. By identifying and marking the process instruction set architecture type during the process loading phase in user mode, and if the user-mode program is interrupted or triggers an exception and enters kernel mode, the process instruction set architecture type is determined for the first time through a flag bit in a created cross-mode privileged service context translation intermediate layer. If it is a RISC-V process, the user program context is saved and a runtime environment is created according to RISC-V specifications; if it is an AArch64 process, the user program context is saved and a runtime environment is created according to AArch64 specifications. This invention achieves user-invisible cross-instruction set binary compatibility execution and operating system-level execution flow security.

Description

Technical Field

[0001] This invention relates to the field of computer operating system technology, and in particular discloses a signal processing method for heterogeneous user instruction sets. Background Technology

[0002] ARM and RISC-V are two independent instruction set architectures. With the trend towards independent control over instruction set architectures and reduced licensing restrictions, the RISC-V architecture exhibits significant advantages in terms of instruction set freedom and hardware customization.

[0003] However, the ARM architecture, with its mature commercial ecosystem and widespread market share, dominates in mobile computing, embedded systems, and other fields. Its rich software ecosystem and highly optimized toolchain provide developers with a seamless development experience. This makes it difficult for the RISC-V architecture to fully replace the ARM architecture in the short term in terms of software ecosystem completeness and industry adaptability.

[0004] During this transition phase, many technologies have emerged to address software ecosystem compatibility issues. Single instruction set architecture solutions mainly include binary translation, static recompilation, and hardware virtualization acceleration.

[0005] The core principle of binary translation technology is to convert the binary code of the target instruction set into executable code of the native instruction set line by line at runtime. Its advantage is that legacy programs can be run without modifying the source code. Its disadvantages include the high performance loss caused by real-time translation, insufficient support for complex instruction extensions, and difficulty in ensuring the performance of application scenarios with strict real-time requirements.

[0006] Static recompilation technology refers to the technology of converting binary source code into the target platform instruction set before the program runs. Its advantages are that the code generation efficiency is close to that of the native program, and no real-time conversion is required. It is suitable for resource-constrained embedded systems or scenarios with high real-time requirements. At the same time, the pre-compilation stage can detect code vulnerabilities in advance, which is more secure. Its disadvantages are that the cost of cross-architecture migration is high and special complex instructions cannot be translated.

[0007] Hardware virtualization acceleration technology refers to improving virtualization performance through dedicated hardware modules, enabling the efficient operation of multiple architecture virtual machines or containers on the same physical machine. Its advantage is that there is almost no performance loss, and multiple architectures can be supported in parallel. Its disadvantage is that it has a high hardware dependency, high cost, and does not meet the requirements of hardware autonomy and controllability.

[0008] Therefore, the aforementioned defects in existing instruction set architecture methods are technical problems that urgently need to be solved. Summary of the Invention

[0009] This invention provides a signal processing method for heterogeneous user instruction sets, aiming to solve at least one of the aforementioned defects in existing instruction set architecture methods.

[0010] This invention relates to a signal processing method for heterogeneous user instruction sets, comprising the following steps:

[0011] During the process loading phase in user space, the process instruction set architecture type is identified and marked. The process instruction set architecture types include ARM64 instruction set and RV64G instruction set.

[0012] When a process executes a user-mode program, if the user-mode program is interrupted or triggers an exception and enters kernel mode, the process instruction set architecture type is determined for the first time by a flag bit in the created cross-mode privileged service context translation intermediate layer. The ARM64 instruction set corresponds to the AArch64 process, and the RV64G instruction set corresponds to the RISC-V process.

[0013] If it is a RISC-V process, the context of the user program is saved and the runtime environment is created according to the RISC-V specification; if it is an AArch64 process, the context of the user program is saved and the runtime environment is created according to the AArch64 specification.

[0014] Furthermore, if it is a RISC-V process, the user program context is saved and a runtime environment is created according to RISC-V specifications; if it is an AArch64 process, the steps of saving the user program context and creating a runtime environment according to AArch64 specifications are followed by:

[0015] Perform kernel services in the created runtime environment;

[0016] Preparing to return to user mode;

[0017] Determine if there is a signal to be processed;

[0018] If so, save the user program's context to the user stack;

[0019] In the initial intermediate layer of the created trans-state transparent signal context, the process instruction set architecture type is determined a second time by using flag bits;

[0020] If it is a RISC-V process, the signal handling function execution context is created according to the RISC-V specification, and the RISC-V signal handling program is executed; if it is an AArch64 process, the signal handling function execution context is created according to the AArch64 specification, and the AArch64 signal handling program is executed.

[0021] The vDSO mechanism allows for quick return to kernel mode from the jump function entry point.

[0022] Furthermore, after determining whether there is a signal to be processed, the process also includes:

[0023] If not, the process instruction set architecture type is determined a third time by using a flag bit in the created cross-state privileged service context translation intermediate layer;

[0024] If it is a RISC-V process, the original user program's context is restored and a running environment is created according to the RISC-V specifications; if it is an AArch64 process, the original user program's context is restored and a running environment is created according to the AArch64 specifications.

[0025] Furthermore, in the step of identifying and marking the process instruction set architecture type during the process loading phase in user mode, according to the principle of single instruction set process, the process instruction set architecture type is implemented based on the reserved bit field bit[5:0] of the processor status register pstate of the ARM64 architecture.

[0026] Furthermore, in the step of identifying and marking the process instruction set architecture type during the process loading phase in user mode, based on the principle of shared ARM64 basic services, a shared process lifecycle management is proposed, and support for loading RV64G executable ELF files is added.

[0027] Furthermore, in the step of identifying and marking the process instruction set architecture type during the process loading phase in user mode, the operating system parses the e_machine field in the header of the ELF executable file. If it is EM_RISCV, the flag PSR_MODE_ARMRV_EL0t (0x00000020) is set in the pstate register; if it is EM_AARCH64, the default value is retained.

[0028] Furthermore, when a process executes a user-mode program, if the user-mode program is interrupted or triggers an exception and enters kernel mode, the kernel reads the pstate value through the pt_regs structure, extracts the flag bit to dynamically identify the current instruction set type, and executes the corresponding architecture processing behavior in the step of first determining the process instruction set architecture type through the step of the cross-mode privileged service context translation intermediate layer.

[0029] Furthermore, if a process executes a user-mode program and is interrupted or triggers an exception, resulting in a kernel-mode transition, the steps for initially determining the process instruction set architecture type using a flag bit in the created cross-mode privileged service context translation intermediate layer include:

[0030] When a user-mode program triggers an exception and enters kernel mode, the current pstate value is automatically saved to the kernel's pt_regs structure;

[0031] The kernel extracts the instruction set type through bitwise operations. If the result is PSR_MODE_ARMRV_EL0t, it is determined to be a RISC-V process; otherwise, it is determined to be an AArch64 process.

[0032] Furthermore, if it is a RISC-V process, the context of the user program is saved and the runtime environment is created according to the RISC-V specification; if it is an AArch64 process, the steps of saving the context of the user program and creating the runtime environment according to the AArch64 specification are carried out by dynamically remapping the RISC-V system call parameters to the ARM64 core interface through pure software layer intermediate conversion logic, so as to achieve cross-instruction set semantic consistency of parameters and return values.

[0033] Furthermore, if it is a RISC-V process, the original user program's context is restored and a running environment is created according to the RISC-V specifications; if it is an AArch64 process, the original user program's context is restored and a running environment is created according to the AArch64 specifications. In this step, a signal processing running environment is constructed based on the differences in process instruction set types, enabling cross-instruction set signal processing programs to perform context restoration.

[0034] The beneficial effects achieved by this invention are as follows:

[0035] This invention provides a signal processing method for heterogeneous user instruction sets. By identifying and marking the process instruction set architecture type during the process loading phase in user mode, and if the user-mode program is interrupted or triggers an exception and enters kernel mode, the process instruction set architecture type is determined for the first time through a flag bit in a created cross-mode privileged service context switching intermediate layer. If it is a RISC-V process, the user program context is saved and a runtime environment is created according to RISC-V specifications; if it is an AArch64 process, the user program context is saved and a runtime environment is created according to AArch64 specifications. This signal processing method for heterogeneous user instruction sets solves the technical problems of software ecosystem compatibility between ARM and RISC-V, lack of instruction set type identification in signal processing under the ArmRV hybrid instruction set architecture, lack of runtime environment for RV64G instruction set processes, failure of cross-instruction set context switching, and lack of a signal processing runtime environment. It achieves user-insensitive cross-instruction set binary compatible execution and operating system-level execution flow security. Attached Figure Description

[0036] Figure 1 This is a schematic diagram illustrating the signal transmission and processing mechanism.

[0037] Figure 2 This is a schematic diagram of the signal processing flow of an embodiment of the signal processing method for heterogeneous user instruction sets of the present invention;

[0038] Figure 3 This is a schematic diagram of the context memory flow under the ARM64 instruction set architecture, which is an embodiment of the signal processing method for heterogeneous user instruction sets of the present invention.

[0039] Figure 4 This is a schematic diagram of the context storage flow under the RV64G instruction set architecture, which is an embodiment of the signal processing method for heterogeneous user instruction sets of the present invention. Detailed Implementation

[0040] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0041] like Figures 2 to 4 As shown, the first embodiment of the present invention proposes a signal processing method for heterogeneous user instruction sets, including the following steps:

[0042] Step S100: Identify and mark the process instruction set architecture type during the process loading phase in user mode. The process instruction set architecture type includes ARM64 instruction set and RV64G instruction set.

[0043] User mode is a low-privilege execution mode allocated by the operating system for ordinary applications. Processes running in this mode can only access limited system resources and cannot directly manipulate hardware or execute privileged instructions. This design ensures system stability through permission isolation and prevents accidental application operations from affecting core system functions.

[0044] The process loading phase is the crucial process by which the operating system converts an executable program into a running process.

[0045] The ARM64 (also known as AArch64) instruction set is a 64-bit instruction set architecture (ISA) introduced in ARMv8 and later architectures, designed specifically for high-performance computing.

[0046] The RV64G instruction set is the core instruction set in the RISC-V architecture for 64-bit general-purpose computing scenarios.

[0047] Step S200: The process executes a user-mode program. If the user-mode program is interrupted or triggers an exception and enters kernel mode, the process instruction set architecture type is determined for the first time in the created cross-mode privileged service context translation intermediate layer by a flag bit. The ARM64 instruction set corresponds to the AArch64 process, and the RV64G instruction set corresponds to the RISC-V process.

[0048] User-mode programs are applications that run in the user mode of the operating system.

[0049] Kernel mode is the privileged mode in which the operating system kernel runs, possessing the highest level of privileges. In this mode, the CPU can execute all instructions, directly access hardware devices (such as disks and network cards) and system resources (such as memory and I / O ports), and manage core functions such as process scheduling and memory allocation.

[0050] The cross-privileged service context translation intermediate layer is an intermediate logical layer that coordinates resource access and state switching between different privilege levels (such as user mode and kernel mode) in a computer system.

[0051] An AArch64 process refers to a program instance that runs in 64-bit mode on the ARMv8-A architecture, and its core characteristics are closely related to the architecture design.

[0052] A RISC-V process is a program execution instance based on the RISC-V instruction set architecture (ISA), and its core features are deeply tied to the open-source nature, modular design, and hierarchical privileged architecture of RISC-V.

[0053] Step S300: If it is a RISC-V process, the context of the user program is saved and a running environment is created according to the RISC-V specification; if it is an AArch64 process, the context of the user program is saved and a running environment is created according to the AArch64 specification.

[0054] Please see Figure 3 and Figure 4 RISC-V is an open standard instruction set architecture (ISA) designed based on the principles of Reduced Instruction Set Computing (RISC). AArch64 is the 64-bit execution mode of the ARMv8-A architecture, and its design specifications revolve around high performance, multi-level security isolation, and support for complex computations.

[0055] Further, please see Figures 2 to 4 The signal processing method for heterogeneous user instruction sets proposed in this embodiment further includes the following after step S300:

[0056] Step S410: Perform kernel services in the created runtime environment.

[0057] Step S420: Prepare to return to user mode.

[0058] Step S430: Determine if there is a signal to be processed.

[0059] Step S440: If yes, save the context of the user program to the user stack.

[0060] The user stack is a dynamic memory area used by user-mode processes during runtime to support function calls, local variable storage, and program execution flow management.

[0061] Step S450: In the initial intermediate layer of the created cross-state transparent signal context, the process instruction set architecture type is determined for the second time by the flag bit.

[0062] The Transparent Signal Context Initialization Intermediate Layer is a core component in distributed system architecture, designed to achieve transparency in signal transmission and processing across different states, protocols, or environments.

[0063] Step S460: If it is a RISC-V process, then create a signal processing function execution context according to the RISC-V specifications and execute the RISC-V signal processing program; if it is an AArch64 process, then create a signal processing function execution context according to the AArch64 specifications and execute the AArch64 signal processing program.

[0064] The execution context of a signal handling function refers to the execution context of the process when the signal is triggered, including register states, memory layout, and runtime environment information.

[0065] RISC-V signal processing programs are software modules based on the RV64G instruction set, used to respond to asynchronous events (such as synchronous signals, asynchronous signals, and uncatchable signals) triggered by the operating system or hardware.

[0066] The AArch64 signal handler is a software module based on the ARM64 instruction set, used to respond to asynchronous events (such as synchronous signals, asynchronous signals, and uncatchable signals) triggered by the operating system or hardware.

[0067] Step S470: Use the vDSO mechanism jump function entry to quickly return to kernel mode.

[0068] The vDSO (virtual dynamic shared object) mechanism's jump function entry point is a specific code segment entry point dynamically mapped by the kernel to user space, used to replace the privilege level switching of traditional system calls.

[0069] Preferably, see details. Figures 2 to 4 The signal processing method for heterogeneous user instruction sets proposed in this embodiment further includes the following after step S430:

[0070] Step S480: If not, the process instruction set architecture type is determined for the third time by the flag bit in the created cross-state privileged service context translation intermediate layer.

[0071] The cross-mode privileged service context translation middleware is a key architectural component in the operating system, responsible for coordinating privilege level switching and execution context management between user mode and kernel mode.

[0072] Step S490: If it is a RISC-V process, restore the original user program's context and create a running environment according to the RISC-V specifications; if it is an AArch64 process, restore the original user program's context and create a running environment according to the AArch64 specifications.

[0073] Furthermore, the signal processing method for heterogeneous user instruction sets provided in this embodiment...

[0074] In step S100, according to the single instruction set process principle, the process instruction set architecture type is implemented based on the reserved bit field [5:0] of the processor status register pstate of the ARM64 architecture.

[0075] Furthermore, in step S100 of the signal processing method for heterogeneous user instruction sets provided in this embodiment, based on the principle of shared ARM64 basic services, a shared process lifecycle management is proposed, and support for loading RV64G executable ELF files is added.

[0076] Furthermore, in the signal processing method for heterogeneous user instruction sets provided in this embodiment, in step S100, the operating system parses the e_machine field in the header of the ELF executable file. If it is EM_RISCV, the flag PSR_MODE_ARMRV_EL0t (0x00000020) is set in the pstate register; if it is EM_AARCH64, the default value is retained.

[0077] Furthermore, in the signal processing method for heterogeneous user instruction sets provided in this embodiment, in step S200, the kernel reads the pstate value through the pt_regs structure, extracts the flag bit to dynamically identify the current instruction set type, and executes the corresponding architecture processing behavior.

[0078] Furthermore, the signal processing method for heterogeneous user instruction sets provided in this embodiment includes step S200 as follows:

[0079] Step S210: When a user-mode program triggers an exception and enters kernel mode, the current pstate value is automatically saved to the kernel's pt_regs structure.

[0080] Step S220: The kernel extracts the instruction set type through bitwise operations. If the result is PSR_MODE_ARMRV_EL0t, it is determined to be a RISC-V process; otherwise, it is determined to be an AArch64 process.

[0081] Furthermore, in the signal processing method for heterogeneous user instruction sets provided in this embodiment, in step S300, the RISC-V system call parameters are dynamically remapped to the ARM64 core interface through pure software layer intermediate conversion logic, thereby achieving cross-instruction set semantic consistency between parameters and return values.

[0082] Furthermore, in the signal processing method for heterogeneous user instruction sets provided in this embodiment, step S490 involves constructing a signal processing runtime environment based on the differences in process instruction set types, thereby enabling cross-instruction set signal processing programs to perform context recovery.

[0083] like Figures 1 to 4 As shown in the figure, the signal processing method for heterogeneous user instruction sets provided in this embodiment works as follows:

[0084] With the rise of open instruction sets such as RISC-V, the collaborative design of hybrid instruction set architectures is gradually becoming a new direction for breaking through ecosystem barriers. Hybrid instruction set architecture processors achieve seamless scheduling and resource isolation across instruction set processes by integrating ARM and RISC-V instruction sets at the hardware level and combining them with operating system-level dynamic context management mechanisms. This approach balances ecosystem compatibility and the need for independent control, while exhibiting minimal performance loss, providing a more flexible technological foundation for the long-term evolution of heterogeneous computing platforms.

[0085] Based on the above ideas, a processor system based on a hybrid instruction set architecture of RV64G and ARM64 was designed and developed, and this hybrid instruction set architecture, which is compatible with the RV64G user-space instruction set of ARM64, was named the ArmRV instruction set architecture. The goal of this architecture is to achieve cross-platform compatible execution of binary applications, that is, users can run old programs of ARM and RISC-V on the ArmRV processor without modifying the code. The architecture only supports the ARM64 instruction set in the privileged states of EL1-EL3, and supports both ARM64 and RV64G instruction sets in the user state of EL0. Its core design principles are (1) deep integration of the RV64G instruction set architecture and the ARM64 instruction set architecture; (2) achieving compatibility with the two instruction set architectures with a small execution pipeline hardware overhead, including a smaller processor hardware area, lower power consumption, and lower timing complexity.

[0086] Based on the above design principles, the ArmRV instruction set architecture systematically achieves cross-architecture compatibility of binary programs through three core technologies: decoder decoupling, execution pipeline operator reuse, and register file dynamic mapping. Specifically, the decoder decoupling technology pre-decodes ARM64 and RV64G instructions into a unified intermediate format, allowing subsequent reuse of the same decoder and execution unit, reducing redundant design. The execution pipeline operator reuse technology allows 92% of RV64G instructions to reuse basic ARM64 instruction operators, implementing only a small number of independent operators, avoiding the need to independently implement all functional units for both instruction sets. The register file dynamic mapping technology allows RV64G and ARM64 to share and reuse physical registers, reducing the number of register file ports and the total number of physical registers. Regarding execution state switching, the ArmRV processor internally uses PSTATE[5:0] to identify execution state, exception level, and other information, while also supporting the handling of newly added illegal return exceptions. The above technologies keep the processor hardware area increase below 5%, and the performance measured by the SPEC CPU2006 standard test program is no less than 12 points / GHz, which well meets the core design principles.

[0087] To achieve binary compatibility and hot-switching of these two instruction sets on the new platform, operating system adaptation for the ArmRV instruction set architecture is required. This necessitates consideration of process lifecycle management support, system call / exception services, and signal handling. Signals are an asynchronous event notification mechanism, encompassing aspects such as... Figure 1 The three steps shown are: signal generation, signal storage, and signal processing. Signals are initially generated by four reasons: keyboard input, system calls, software conditions, and hardware exceptions. The kernel determines the cause and stores the relevant information in the target process's pending signal table. When the target process finishes executing a kernel service and returns from kernel mode to user mode, it checks for any existing signals. If a signal is found, it is processed. Signal processing can take three forms: default processing, custom processing, and ignoring the signal.

[0088] This invention discloses a signal processing method for heterogeneous user instruction sets. Through dynamic context switching and ABI transparent adaptation, it achieves user-invisible cross-instruction set binary compatibility execution. This invention supports the mixed execution of ARM64 and RISC-V user-mode programs without modifying application source code or binary files, and ensures cross-instruction set consistency in signal processing execution environment construction and context recovery processes, providing operating system-level signal processing integrity guarantees for heterogeneous processors. Based on the ArmRV instruction set architecture's characteristic of supporting only the ARM64 instruction set in EL1-EL3 privileged states and simultaneously supporting both ARM64 and RV64G instruction sets in EL0 user state, a key issue in cross-instruction set binary file compatibility execution is that RV64G applications lack RV64G kernel service support. To achieve mixed execution of programs from both instruction sets, RV64G applications need to reuse ARM64 kernel services. Based on this design, the semantic issues of context passing during cross-state switching between RV64G user programs and ARM64 kernel services need to be considered, i.e., dynamic register translation is required. Analyzing the aforementioned signal generation, storage, and processing steps, register semantic issues arise during signal generation and signal processing. When a signal is generated via a system call, the RV64G's binary program prepares the corresponding parameters, enters the kernel, and calls the ARM64 kernel service, a process involving register translation. When a signal is handled in a custom manner, such as... Figure 2 As shown, the timing for signal recognition and processing is before returning from kernel services. Before this, it is necessary to support ② context switching into the kernel, which is consistent with the adaptation requirements of the signal generation stage. Processing signals requires returning to user mode to execute a custom signal handler, which requires ③ creating a context environment for signal handlers with different instruction sets. After executing the signal handler, and quickly returning to kernel mode using the vDSO mechanism, it is necessary to check the process instruction set type and then restore the user program execution environment for the process. In addition to judging the process instruction set type and supporting RV64G application lifecycle management, the key problems in achieving signal processing under the ArmRV architecture can be summarized into the following four:

[0089] (1) Lack of instruction set architecture identification: When the signal is triggered, the operating system cannot dynamically determine the process instruction set type of the current execution flow, resulting in incorrect register storage or incompatible format.

[0090] (2) Lack of runtime environment for RV64G instruction set processes: Operating systems for ARM64 instruction set applications do not support lifecycle management of RV64G instruction set applications.

[0091] (3) Cross-state context switching failure: When the RV64G user program and the ARM64 kernel processor switch across states, the traditional context recovery mechanism cannot achieve transparent switching, causing the execution flow to crash.

[0092] (4) Insufficient signal stack compatibility: In a mixed instruction set environment, the user-mode-kernel-mode interaction required for signal processing needs to be adapted to the register semantic conventions of different instruction sets. Currently, the construction of the RV64G signal processing function runtime environment is not supported.

[0093] This invention designs a hybrid instruction set operating system based on the following two principles to solve the above four problems and achieve signal processing support in a hybrid instruction set operating system:

[0094] (1) Single instruction set process principle: A single process can only support running user-mode programs with a single instruction set. The signal processing function is strictly consistent with the instruction set type of the main program process. This principle is guaranteed by the premise of not modifying the user binary executable file. That is, only RISC-V signal processing programs are registered in RISC-V executable programs, and the same applies to ARM64.

[0095] (2) Principle of sharing ARM64 basic services: The kernel-mode services of this invention are supported by ARM64 instruction set programs. When designing a mixed instruction operating system, RV64 applications can share ARM64 basic services, which can reduce the amount of operating system development, reduce the complexity of the software system, and improve availability and system efficiency.

[0096] In summary, to solve the software ecosystem compatibility issues of RISC-V through ArmRV heterogeneous processors and mixed instruction operating system adaptation, it is crucial to support the mixed operation of ARM64 and RISC-V user-space programs without modifying application source code or binary files, and to ensure cross-instruction set consistency in signal capture, stack frame construction, and context recovery processes. Implementing a state labeling and cross-state context translation layer is also key.

[0097] The signal processing method and system for heterogeneous user instruction sets aim to solve the technical problems of missing instruction set type identification, missing runtime environment for RV64G instruction set processes, failure of cross-instruction set context switching, and missing signal processing runtime environment in signal processing under the ArmRV hybrid instruction set architecture, so as to achieve user-unobtrusive cross-instruction set binary compatible execution and operating system-level execution flow security.

[0098] One aspect of the present invention relates to a signal processing method for heterogeneous user instruction sets, comprising the following steps:

[0099] To address the problem of missing instruction set architecture identification (1), a dynamic identification and marking method for instruction set architecture is proposed: Based on the reserved bit field [5:0] of the pstate register of the ARM64 processor, the e_machine field of the ELF header of the executable file is parsed during the process loading stage to determine and solidify the instruction set type of the process as ARM64 or RV64G. Combined with the principle of single instruction set process (1), the instruction set architecture of the current process and its signal handler can be quickly, conveniently and with low overhead within the process life cycle, which is convenient for different processing.

[0100] To address the problem of missing runtime environment for RV64G instruction set processes (2), a shared process lifecycle management method is proposed based on principle (2) of sharing ARM64 basic services: adding support for loading RV64G executable ELF files, so that the operating system can load and schedule applications of two different instruction sets at the same time, providing lifecycle management for mixed instruction set processes.

[0101] To solve the problem of cross-state context switching failure (3), a cross-instruction set system call dynamic register mapping method is proposed: through pure software layer intermediate conversion logic, the RISC-V system call parameters are dynamically remapped to the ARM64 core interface to achieve cross-instruction set semantic consistency between parameters and return values. This lightweight approach can ensure that the cross-state service processing efficiency is close to the native performance.

[0102] To address the problem of insufficient signal stack compatibility (4), a dynamic management method for signal processing context is proposed: a signal processing runtime environment is constructed based on the differences in process instruction set types, and cross-instruction set signal processing program context recovery is realized, so as to achieve transparent support for mixed communication of two instruction sets based on the communication function library.

[0103] Furthermore, the steps of the instruction set architecture dynamic identification and tagging method include:

[0104] During the process loading phase, the process architecture type is identified and marked: The operating system parses the e_machine field in the header of the ELF executable file. If it is EM_RISCV, the flag PSR_MODE_ARMRV_EL0t (0x00000020) is set in the pstate register; if it is EM_AARCH64, the default value is retained.

[0105] In the signal processing flow, the architecture type is determined by flag bits: the kernel reads the pstate value through the pt_regs structure, extracts the flag bits to dynamically identify the current instruction set type, and executes the corresponding architecture processing behavior.

[0106] Furthermore, the steps of the shared process lifecycle management method include:

[0107] Added a check for RV64G executable files: When loading an executable file and checking whether the file's machine type is reasonable, logic was added to check if the EM_RISCV flag is valid.

[0108] Initialize the runtime environment: When initializing the runtime environment of the process for the RV64G file, set the program status register to PSR_MODE_ARMRV_EL0t.

[0109] Furthermore, the steps of cross-instruction set system call dynamic register mapping methods include:

[0110] Parameter remapping: When a RISC-V user program triggers a system call via ecall, the kernel dynamically maps the parameter registers x10-x16 to the kernel stack regs[0]-regs[6], and the system call number x17 is stored in the scno field to ensure the semantic consistency of registers during kernel code execution.

[0111] Return value adaptation: Based on the process instruction set type, the return value of the RISC-V system call is stored in regs

[10] , and the return value of the ARM64 system call is stored in regs[0] to ensure that the user-mode program receives the result correctly.

[0112] Performance optimization: Pure software-level dynamic mapping is used, the native ARM64 process has no performance loss, and the RISC-V process call latency is extremely small.

[0113] Furthermore, the steps of the signal processing context dynamic management method include:

[0114] Runtime environment construction: Register contents are set differently according to instruction set type, including passed parameters, stack pointer, return address, and return value.

[0115] Signal recovery: After the signal processing function is executed, rt_sigreturn is triggered through the vDSO jump board function, and the context is restored in conjunction with the register intermediate layer to ensure semantic consistency between ARM64 kernel mode and RISC-V user mode.

[0116] Isolation guarantee: Strictly adhere to the single instruction set process principle, and ensure that signal handling functions are consistent with the main program instruction types to prevent escape of cross-instruction set execution flow.

[0117] Another aspect of the present invention relates to a signal processing system for heterogeneous user instruction sets, and the kernel module units involved are as follows:

[0118] Instruction set type identification:

[0119] Process loading unit: Parses the ELF header and marks the pstate register.

[0120] Exception handling unit: dynamically extracts instruction set types using pt_regs.

[0121] Intermediate layer for cross-state register conversion:

[0122] Exception handling unit: Implements dynamic remapping of RISC-V and ARM64 system call parameters; writes back system call results according to instruction set type.

[0123] Signal context management:

[0124] Signal processing execution environment construction unit: Configure register contents according to instruction set type.

[0125] Signal recovery unit: Enables rapid signal recovery through the vDSO mechanism.

[0126] In summary, process instruction set type identification achieves lightweight marking by reusing reserved bit fields of ARM64 hardware registers, ensuring compatibility with existing chip designs; the cross-state register conversion intermediate layer adopts a dynamic software mapping strategy to avoid hardware modification or binary translation overhead; and the signal context management combines static construction and dynamic recovery mechanisms to eliminate the risk of cross-instruction set execution flow conflicts.

[0127] like Figure 2 , 3 As shown in Figure 4, this invention implements signal processing in a mixed-instruction operating system for ArmRV heterogeneous processors. Key features include instruction set architecture type identification and marking, cross-state privileged service context switching, and cross-state signal processing context management. The specific implementation method is as follows:

[0128] Based on the single instruction set process principle, the instruction set architecture type identification and marking method in this embodiment is implemented based on the reserved bit field bit[5:0] of the processor status register pstate of the ARM64 architecture. The instruction set type of the process is marked as ARM64 or RV64G by the flag bit, ensuring that the instruction set architecture of the user-mode executable file and the signal processing function within a single process is strictly consistent.

[0129] During the process loading phase, the operating system parses the e_machine field in the ELF header of the executable file to determine the target instruction set type. If it is a RISC-V architecture (EM_RISCV), the hardware extended flag PSR_MODE_ARMRV_EL0t (value 0x00000020) is set in the pstate register of the current process. This flag is isolated from other status bits by the mask ~PSR_MODE_ARMRV_MASK (0x0000003f). For ARM64 executables (EM_AARCH64), this flag is not set, and the file runs in ARM64 mode by default.

[0130] When a user-mode program triggers an exception and enters kernel mode, the hardware automatically saves the current pstate value to the kernel's pt_regs structure. The kernel extracts the instruction set type through bitwise operations (regs->pstate&PSR_MODE_ARMRV_MASK): if the result is PSR_MODE_ARMRV_EL0t, it is determined to be a RISC-V process; otherwise, it is an ARM64 process. This flag cannot be modified after the process is loaded, ensuring that the instruction set type is fixed throughout the process's lifecycle and avoiding the risk of state inconsistency caused by dynamic switching at runtime.

[0131] This embodiment achieves lightweight and highly reliable instruction set type identification through a hardware bit-field marking mechanism. Its advantages lie in reusing the reserved status bits of the ARM64 architecture, eliminating the need for customized hardware expansion and ensuring compatibility with existing chip designs; furthermore, it features strong security isolation. The process-level instruction set type is fixed, and combined with static verification of signal processing functions, it completely eliminates the risk of cross-instruction set execution flow escape.

[0132] This embodiment addresses the compatibility issue of cross-state privileged service context translation under the ARM64 and RISC-V hybrid instruction set architecture by designing a register translation intermediate layer, which achieves transparent system call processing across instruction sets through a dynamic remapping mechanism.

[0133] During the system call exception handling phase, the kernel determines the source of the exception by reading the exception class field of the esr_el1 register. If the exception value is the custom RISC-V system call identifier ESR_ELx_EC_RVECALL (0x14) in this embodiment, the el0_rvecall() processing flow is triggered; if it is the standard ARM64 system call identifier ESR_ELx_EC_SVC64 (0x15), it is processed according to the native process. For system calls triggered by RISC-V user-space programs through ecall, the parameter registers x10-x16 and the system call number register x17 are stored in the regs

[10] to regs

[17] fields of the kernel pt_regs structure. The register conversion intermediate layer maps the values ​​of regs

[10] to regs

[16] to regs[0] to regs[6] in the invoke_syscall() function, and sets regs

[17] as the system call number and stores it in the syscallno field, thereby adapting to the system call execution logic of the ARM64 kernel. After the system call is executed, the return value is written to different locations according to the instruction set type of the process: the return value of the RISC-V process is stored in regs

[10] , and the return value of the ARM64 process is stored in regs[0], to ensure that the user-mode program receives the result correctly.

[0134] This embodiment achieves dynamic register remapping through a pure software layer, enabling RISC-V user-space programs to call ARM64 kernel services without modification. System call parameters and return values ​​are automatically adapted. This approach not only achieves transparent compatibility for RISC-V user programs, avoiding the overhead of hardware modification or binary translation, but also ensures low conversion latency and guarantees no additional performance loss for native ARM64 processes.

[0135] This embodiment addresses the context management problem of cross-state signal processing under the ArmRV architecture by proposing a cross-instruction set system call dynamic register mapping method to ensure the transparency and efficiency of the signal processing flow.

[0136] During the signal triggering phase, after the kernel detects the _TIF_SIGPENDING flag through the do_notify_resume function, it calls the do_signal function to initiate the signal handling process. do_signal further calls the setup_rt_frame function to construct the runtime environment for the signal handling function. During this process, the kernel obtains the user-mode stack top pointer through get_sigframe and reserves space on the stack to construct the rt_sigframe_user_layout structure, saving the original program's context information. This context information is not used during the temporary storage of the user stack; therefore, this operation of temporarily saving the user program context on the user stack does not require separate handling for ARM64 and RISC-V. The above process is the native ARM64 process and can be applied to RISC-V processes without modification.

[0137] Next, when creating the execution context of the signal processing function, according to the single instruction set process principle, this embodiment prepares contexts for ARM64 and RISC-V respectively. The RISC-V signal processing logic in the setup_return function stores the return value in regs

[10] , stores the signal processing program stack pointer in regs[8], stores the jump board program address that quickly returns to kernel mode through the vDSO mechanism after signal processing in regs[1], and stores the processor architecture flag PSR_MODE_ARMRV_ELOt in pstate; corresponding to RISC-V, the same information for ARM is stored in regs[0], regs

[29] , and regs

[30] respectively. Next, in the setup_rt_frame function, the parameter registers for the extra parameters siginfo and ucontext structure address are set, which are stored in regs

[11] and regs

[12] in RISC-V and in regs[1] and regs[2] in ARM64.

[0138] After the signal handling function finishes execution and calls the jump function to rt_sigreturn, the corresponding context information is directly restored from the user stack without considering architectural differences. Then, when returning to user mode, the cross-mode privileged service context translation intermediate layer implemented above ensures the consistency of register semantics after user mode is restored.

[0139] This embodiment constructs a register translation intermediate layer by using a cross-instruction set system call dynamic register mapping method, thereby achieving cross-instruction set transparency of the signal processing flow.

[0140] The beneficial effects achieved by this invention are as follows:

[0141] 1. High efficiency and compatibility: Supports mixed operation of ARM64 and RISC-V user-space programs with extremely low signal processing latency.

[0142] 2. Lightweight design: Reuses hardware register bit fields, requiring no customized extensions, resulting in extremely low performance loss for native ARM64 processes.

[0143] 3. Security Isolation: By solidifying the process-level instruction set and statically verifying signal processing, the risk of cross-instruction set execution flow conflicts is completely eliminated.

[0144] 4. Industrial value: Provides operating system-level signal processing support for heterogeneous scenarios such as ArmRV, accelerating the integration of the RISC-V and ARM ecosystems.

[0145] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention. Clearly, those skilled in the art can make various alterations and modifications to the invention without departing from its spirit and scope. Thus, if these modifications and modifications of the invention fall within the scope of the claims and their equivalents, the invention is also intended to include these modifications and modifications.

Claims

1. A signal processing method for a heterogeneous user instruction set, characterized by, Comprise the following steps: In the process of user state loading stage, the process instruction set architecture type is identified and marked, including ARM64 instruction set and RV64G instruction set; The user state program is executed, and if the user state program is interrupted or triggers an exception to fall into the kernel state, the process instruction set architecture type is judged for the first time in the created cross-state privilege service context conversion intermediate layer through the marking bit, the ARM64 instruction set corresponds to AArch64 process, and the RV64G instruction set corresponds to RISC-V process; If it is a RISC-V process, the context of the user program is saved and a running site is created according to the provisions of RISC-V; if it is an AArch64 process, the context of the user program is saved and a running site is created according to the provisions of AArch64.

2. The signal processing method for a heterogeneous user instruction set according to claim 1, wherein, After the step that if it is a RISC-V process, the context of the user program is saved and a running site is created according to the provisions of RISC-V; if it is an AArch64 process, the context of the user program is saved and a running site is created according to the provisions of AArch64, the step further comprises: Kernel service is performed in the created running site; Preparation is made for returning to the user state; It is judged whether there is a signal to be calculated and processed; If yes, the context of the user program is saved to the user stack; The process instruction set architecture type is judged for the second time in the created cross-state transparent signal context initial intermediate layer through the marking bit; If it is a RISC-V process, a signal processing function running site is created according to the provisions of RISC-V, and a RISC-V signal processing program is executed; if it is an AArch64 process, a signal processing function running site is created according to the provisions of AArch64, and an AArch64 signal processing program is executed; The vDSO mechanism skip function entry is used to quickly return to the kernel state.

3. The signal processing method for a heterogeneous user instruction set according to claim 2, wherein, After the step that it is judged whether there is a signal to be calculated and processed, the step further comprises: If no, the process instruction set architecture type is judged for the third time in the created cross-state privilege service context conversion intermediate layer through the marking bit; If it is a RISC-V process, the context of the original user program is restored and a running site is created according to the provisions of RISC-V; if it is an AArch64 process, the context of the original user program is restored and a running site is created according to the provisions of AArch64.

4. The signal processing method for a heterogeneous user instruction set according to claim 3, wherein, In the step that the process instruction set architecture type is identified and marked in the process loading stage of the user state, according to the single instruction set process principle, the process instruction set architecture type is realized based on the reserved bit field bit[5:0] of the processor state register pstate of the ARM64 architecture.

5. The signal processing method for a heterogeneous user instruction set according to claim 3, wherein, In the step that the process instruction set architecture type is identified and marked in the process loading stage of the user state, based on the shared ARM64 basic service principle, a shared process life cycle management is proposed, and the loading support for the RV64G executable ELF file is increased.

6. The signal processing method for a heterogeneous user instruction set according to claim 3, wherein, In the step of identifying and marking the process instruction set architecture type in the user state process loading stage, the operating system parses the ELF executable file header e_machine field. If it is EM_RISCV, the flag bit PSR_MODE_ARMRV_EL0t (0x00000020) is set in the pstate register. If it is EM_AARCH64, the default value is reserved.

7. The signal processing method for a heterogeneous user instruction set according to claim 3, wherein, In the step of executing the user state program, if the user state program is interrupted or triggers an exception to fall into the kernel state, the kernel reads the pstate value through the pt_regs structure, extracts the flag bit to dynamically identify the current instruction set type, and performs the processing behavior of the corresponding architecture in the cross-state privilege service context conversion intermediate layer created by the marked bit for the first time.

8. The signal processing method for a heterogeneous user instruction set according to claim 3, wherein, In the step of executing the user state program, if the user state program is interrupted or triggers an exception to fall into the kernel state, the kernel reads the pstate value through the pt_regs structure, extracts the flag bit to dynamically identify the current instruction set type, and performs the processing behavior of the corresponding architecture in the cross-state privilege service context conversion intermediate layer created by the marked bit for the first time. When the user state program triggers an exception to fall into the kernel state, the current pstate value is automatically saved to the pt_regs structure of the kernel. The kernel extracts the instruction set type through bit operation. If the result is PSR_MODE_ARMRV_EL0t, it is determined to be a RISC-V process. Otherwise, it is determined to be an AArch64 process.

9. The signal processing method for a heterogeneous user instruction set according to claim 3, wherein, In the step of saving the context of the user program and creating a running site according to the RISC-V specification if it is a RISC-V process, or according to the AArch64 specification if it is an AArch64 process, the RISC-V system call parameters are dynamically remapped to the ARM64 kernel interface through the pure software layer intermediate conversion logic, realizing the consistency of parameters and return values across instruction sets.

10. The signal processing method for a heterogeneous user instruction set according to claim 3, wherein, In the step of restoring the context of the original user program and creating a running site according to the RISC-V specification if it is a RISC-V process, or according to the AArch64 specification if it is an AArch64 process, the signal processing running environment is constructed based on the process instruction set type difference, realizing the context recovery of the cross-instruction set signal processing program.

Images