Signal processing method for heterogeneous user instruction set

Abstract

The invention discloses a heterogeneous user instruction set-oriented signal processing method, which comprises the following steps of: identifying and marking the architecture type of a process instruction set in a process loading stage of a user mode, executing a user mode program by the process, and if the user mode program is interrupted or is abnormally triggered to fall into a kernel mode, executing the process; if yes, the process instruction set architecture type is judged for the first time through a flag bit in the created cross-state privileged service context conversion middle layer; if the process is the RISC-V process, the context of the user program is stored according to the regulation of RISC-V, and an operation site is created; if the process is the AArch64 process, the context of the user program is stored according to the regulation of AArch64, and an operation site is created. According to the method, user-awareness-free cross-instruction-set binary compatible execution and operating system-level execution stream safety guarantee are achieved.

Description

Technical Field

[0001] The present invention relates to the technical field of computer operating systems, and in particular discloses a signal processing method oriented to heterogeneous user instruction sets. Background Art

[0002] ARM and RISC-V are two independent instruction set architectures. With the trend toward independent and controllable instruction set architectures and reduced licensing restrictions, the RISC-V architecture demonstrates significant advantages in instruction set freedom and hardware customization.

[0003] However, the ARM architecture, with its mature business ecosystem and extensive market share, holds a dominant position in mobile computing, embedded systems, and other fields. Its rich software ecosystem and highly optimized tool chain 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 adaptation scale.

[0004] During this transitional period, many technologies have emerged to address software ecosystem compatibility issues. Solutions for single instruction set architectures 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 local instruction set one by one at runtime. Its advantage is that legacy programs can be run without modifying the source code. Its disadvantages include high performance loss caused by real-time translation, insufficient support for complex instruction extensions, and difficulty in ensuring application scenarios with strict real-time requirements.

[0006] Static recompilation technology refers to the technology of completely converting binary source code into the target platform instruction set before the program runs. Its advantage is that the code generation efficiency is close to that of native programs, 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, and it has higher security. Its disadvantage is 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, supporting the efficient operation of multi-architecture virtual machines or containers on the same physical machine. Its advantages are almost no performance loss and multiple architectures can be supported in parallel. Its disadvantages are high hardware dependence, high cost, and failure to meet the needs of hardware autonomy and control.

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

[0009] The present invention provides a signal processing method for heterogeneous user instruction sets, aiming to solve at least one of the above-mentioned defects existing in the existing instruction set architecture method.

[0010] The present invention relates to a signal processing method for heterogeneous user instruction sets, comprising the following steps: Identify and mark the process instruction set architecture type during the user-mode process loading phase. The process instruction set architecture types include ARM64 instruction set and RV64G instruction set. The process executes the user-mode program. If the user-mode program is interrupted or triggers an exception and falls into the kernel mode, the process instruction set architecture type is first determined by the flag bit in the created cross-mode privileged service context transition intermediate layer. The ARM64 instruction set corresponds to the AArch64 process, and the RV64G instruction set corresponds to the RISC-V process. If it is a RISC-V process, the context of the user program is saved and the execution 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 the execution site is created according to the provisions of AArch64.

[0011] Furthermore, if it is a RISC-V process, the context of the user program is saved and the running site is created according to the provisions of RISC-V; if it is an AArch64 process, after the steps of saving the context of the user program and creating the running site according to the provisions of AArch64, the following steps are further included: Perform kernel services at the created runtime site; Prepare to return to user mode; Determine whether there is a signal to be processed; If so, save the context of the user program to the user stack; In the created cross-state transparent signal context initial intermediate layer, the process instruction set architecture type is determined for the second time through the flag bit; If it is a RISC-V process, a signal processing function execution site is created according to the RISC-V regulations and the RISC-V signal processing program is executed; if it is an AArch64 process, a signal processing function execution site is created according to the AArch64 regulations and the AArch64 signal processing program is executed; Use the vDSO mechanism to quickly return to kernel mode by using the springboard function entry.

[0012] Furthermore, after the step of determining whether there is a signal to be processed, the following step is further included: If not, the process instruction set architecture type is determined for the third time by using the flag bit in the created cross-state privileged service context conversion intermediate layer; If it is a RISC-V process, the context of the original user program is restored and the 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 the running site is created according to the provisions of AArch64.

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

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

[0015] 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 ELF executable file header. 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.

[0016] Furthermore, when a process executes a user-mode program, if the user-mode program is interrupted or triggers an exception and falls into kernel mode, then in the step of first determining the process instruction set architecture type through the flag bit in the created cross-mode privileged service context transition intermediate layer, 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 processing behavior of the corresponding architecture.

[0017] Furthermore, when a process executes a user-mode program, if the user-mode program is interrupted or an exception is triggered, trapping the program into kernel mode, the steps of first determining the process instruction set architecture type by using a flag bit in the created cross-mode privileged service context transfer intermediate layer include: When a user-mode program triggers an exception and falls into kernel mode, the current pstate value is automatically saved to the kernel's pt_regs structure; The kernel extracts the instruction set type through bit 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.

[0018] Furthermore, if it is a RISC-V process, the context of the user program is saved and the 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 the running site is created according to the provisions of AArch64. Through the pure software layer intermediate conversion logic, the RISC-V system call parameters are dynamically remapped to the ARM64 kernel interface to achieve cross-instruction set semantic consistency of parameters and return values.

[0019] Furthermore, if it is a RISC-V process, the context of the original user program is restored and the 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 the running site is created according to the provisions of AArch64, and the signal processing running environment is constructed based on the process instruction set type to realize context recovery of signal processing programs across instruction sets.

[0020] The beneficial effects achieved by the present invention are: The present invention provides a signal processing method for heterogeneous user instruction sets. The method identifies and marks the process instruction set architecture type during the process loading phase in user mode. The process executes the user mode program. If the user mode program is interrupted or triggers an exception and falls into kernel mode, the process instruction set architecture type is first determined by a mark bit in the created cross-mode privileged service context conversion intermediate layer. 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 signal processing method for heterogeneous user instruction sets provided by the present invention solves the technical problems of software ecological compatibility between ARM and RISC-V, lack of instruction set type identification in signal processing under the ArmRV hybrid instruction set architecture, lack of running environment for RV64G instruction set processes, failure of cross-instruction set context switching, and lack of signal processing running environment, thereby realizing user-unaware cross-instruction set binary compatible execution and operating system-level execution flow security. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 A flow chart of the signal mechanism from signal sending to processing; Figure 2 A schematic diagram of a signal processing flow chart of an embodiment of a signal processing method for heterogeneous user instruction sets according to the present invention; Figure 3 A schematic diagram of a context storage flow under the ARM64 instruction set architecture according to an embodiment of a signal processing method for heterogeneous user instruction sets of the present invention; Figure 4This is a schematic diagram of the context storage flow under the RV64G instruction set architecture of an embodiment of the signal processing method for heterogeneous user instruction sets of the present invention. DETAILED DESCRIPTION

[0022] In order to better understand the above technical solution, the above technical solution will be described in detail below with reference to the accompanying drawings and specific implementation methods.

[0023] like Figures 2 to 4 As shown, the first embodiment of the present invention provides a signal processing method for heterogeneous user instruction sets, comprising the following steps: 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 the ARM64 instruction set and the RV64G instruction set.

[0024] User Mode is a low-privilege execution mode assigned by the operating system to standard applications. Processes running in User Mode can only access limited system resources and cannot directly operate hardware or execute privileged instructions. This design ensures system stability through privilege isolation and prevents application errors from affecting core system functions.

[0025] The process loading phase is the key process for the operating system to convert an executable program into a running process.

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

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

[0028] Step S200: The process executes the user-mode program. If the user-mode program is interrupted or triggers an exception and falls into the kernel mode, the process instruction set architecture type is first determined by the mark bit in the created cross-mode privileged service context transition intermediate layer. The ARM64 instruction set corresponds to the AArch64 process, and the RV64G instruction set corresponds to the RISC-V process.

[0029] User mode programs refer to applications that run in the user mode of the operating system.

[0030] Kernel Mode is the privileged mode in which the operating system's core (kernel) operates, possessing the highest level of privilege. 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.

[0031] The cross-state privileged service context switching middleware is an intermediate logic layer that coordinates resource access and state switching between different privilege levels of a computer system (such as user state and kernel state).

[0032] An AArch64 process is a program instance that runs in 64-bit mode on the ‌ARMv8-A architecture‌. Its core features are closely related to the architecture design.

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

[0034] Step S300: If it is a RISC-V process, the context of the user program is saved and the 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 the running site is created according to the provisions of AArch64.

[0035] 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 a 64-bit execution mode of the ARMv8-A architecture, designed around high performance, multi-level security isolation, and support for complex computations.

[0036] Further, see Figures 2 to 4 The signal processing method for heterogeneous user instruction sets proposed in this embodiment further includes, after step S300: Step S410: Perform kernel services at the created running site.

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

[0038] Step S430: Determine whether there is a signal to be processed.

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

[0040] 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 process management.

[0041] Step S450: Determine the process instruction set architecture type for the second time through the flag bit in the created cross-state transparent signal context initial intermediate layer.

[0042] The cross-state transparent signal context initialization middleware is a core component in the distributed system architecture, designed to achieve transparency in signal transmission and processing across different states, protocols or environments.

[0043] Step S460: If it is a RISC-V process, a signal processing function execution site is created according to the RISC-V regulations and a RISC-V signal processing program is executed; if it is an AArch64 process, a signal processing function execution site is created according to the AArch64 regulations and an AArch64 signal processing program is executed.

[0044] The execution context of the signal processing function refers to the execution context of the process when the signal is triggered, including register status, memory layout, and operating environment information.

[0045] A RISC-V signal handler is a software module based on the RV64G instruction set that responds to asynchronous events (such as synchronous signals, asynchronous signals, and uncatchable signals) triggered by the operating system or hardware.

[0046] An AArch64 signal handler is a software module based on the ‌ARM64 instruction set‌ that responds to asynchronous events (such as synchronous signals, asynchronous signals, and uncatchable signals) triggered by the operating system or hardware.

[0047] Step S470: Use the vDSO mechanism springboard function entry to quickly return to the kernel state.

[0048] The springboard function entry of the vDSO (virtual Dynamic Shared Object) mechanism is a specific code segment entry point dynamically mapped from the kernel to user space, which is used to replace the privilege level switching of traditional system calls.

[0049] Preferably, see Figures 2 to 4 The signal processing method for heterogeneous user instruction sets proposed in this embodiment further includes, after step S430: Step S480: If not, the process instruction set architecture type is determined for the third time by using the flag bit in the created cross-state privileged service context transfer intermediate layer.

[0050] The cross-state privileged service context transition 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.

[0051] Step S490: If it is a RISC-V process, the context of the original user program is restored and the 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 the running site is created according to the provisions of AArch64.

[0052] Furthermore, the signal processing method for heterogeneous user instruction sets provided in this embodiment is 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 bit[5:0] of the processor state register pstate of the ARM64 architecture.

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

[0054] Furthermore, in the signal processing method for heterogeneous user instruction sets provided by this embodiment, in step S100, the operating system parses the e_machine field in the ELF executable file header. 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.

[0055] Furthermore, in the signal processing method for heterogeneous user instruction sets provided by 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 processing behavior of the corresponding architecture.

[0056] Furthermore, the signal processing method for heterogeneous user instruction sets provided by this embodiment includes step S200: Step S210: When the user-mode program triggers an exception and falls into the kernel mode, the current pstate value is automatically saved to the kernel's pt_regs structure.

[0057] Step S220: The kernel extracts the instruction set type through bit 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.

[0058] 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 kernel interface through the pure software layer intermediate conversion logic, thereby achieving cross-instruction set semantic consistency of parameters and return values.

[0059] Furthermore, in the signal processing method for heterogeneous user instruction sets provided in this embodiment, in step S490, a signal processing operating environment is differentially constructed based on the process instruction set type, so as to implement context recovery of signal processing programs across instruction sets.

[0060] like Figures 1 to 4 As shown, the signal processing method for heterogeneous user instruction sets provided by this embodiment has the following working principles: With the rise of open instruction sets like RISC-V, hybrid instruction set architecture (HISA) co-design is emerging as a new direction for breaking through ecosystem barriers. Hybrid ISA processors fuse the ARM and RISC-V instruction sets at the hardware level, combined with dynamic context management mechanisms at the operating system level, to achieve seamless scheduling and resource isolation of cross-IS processes. This approach balances ecosystem compatibility with the need for independent control while minimizing performance degradation, providing a more flexible technical foundation for the long-term evolution of heterogeneous computing platforms.

[0061] Based on the above ideas, a processor system based on the hybrid instruction set architecture of RV64G and ARM64 was designed and developed, and this hybrid instruction set architecture that is compatible with the ARM64 instruction set and the RV64G user-mode instruction set 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 ARM and RISC-V programs on the ArmRV processor without modifying the code. This architecture only supports the ARM64 instruction set in the EL1-EL3 privileged states, and supports both the ARM64 and RV64G instruction sets in the EL0 user state. 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 smaller execution pipeline hardware overhead, including smaller processor hardware area, lower power consumption, and lower timing complexity.

[0062] 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. Decoder decoupling technology pre-decodes ARM64 and RV64G instructions into a unified intermediate format, subsequently reusing the same set of decoders and execution units to reduce duplication of design; execution pipeline operator reuse technology allows 92% of RV64G instructions to reuse the basic operators of ARM64 instructions, implementing only a small number of independent operators, avoiding the need to independently implement all functional units for the two instruction sets; 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. In terms of execution state switching implementation, the ArmRV processor uses PSTATE[5:0] internally to identify execution status, exception level, and other information, while also supporting the newly added illegal return exception handling. The above technologies control the increase in processor hardware area to less than 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.

[0063] In order to achieve binary compatibility and hot switching of these two instruction applications on the new platform, it is necessary to adapt the operating system to the ArmRV instruction set architecture, and the design of process life cycle management support, system call / exception service, signal processing, etc. should be considered. Among them, signal is an asynchronous event notification mechanism, including Figure 1 The three steps shown are signal generation, signal storage, and signal processing. Signals are initially generated by keyboard input, system calls, software conditions, and hardware exceptions. The kernel determines the relevant information and saves it to the target process's pending signal table. When the target process completes a kernel service and returns to user mode from kernel mode, it checks for the presence of a signal and, if so, performs signal processing. Signal processing can be performed in three ways: default, custom, and ignore.

[0064] The present invention discloses a signal processing method for heterogeneous user instruction sets. Through dynamic context switching and an ABI transparent adaptation mechanism, user-imperceptible cross-instruction set binary compatible execution is achieved. The present invention supports the mixed operation of ARM64 and RISC-V user-mode programs without modifying the application source code or binary files, and ensures cross-instruction set consistency in the signal processing execution environment construction and context recovery process, providing operating system-level signal processing integrity protection for heterogeneous processors. Based on the characteristics of the ArmRV instruction set architecture that only supports the ARM64 instruction set in the EL1-EL3 privileged states and supports both the ARM64 and RV64G instruction sets in the EL0 user state, the key issue of cross-instruction set binary file compatible execution is that RV64G applications do not have RV64G kernel service support. To achieve mixed operation of programs of the two instruction sets, RV64G applications need to reuse ARM64 kernel services. Based on this design, it is necessary to consider the semantic issues of context transfer when switching between RV64G user programs and ARM64 kernel services across states, that is, dynamic register conversion is required. Analysis of the aforementioned signal generation, storage, and processing steps reveals that register semantic issues may exist during signal generation and signal processing. When a signal is generated by a system call, the RV64G binary program prepares the corresponding parameters, enters the kernel, and calls the ARM64 kernel service. In this process, register conversion is involved. When the signal is processed in a custom way, such as Figure 2As shown, the timing for signal recognition and processing is before returning from kernel services. Before this, support for ② context switching to the kernel is required, which is consistent with the adaptation requirements of the signal generation stage. Processing signals requires returning to user mode to execute a customized signal handler, which requires ③ creating a context environment for signal handlers of 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 running environment for the process. In addition to determining the process instruction set type and supporting RV64G application lifecycle management, the key issues faced in achieving signal processing in the ArmRV architecture can be summarized as follows: (1) Lack of instruction set architecture recognition: When the signal is triggered, the operating system cannot dynamically determine the process instruction set type of the current execution flow, resulting in register saving errors or incompatible formats.

[0065] (2) Lack of operating environment for RV64G instruction set processes: The operating system for ARM64 instruction set applications does not support the lifecycle management of RV64G instruction set applications.

[0066] (3) Failure of cross-state context switching: When the RV64G user program and the ARM64 kernel handler switch across states, the traditional context recovery mechanism cannot achieve transparent switching, causing the execution flow to crash.

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

[0068] The present invention designs a hybrid instruction set operating system based on the following two principles to solve the above four problems and implement signal processing support in the hybrid instruction set operating system: (1) Single instruction set process principle: A single process only supports running user-mode programs with a single instruction set. The signal handling 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 handlers will be registered in the RISC-V executable program. The same is true for ARM64. (2) Sharing ARM64 basic service principle: The kernel-mode service of the present invention is supported by the ARM64 instruction set program. When designing a mixed-pointer operating system, the RV64 application program can share the ARM64 basic service, which can reduce the development workload of the operating system, reduce the complexity of the software system, and improve the usability and system efficiency.

[0069] In general, the software ecosystem compatibility issues of RISC-V should be solved by adapting the ArmRV heterogeneous processor and the mixed-finger operating system. Without modifying the application source code or binary files, it is necessary to support the mixed operation of ARM64 and RISC-V user-mode programs, and ensure the cross-instruction set consistency of signal capture, stack frame construction and context recovery processes. The key is to realize state labeling and cross-state context transfer layer.

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

[0071] One aspect of the present invention relates to a signal processing method for heterogeneous user instruction sets, comprising the following steps: In order to solve the problem (1) of missing instruction set architecture identification, a dynamic identification and marking method for instruction set architecture is proposed: based on the reserved bit field bit[5:0] of the ARM64 processor status register pstate, the e_machine field in the ELF header of the executable file is parsed during the process loading phase to determine and solidify the instruction set type of the process as ARM64 or RV64G. Combined with the principle (1) single instruction set process principle, the instruction set architecture of the current process and its signal handler can be quickly, conveniently and cheaply determined during the process life cycle, facilitating different processing; In order to solve the problem (2) of the lack of a running environment for RV64G instruction set processes, based on principle (2) of sharing ARM64 basic services, a method for shared process lifecycle management is proposed: by adding support for loading RV64G executable ELF files, the operating system can naturally load and schedule applications of two different instruction sets at the same time, providing lifecycle management for mixed instruction set processes.

[0072] To solve the problem (3) of cross-state context switching failure, a cross-instruction set system call dynamic register mapping method is proposed: through the pure software layer intermediate conversion logic, the RISC-V system call parameters are dynamically remapped to the ARM64 kernel interface to achieve cross-instruction set semantic consistency of parameters and return values. This lightweight method can ensure that the cross-state service processing efficiency is close to the native performance; In order to solve the problem (4) of insufficient signal stack compatibility, a dynamic management method for signal processing context is proposed: the signal processing operating environment is constructed based on the differentiation of process instruction set types, and the context recovery of signal processing programs across instruction sets is realized, so as to achieve transparent support for mixed communication of two instruction set applications based on the communication function library.

[0073] Furthermore, the steps of the instruction set architecture dynamic identification and marking method include: Identify and mark the process architecture type during the process loading phase: the operating system parses the e_machine field in the ELF executable file header. 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.

[0074] In the signal processing process, the architecture type is determined by the flag bit: 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 processing behavior of the corresponding architecture.

[0075] Furthermore, the steps of the shared process lifecycle management method include: Added support for RV64G executable files: When loading an executable file, the logic for checking whether the file machine type is reasonable is added to check whether the EM_RISCV flag is passed. Initialize the running site: When initializing the process running site for the RV64G file, set the program status register to PSR_MODE_ARMRV_EL0t.

[0076] Furthermore, the steps of the cross-instruction set system call dynamic register mapping method include: Parameter remapping: When a RISC-V user program triggers a system call through ecall, the kernel dynamically maps parameter registers x10-x16 to the kernel stack regs[0]-regs[6], and stores the system call number x17 in the scno field to ensure register semantic consistency when the kernel code is executed.

[0077] Return value adaptation: According to the process instruction set type, the RISC-V system call return value is stored in regs

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

[0078] Performance optimization: Using pure software layer dynamic mapping, the native ARM64 process has no performance loss, and the RISC-V process call delay is extremely small.

[0079] Furthermore, the steps of the signal processing context dynamic management method include: Runtime environment construction: Register contents are set differently according to the instruction set type, including passing parameters, stack pointers, return addresses, and return values.

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

[0081] Isolation protection: Strictly adhere to the principle of a single instruction set process, and the signal processing function is consistent with the main program instruction type to avoid cross-instruction set execution flow escape.

[0082] 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: Instruction set type identification: Process load unit: parses the ELF header and marks the pstate register.

[0083] Exception handling unit: Dynamically extract instruction set type through pt_regs.

[0084] Cross-state register conversion middle layer: Exception handling unit: Implements dynamic remapping of RISC-V and ARM64 system call parameters; writes back system call results according to instruction set type.

[0085] Signal context management: Signal processing execution environment construction unit: configure register contents according to instruction set type.

[0086] Signal recovery unit: Realizes rapid signal processing recovery through the vDSO mechanism.

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

[0088] like Figure 2 、 3 As shown in FIG4 , the present invention implements signal processing in a mixed-finger operating system for the ArmRV heterogeneous processor. The core points include instruction set architecture type identification and marking, cross-state privileged service context conversion, and cross-state signal processing context management. The specific implementation method is as follows: According to the principle of a single instruction set process, the instruction set architecture type identification and marking method of this embodiment is implemented based on the reserved bit field bit[5:0] of the processor state 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 are strictly consistent.

[0089] During process loading, the operating system parses the executable file's ELF header's e_machine field to determine the target instruction set type. If the target architecture is RISC-V (EM_RISCV), the hardware extension flag PSR_MODE_ARMRV_EL0t (value 0x00000020) is set in the current process's pstate register. 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 executable runs in ARM64 mode by default.

[0090] When a user-mode program triggers an exception and falls into 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 a bitwise operation (regs->pstate & PSR_MODE_ARMRV_MASK). If the result is PSR_MODE_ARMRV_EL0t, the process is considered 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 lifetime and avoiding the risk of state inconsistencies caused by dynamic switching at runtime.

[0091] This embodiment uses a hardware bitfield tagging mechanism to achieve lightweight and highly reliable instruction set type identification. Its advantages lie in reusing the reserved status bits of the ARM64 architecture, eliminating the need for customized hardware extensions and maintaining compatibility with existing chip designs. Furthermore, it provides strong security isolation. This design solidifies the instruction set type at the process level, combined with static verification of signal processing functions, completely eliminating the risk of cross-instruction set execution flow escape.

[0092] This embodiment addresses the compatibility issue of cross-state privileged service context conversion under the ARM64 and RISC-V hybrid instruction set architecture, designs a register conversion middle layer, and implements transparent system call processing across instruction sets through a dynamic remapping mechanism.

[0093] 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 RISC-V system call identifier ESR_ELx_EC_RVECALL (0x14) customized 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-mode programs through ecall, its parameter registers x10-x16 and system call number register x17 are stored in the regs

[10] to regs

[17] fields of the kernel pt_regs structure. In the invoke_syscall() function, the register conversion middle layer maps the values of regs

[10] to regs

[16] to regs[0] to regs[6] in sequence, and sets regs

[17] to 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.

[0094] This embodiment implements dynamic register remapping through a pure software layer, allowing RISC-V user-mode programs to call ARM64 kernel services without modification, and automatically adapting system call parameters and return values. This approach not only achieves transparent compatibility with RISC-V user programs, avoiding the overhead of hardware modification or binary translation, but also ensures low conversion latency and no additional loss in the runtime performance of native ARM64 processes.

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

[0096] During the signal triggering phase, the kernel detects the _TIF_SIGPENDING flag through the do_notify_resume function and calls the do_signal function to initiate the signal processing process. do_signal further calls the setup_rt_frame function to construct the runtime environment for the signal processing function. During this process, the kernel obtains the pointer to the top of the user stack through get_sigframe and reserves space on the stack to construct the rt_sigframe_user_layout structure to save the context information of the original program. This context information is not used during the temporary storage of the user stack, so the operation of temporarily saving the user program context on the user stack here does not need to be processed separately for ARM64 and RISC-V. The above process is native to ARM64 and can also be applied to RISC-V processes without modification.

[0097] Then, when creating the signal processing function execution site, according to the principle of a single instruction set process, 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] , the signal processing program stack pointer in regs[8], the springboard program address that quickly returns to the kernel state through the vDSO mechanism after the signal processing is completed in regs[1], and the processor architecture flag PSR_MODE_ARMRV_ELOt in pstate; corresponding to RISC-V, the same information of ARM is stored in regs[0], regs

[29] , and regs

[30] respectively. Then, in the setup_rt_frame function, the parameter registers for the additional 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.

[0098] When the signal processing function is executed and the springboard function is called to transfer to rt_sigreturn, the corresponding context information is directly restored from the user stack without considering the architectural differences. Then, when returning to the user state, the cross-state privileged service context transfer middle layer implemented above is used to ensure the semantic consistency of the registers after the user state is restored.

[0099] This embodiment calls a dynamic register mapping method across instruction set systems to build a register conversion intermediate layer, thereby achieving cross-instruction set transparency of the signal processing flow.

[0100] The beneficial effects achieved by the present invention are: 1. Efficient compatibility: supports mixed operation of ARM64 and RISC-V user-mode programs, with extremely low signal processing latency.

[0101] 2. Lightweight design: Reuses hardware register bit fields, eliminating the need for customized extensions, and reduces native ARM64 process performance loss.

[0102] 3. Security isolation: Through process-level instruction set solidification and signal processing static verification, the risk of cross-instruction set execution flow conflicts is completely eliminated.

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

[0104] Although preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they are aware of the basic inventive concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the invention. Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the invention. Thus, the present invention is intended to include such changes and modifications as fall within the scope of the claims and their equivalents.

Claims

1. A signal processing method for heterogeneous user instruction sets, characterized in that: The following steps are involved: Identify and mark the process instruction set architecture type during the process loading phase in user mode, where the process instruction set architecture type includes the ARM64 instruction set and the RV64G instruction set; The process executes a user-mode program. If the user-mode program is interrupted or an exception is triggered, causing it to fall into kernel mode, the process instruction set architecture type is first determined by the flag bit in the created cross-mode privileged service context transition intermediate layer. The ARM64 instruction set corresponds to the AArch64 process, and the RV64G instruction set corresponds to the RISC-V process. If it is a RISC-V process, the context of the user program is saved and the execution 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 the execution site is created according to the provisions of AArch64.

2. The signal processing method for heterogeneous user instruction sets according to claim 1, characterized in that: If it is a RISC-V process, the context of the user program is saved and the 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 the running site is created according to the provisions of AArch64. The following steps are also included: Perform kernel services at the created runtime site; Prepare to return to user mode; Determine whether there is a signal to be processed; If so, save the context of the user program to the user stack; Determining the process instruction set architecture type for the second time by using the flag bit in the created cross-state transparent signal context initial intermediate layer; If it is a RISC-V process, a signal processing function execution site is created according to the RISC-V regulations and the RISC-V signal processing program is executed; if it is an AArch64 process, a signal processing function execution site is created according to the AArch64 regulations and the AArch64 signal processing program is executed; Use the vDSO mechanism to quickly return to kernel mode by using the springboard function entry.

3. The signal processing method for heterogeneous user instruction sets according to claim 2, characterized in that: After the step of determining whether there is a signal to be processed, the following steps are further included: If not, determining the process instruction set architecture type for the third time by using the flag bit in the created cross-state privileged service context transfer intermediate layer; If it is a RISC-V process, the context of the original user program is restored and the 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 the running site is created according to the provisions of AArch64.

4. The signal processing method for heterogeneous user instruction sets according to claim 3, characterized in that: In the step of identifying and marking the process instruction set architecture type in the process loading phase in user mode, according to the single instruction set process principle, the process instruction set architecture type is implemented 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 heterogeneous user instruction sets according to claim 3, characterized in that: In the step of identifying and marking the process instruction set architecture type in the process loading phase in user mode, based on the principle of sharing ARM64 basic services, shared process lifecycle management is proposed to increase support for loading RV64G executable ELF files.

6. The signal processing method for heterogeneous user instruction sets according to claim 3, characterized in that: 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 ELF executable file header. 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 retained.

7. The signal processing method for heterogeneous user instruction sets according to claim 3, characterized in that: The process executes a user-state program. If the user-state program is interrupted or triggers an exception and falls into kernel state, in the step of first determining the instruction set architecture type of the process through the flag bit in the created cross-state privileged service context conversion intermediate layer, 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 processing behavior of the corresponding architecture.

8. The signal processing method for heterogeneous user instruction sets according to claim 3, characterized in that: The process executes a user-mode program. If the user-mode program is interrupted or triggers an exception and falls into kernel mode, the step of first determining the instruction set architecture type of the process by using a flag bit in the created cross-mode privileged service context transfer intermediate layer includes: When a user-mode program triggers an exception and falls into kernel mode, the current pstate value is automatically saved to the kernel's pt_regs structure; The kernel extracts the instruction set type through bit 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.

9. The signal processing method for heterogeneous user instruction sets according to claim 3, characterized in that: If it is a RISC-V process, the context of the user program is saved and the 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 the running site is created according to the provisions of AArch64. Through the pure software layer intermediate conversion logic, the RISC-V system call parameters are dynamically remapped to the ARM64 kernel interface to achieve cross-instruction set semantic consistency of parameters and return values.

10. The signal processing method for heterogeneous user instruction sets according to claim 3, characterized in that: If it is a RISC-V process, the context of the original user program is restored and the 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 the running site is created according to the provisions of AArch64. The signal processing running environment is differentially constructed based on the process instruction set type to realize context recovery of signal processing programs across instruction sets.

Images