Register access instruction generation method, register access method, host, device, server and medium

Abstract

The application relates to the technical field of artificial intelligence chips, and provides a register access instruction generation method, a register access method, a host, equipment, a server and a medium, which comprise the following steps: extracting cross-thread bundle shared variables in kernel code; based on the total private register demand of the kernel code, dividing physical register resources of a hardware device into a private register pool and a shared register pool; determining a shared base address of the shared register pool, and allocating a static offset to each cross-thread bundle shared variable; and converting access statements in the kernel code for each cross-thread bundle shared variable into target access instructions according to the shared base address and the static offset. The application divides the shared register pool, and generates target access instructions by using a unified shared base address combined with a static offset, so that high-speed register-level data sharing and low-delay communication of cross-thread bundles are realized, cross-thread bundle synchronization and memory access delay are reduced, and the utilization rate of on-chip physical register resources is improved.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence chip technology, and in particular to a register access instruction generation method, a register access method, a host, a device, a server, and a medium. Background Technology

[0002] In current mainstream artificial intelligence devices and their hardware execution models, computing units have a fixed number of physical register files. When the kernel starts, each thread is assigned a set of private thread local registers (TLRs), which are typically organized and managed in units of warp.

[0003] In traditional hardware architectures, the number of registers required by each thread bundle is statically determined at compile time, and the hardware allocates a separate private register block for each active thread bundle at runtime. Under this execution model, register access is strictly confined to a single thread bundle; a thread bundle cannot access register blocks allocated to other thread bundles, thus achieving thread isolation.

[0004] However, as the demands of parallel computing become increasingly complex, existing register management and allocation mechanisms have gradually revealed significant shortcomings. First, due to the lack of fast data exchange channels between thread bundles, communication across thread bundles must be achieved through slower shared memory or global memory, introducing significant memory access latency and synchronization overhead. Second, physical registers are statically divided into completely isolated private blocks, resulting in extremely rigid hardware resource allocation; even if some thread bundles have idle registers, they cannot be utilized by other thread bundles that urgently need resources. Furthermore, existing programming models only provide low-level thread bundle internal primitives, making it difficult to support fine-grained collaboration across thread bundles. Summary of the Invention

[0005] This invention provides a register access instruction generation method, a register access method, a host, a device, a server, and a medium to solve the defects in related technologies, such as high cross-thread communication latency, large synchronization overhead, and low utilization of on-chip physical register resources, caused by strict isolation of register resources between thread bundles.

[0006] This invention provides a method for generating register access instructions, the method being applied to a host computer, the method comprising: Obtain the kernel code to be processed, and extract at least one cross-thread bundle shared variable declared in the kernel code; Determine the total private register requirement of the kernel code when it runs on the hardware device, and based on the total private register requirement, divide the physical register resources of the hardware device into a private register pool and a shared register pool. The shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles. Determine the shared base address corresponding to the shared register pool, and allocate a static offset relative to the shared base address in the shared register pool for each cross-thread bundle shared variable; Based on the shared base address and the static offset, the access statements in the kernel code for the shared variables across each thread bundle are converted into target access instructions. The target access instructions are used to instruct the hardware device to access the corresponding shared registers in the shared register pool based on the shared base address and the static offset.

[0007] According to a register access instruction generation method provided by the present invention, the step of determining the total private register requirement of the kernel code when running on a hardware device, and dividing the physical register resources of the hardware device into a private register pool and a shared register pool based on the total private register requirement, includes: Based on the kernel code, determine the number of private registers required for each thread; The total private register requirement is calculated based on the number of private registers, the thread bundle size of the hardware device, and the maximum number of concurrent thread bundles. If the total private register requirement does not exceed the physical register resources, the space in the physical register resources that matches the size of the total private register requirement is divided into the private register pool. The remaining available space in the physical register resources, excluding the private register pool, is divided into the shared register pool.

[0008] According to a register access instruction generation method provided by the present invention, determining the shared base address corresponding to the shared register pool includes: Determine the end address of the private register pool within the physical register resource; Configure the end address as the shared base address of the shared register pool so that the shared register pool and the private register pool are physically contiguous.

[0009] According to a register access instruction generation method provided by the present invention, the step of allocating a static offset relative to the shared base address for each cross-thread bundle shared variable in the shared register pool includes: Obtain the data type size of each cross-thread bundle shared variable; Based on the declaration order of each cross-thread bundle shared variable and the data type size of each cross-thread bundle shared variable, the static offset is allocated to each cross-thread bundle shared variable in the shared register pool so that each cross-thread bundle shared variable is arranged linearly and continuously in the shared register pool.

[0010] According to a register access instruction generation method provided by the present invention, before the step of allocating the static offset for each cross-thread bundle shared variable in the shared register pool, the method further includes: Analyze the lifetime of each cross-thread bundle shared variable in the kernel code to identify at least two target cross-thread bundle shared variables whose lifetimes do not overlap; The process of allocating the static offset for each cross-thread bundle shared variable in the shared register pool includes: In the shared register pool, the same static offset is assigned to the at least two target cross-thread bundle shared variables to indicate that the at least two target cross-thread bundle shared variables reuse the same physical register at runtime.

[0011] According to a register access instruction generation method provided by the present invention, the step of converting access statements in the kernel code for the cross-thread bundle shared variables into target access instructions based on the shared base address and the static offset includes: Analyze the access statements in the kernel code for the shared variables across each thread bundle to determine the corresponding shared access mode; Based on the shared access mode, the memory access operations corresponding to the access statements are merged or rearranged to obtain an optimized memory access operation sequence. Based on the shared base address and the static offset, the optimized memory access operation sequence is converted into the target access instruction; The target access instruction is either a hardware atomic operation instruction or a normal memory access instruction, and the static offset is fixed in the target access instruction as a compile-time constant.

[0012] A register access instruction generation method provided by the present invention further includes: Generate initialization instructions, which instruct the hardware device to load the shared base address into the shared base address register when the kernel starts.

[0013] This invention also provides a register access method applied to a hardware device, wherein the physical register resources of the hardware device are divided into a private register pool and a shared register pool according to the total private register requirements of the kernel code during runtime, and the shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles. The method includes: Receive register access instructions from the host, the register access instructions including the target access instructions obtained by the host after converting the access statements in the kernel code for cross-thread bundle shared variables; Decode the register access instruction to determine the addressing mode corresponding to the register access instruction; When the addressing mode is shared mode, the shared base address corresponding to the shared register pool is obtained based on the register identifier carried in the register access instruction, and the first target physical address is determined according to the shared base address and the static offset carried in the register access instruction. The static offset is the offset relative to the shared base address that the host pre-allocates in the shared register pool for the corresponding cross-thread bundle shared variable. Based on the first target physical address, the corresponding shared register in the shared register pool is accessed.

[0014] According to a register access method provided by the present invention, the step of accessing the corresponding shared register in the shared register pool based on the first target physical address includes: The current access status of the target shared register corresponding to the first target physical address is obtained through the configured shared access status register. The shared access status register records the access status of each shared register in the shared register pool. Based on the current access state, conflict detection is performed on the current thread's access to the target shared register. If no conflict is detected, a hardware atomic operation based on the shared base address is performed on the target shared register, and the access status of the target shared register in the shared access status register is updated.

[0015] According to a register access method provided by the present invention, the method further includes: When the addressing mode is private mode, the second target physical address is calculated based on the private base address of the current thread, the thread channel identifier, and the local offset, and the corresponding private register in the private register pool is accessed according to the second target physical address.

[0016] The present invention also provides a register access instruction generation apparatus, the apparatus being applied to a host computer, the apparatus comprising: An extraction module is used to obtain the kernel code to be processed and extract at least one cross-thread bundle shared variable declared in the kernel code; The partitioning module is used to determine the total private register requirement of the kernel code when it runs on the hardware device, and based on the total private register requirement, divide the physical register resources of the hardware device into a private register pool and a shared register pool. The shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles. An allocation module is used to determine the shared base address corresponding to the shared register pool and allocate a static offset relative to the shared base address for each cross-thread bundle shared variable in the shared register pool; The conversion module is used to convert the access statements in the kernel code for the shared variables across each thread bundle into target access instructions based on the shared base address and the static offset. The target access instructions are used to instruct the hardware device to access the corresponding shared registers in the shared register pool based on the shared base address and the static offset.

[0017] The present invention also provides a register access device applied to a hardware device, wherein the physical register resources of the hardware device are divided into a private register pool and a shared register pool according to the total private register requirements of the kernel code during runtime, and the shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles. The device includes: A receiving module is used to receive register access instructions from the host, the register access instructions including the target access instructions obtained by the host after converting the access statements for cross-thread bundle shared variables in the kernel code; The decoding module is used to decode the register access instruction and determine the addressing mode corresponding to the register access instruction; The determination module is used to, when the addressing mode is shared mode, obtain the shared base address corresponding to the shared register pool based on the register identifier carried in the register access instruction, and determine the first target physical address according to the shared base address and the static offset carried in the register access instruction. The static offset is the offset relative to the shared base address that the host pre-allocates in the shared register pool for the corresponding cross-thread bundle shared variable. The access module is used to access the corresponding shared registers in the shared register pool according to the first target physical address.

[0018] The present invention also provides a host computer, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor, when executing the computer program, implements the register access instruction generation method as described above.

[0019] The present invention also provides a hardware device, comprising: Physical register resources are used to divide the space into a private register pool and a shared register pool, wherein the shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles. A shared base address register is used to store the shared base address of the shared register pool during the kernel startup phase; The instruction decoding unit is used to receive register access instructions from the host, decode the register access instructions, determine the addressing mode corresponding to the register access instructions, and the register access instructions include the target access instructions obtained by the host after converting the access statements for cross-thread bundle shared variables in the kernel code. The instruction execution unit is configured to access the corresponding shared register in the shared register pool based on the shared base address stored in the shared base address register and the static offset carried in the register access instruction when the addressing mode is shared mode. The static offset is the offset relative to the shared base address that the host pre-allocates in the shared register pool for the corresponding cross-thread bundle shared variable.

[0020] A hardware device according to the present invention further includes: A shared access status register is used to record the access status of each currently active thread bundle to each shared register in the shared register pool; The instruction execution unit is further configured to query the access status recorded in the shared access status register when performing cross-thread bundle register access operations in the shared mode, so as to perform access conflict detection. The static offset is the offset relative to the shared base address that the host pre-allocates in the shared register pool for the corresponding cross-thread bundle shared variable.

[0021] The present invention also provides a server, including a host as described above, and a hardware device as described above that is communicatively connected to the host.

[0022] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the register access instruction generation method or the register access method as described above.

[0023] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the register access instruction generation method or the register access method described above.

[0024] This invention provides a register access instruction generation method, register access method, host, device, server, and medium. By obtaining cross-thread bundle shared variables declared in the kernel code and dividing physical register resources into a private register pool and a shared register pool accessible to all thread bundles based on the total private register requirements of the kernel code running on the hardware device, this invention overcomes the strict isolation limitations of physical registers at the thread bundle level in traditional architectures while ensuring the original thread bundle private register resource requirements are met. This allows potentially idle register resources to be shared and reused, thereby improving the overall resource utilization of on-chip physical registers. Simultaneously, this invention defines a unified shared base address for the shared register pool and assigns static offsets that can be determined at compile time to each cross-thread bundle shared variable. This directly converts access statements in the kernel code into target access instructions based on the shared base address and static offsets. This direct addressing and instruction generation mechanism based on a unified base address and static offsets enables cross-thread bundle data exchange to be completed directly at the high-speed register level, avoiding the memory access latency and synchronization overhead caused by the slower shared memory or global memory required in traditional cross-thread bundle communication. Attached Figure Description

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

[0026] Figure 1 This is a flowchart illustrating the register access instruction generation method provided by the present invention; Figure 2 This is a schematic diagram of the structure of the private register pool and the shared register pool provided by the present invention; Figure 3 This is one of the flowcharts illustrating the register access method provided by the present invention; Figure 4 This is the second flowchart of the register access method provided by the present invention; Figure 5 This is a schematic diagram of the register access instruction generation device provided by the present invention; Figure 6 This is a schematic diagram of the register access device provided by the present invention; Figure 7 This is a schematic diagram of the hardware device provided by the present invention; Figure 8 This is a schematic diagram of the host structure provided by the present invention. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention. It should be noted that all actions involving the acquisition of instructions, information, or data in this invention are performed in accordance with the relevant data protection laws and policies of the country where the invention is located, and with authorization from the owner of the corresponding device.

[0028] In existing AI device programming and hardware execution models, computing units typically possess a fixed number of physical register files. Here, the register file (also known as the register stack) is a high-speed static random-access memory (SRAM) on the processor used to store the values ​​of all registers. When the kernel starts, each thread is allocated a set of private thread-local registers (TLRs), which are organized and managed in units of thread bundles (Warp). It should be understood that TLRs are thread-private registers, hardware resources exclusive to each thread and invisible to other threads.

[0029] In existing hardware architectures and execution models, the total number of physical registers on each processor is subject to a fixed hardware limit, and the number of TLRs required for each warp is statically determined during kernel compilation. During kernel execution, the hardware dynamically allocates a contiguous, independent block of registers in the register file for each active warp. The starting address of this register block is typically called the private base address (denoted as WARP_BASE). Here, the private base address refers to the starting address of the private registers (i.e., TLRs) of all threads within a warp in the physical register file; each warp has its own independent WARP_BASE. In this model, the compiler's role is limited to calculating register requirements and generating addressing code based on WARP_BASE for each thread. WARP_BASE is dynamically allocated and managed by the hardware at runtime, transparent to the software layer.

[0030] This traditional register management and addressing method has a key physical limitation: register access is strictly confined to within a Warp; a Warp cannot access a register block allocated to another Warp. While this mechanism achieves strict isolation and security between threads and Warps, the increasing demand for fine-grained parallel computing in fields such as artificial intelligence and high-performance computing has gradually revealed certain shortcomings in existing technologies.

[0031] First, there is a lack of fast communication mechanisms across warp bundles. Because registers are strictly isolated at the warp level, data exchange between warps must be done through slower shared or global memory. This communication method introduces significant memory access latency and synchronization overhead, limiting the performance of parallel algorithms that require fine-grained, cross-warp collaboration.

[0032] Secondly, rigid hardware resource utilization leads to resource waste. The physical TLR is statically divided into completely isolated Warp private register blocks. In actual operation scenarios, even if some Warp actually uses fewer registers than their statically allocated quota, these idle private registers cannot be utilized by other Warp that urgently need resources. This rigid resource allocation mechanism results in low utilization of on-chip physical register resources.

[0033] Furthermore, the programming model lacks high-level shared abstractions. The current GPU programming model only provides low-level intra-warp operation primitives and does not support register-level sharing across warps at all. This forces developers to use inefficient alternatives, such as relying on shared memory for data exchange, when dealing with cross-warp data collaboration.

[0034] To address the aforementioned shortcomings, this invention provides a register access instruction generation method. By dividing a pool of shared registers that can be accessed collaboratively based on the demand for private registers, and using a unified shared base address combined with a static offset to generate a target access instruction that directly accesses the shared register pool, this method breaks the isolation limitation of Warp-level registers in traditional architectures, achieves efficient register sharing across thread bundles, improves the resource utilization of physical registers and cross-Warp communication performance, thereby overcoming the aforementioned shortcomings.

[0035] Figure 1 This is a flowchart illustrating the register access instruction generation method provided by the present invention, as shown below. Figure 1 As shown, this method is applied to a host, and the method includes: Step 110: Obtain the kernel code to be processed and extract at least one cross-thread bundle shared variable declared in the kernel code.

[0036] It should be noted that the method provided in this embodiment of the invention can be executed by a register access instruction generation device, which can be implemented in at least one way, either software or hardware, and configured in a host computer. The host computer can be a general-purpose computer system containing components such as a central processing unit (CPU) and memory, or other computing devices containing dedicated processors, responsible for tasks such as kernel code compilation, task distribution, and instruction generation. Hardware devices refer to artificial intelligence devices containing a large number of computing units, such as graphics processing units (GPUs), general-purpose computing on graphics processing units (GPGPUs), and tensor processing units (TPUs), primarily used for executing parallel computing tasks.

[0037] Specifically, kernel code typically refers to program code that executes in parallel on hardware devices (such as GPUs). A host can obtain kernel code by reading source code files stored locally or in the cloud, or by receiving kernel code dynamically compiled at runtime by upper-layer applications.

[0038] In high-performance computing and parallel programming, threads are the basic unit of GPU execution, and warps are the basic thread unit of GPU execution. For example, in a GPU architecture, a warp typically contains 32 or 64 threads that execute the same instructions in a lockstep manner. In traditional GPU programming models, register resources are statically partitioned into completely isolated warp-private register blocks. This means that even if some warps actually use fewer registers than allocated, the idle registers cannot be utilized by other warps, and data exchange between warps must be done through slower shared memory or global memory, introducing significant latency and synchronization overhead.

[0039] To address this issue, embodiments of the present invention introduce a new storage class at the language level (i.e., a cross-warp shared storage class, for example, represented using the `cross_warp_shared` keyword), enabling programmers to explicitly declare cross-warp shared variables in kernel code. This allows for the secure allocation and use of cross-warp shared register resources. It should be understood that declaring cross-warp shared variables in kernel code provides developers with a high-level sharing abstraction, explicitly instructing the compiler that these variables need to be decoupled from traditional Warp-private isolation mechanisms, thereby leveraging low-latency physical registers to achieve high-speed, secure communication and data exchange across Warp instances.

[0040] After the host obtains the kernel code to be compiled, it first performs lexical and syntactic analysis to identify and extract all variables explicitly declared as cross-warp shared variables, i.e., variables declared with the keyword `cross_warp_shared`. These variables are cross-warp shared variables. By extracting these cross-warp shared variables, it is possible to accurately distinguish which variables need to use the newly introduced shared base addressing mode, thus providing a clear data foundation for subsequent calculations of the total shared space requirements, static partitioning of physical register resources, and allocation of corresponding static offsets for each shared variable.

[0041] Step 120: Determine the total private register requirement of the kernel code when it runs on the hardware device, and based on the total private register requirement, divide the physical register resources of the hardware device into a private register pool and a shared register pool. The shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles.

[0042] Specifically, physical register resources (i.e., physical register files) are a high-speed SRAM within the processor of a hardware device, used to store the values ​​of all registers. They are the fastest on-chip storage resource to access when performing computational tasks. In traditional architectures, physical registers are only used as thread-local registers (TLRs), and are strictly isolated between warps.

[0043] To achieve register-level sharing across warp, this embodiment of the invention performs static allocation of physical register resources during the compilation phase. Specifically, the host first analyzes the kernel code to determine the total number of private registers required when the code executes on the target hardware device. Here, the total number of private registers refers to the total number of thread-local registers (TLRs) required by all concurrently executing thread bundles on the target hardware device when running the kernel code. When determining this requirement, the host first determines the number of private registers required by each thread based on the complexity and instruction requirements of the kernel code. Then, based on the number of private registers, the thread bundle size of the hardware device (such as the typical 32 or 64 threads) and the maximum number of concurrent thread bundles (i.e., the maximum number of warp that can be active simultaneously under the hardware support or current configuration), the total number of private registers is accurately calculated.

[0044] After determining the total private register requirement, the host further logically partitions the physical register resources of the hardware devices based on this requirement. For example, a contiguous space within the physical register resources that matches the total private register requirement can be divided into a private register pool (also called a Warp private register pool). This portion of the resources is used independently by each Warp to ensure backward compatibility with the existing GPU architecture and execution model. It should be understood that the private register pool is a logical collection of all thread-local register resources (i.e., TLR resources). During kernel startup and actual runtime, the hardware dynamically allocates this private register pool to each active Warp, thereby dividing it into multiple independent private register blocks. Each private register block is contiguously allocated to a specific Warp and has its own independent starting address (i.e., WARP_BASE). The registers within it are entirely for the private use of each thread within that Warp.

[0045] Then, the remaining available space in the physical register resources, excluding the private register pool, is directly divided into a shared register pool (also known as the cross-Warp shared register pool). This part of the shared register pool is the portion stripped from the total resources after deducting all Warp-specific requirements, and includes one or more shared registers that can be accessed collaboratively by all active Warp instances within the current kernel.

[0046] By first ensuring private needs and then allocating the remaining resources to the shared pool, the static allocation mechanism described above breaks the limitation of traditional physical registers being completely private and isolated, maximizing the utilization of hardware resources while ensuring security.

[0047] Step 130: Determine the shared base address corresponding to the shared register pool, and allocate a static offset relative to the shared base address for each cross-thread bundle shared variable in the shared register pool.

[0048] It should be noted that in the traditional architecture, each Warp is allocated a contiguous block of private registers in the physical register file, the starting address of which is called the private base address (WARP_BASE). Each thread accesses the private registers through this private base address, its own thread channel identifier (i.e., the thread's index within its own Warp), and a local offset.

[0049] The embodiments of this invention introduce a hierarchical base addressing mechanism. Specifically, the hardware device provides a new addressing mode that supports multiple parallel register base addresses. In addition to supporting the traditional WARP_BASE for accessing Warp private registers, a new shared base address (denoted as SHARED_BASE) is added specifically for accessing the shared register pool.

[0050] Specifically, after completing the aforementioned register resource allocation, the host determines the starting position of the shared register pool within the physical register resources and configures it as this unified shared base address. Since the entire shared register pool uses this single shared base address, for each extracted cross-thread bundle shared variable, the host allocates a static offset (denoted as `static_offset`) relative to the shared base address within the shared register pool during compilation, ensuring that these shared variables are linearly and continuously arranged within the shared register pool. This static offset is a fixed constant determined at compile time, representing the specific storage location of the shared variable within the shared register pool. Because all shared variables are linearly and continuously arranged within the shared register pool, this allocation method, combining a single shared base address and a static offset, not only avoids the runtime overhead of dynamic base address calculation but also simplifies the compiler's address calculation and management logic.

[0051] Step 140: Based on the shared base address and the static offset, convert the access statements in the kernel code for the cross-thread bundle shared variables into target access instructions. The target access instructions are used to instruct the hardware device to access the corresponding shared registers in the shared register pool based on the shared base address and the static offset.

[0052] Specifically, after determining the shared base address and corresponding static offset of each cross-thread bundle shared variable in physical space, the host, during the instruction generation phase, converts or replaces all read / write access statements for these high-level abstract shared variables in the kernel code with low-level target access instructions. These target access instructions internally encode or implicitly contain addressing modes based on the shared base address and static offset. When these instructions are finally distributed to the hardware device for execution, the hardware device can obtain the corresponding shared base address and the static offset embedded in the instruction by decoding the target access instruction. Then, by adding the two together, it can directly locate the corresponding physical register in the shared register for data read / write.

[0053] The method provided in this invention obtains cross-thread bundle shared variables declared in the kernel code and, based on the total private register requirements of the kernel code running on the hardware device, divides physical register resources into a private register pool and a shared register pool accessible to all thread bundles. This overcomes the strict isolation limitations of physical registers at the thread bundle level in traditional architectures while ensuring the original thread bundle private register resource requirements are met. It allows potentially idle register resources to be shared and reused, thereby improving the overall resource utilization of on-chip physical registers. Simultaneously, this invention determines a unified shared base address for the shared register pool and assigns static offsets that can be determined at compile time to each cross-thread bundle shared variable. This directly translates access statements in the kernel code into target access instructions based on the shared base address and static offsets. This direct addressing and instruction generation mechanism based on a unified base address and static offsets enables cross-thread bundle data exchange to be completed directly at the high-speed register level, avoiding the memory access latency and synchronization overhead caused by the slower shared memory or global memory required in traditional cross-thread bundle communication.

[0054] Based on the above embodiments, step 120 specifically includes: Step 121: Based on the kernel code, determine the number of private registers required for each thread.

[0055] Specifically, the compiler in the host can perform lexical and dependency analysis on the kernel code through the built-in register allocation algorithm, thereby determining the number of private registers (denoted as R_per_thread) that each thread in the current kernel code must use to complete its independent computational task.

[0056] Step 122: Calculate the total private register requirement based on the number of private registers, the thread bundle size of the hardware device, and the maximum number of concurrent thread bundles.

[0057] Specifically, the thread bundle size (denoted as Warp_Size) refers to the number of threads contained in a single thread bundle, such as 32 or 64; the maximum number of concurrent thread bundles (denoted as Max_Concurrent_Warps) refers to the upper limit of the number of active thread bundles that the target hardware device can simultaneously support in order to maintain high occupancy.

[0058] The host multiplies the number of private registers for each thread by the thread bundle size to obtain the private register requirement for a single thread bundle. This requirement is then multiplied by the maximum number of concurrent thread bundles to calculate the total private register requirement needed to satisfy the current kernel's full-load parallel execution. The specific formula is: Total_Private = R_per_thread Warp_Size Max_Concurrent_Warps, where Total_Private represents the total private register requirement.

[0059] Step 123: If the total private register requirement does not exceed the physical register resource, the space in the physical register resource that matches the size of the total private register requirement is divided into the private register pool. Step 124: Divide the remaining available space in the physical register resources, excluding the private register pool, into the shared register pool; Specifically, during compilation, the host verifies whether the calculated total private register requirement exceeds the fixed physical register resource limit of the hardware. If the limit is not exceeded, the corresponding size of physical register space can be allocated to the private register pool. After allocating the private register pool, the remaining available space in the physical register resources other than the private register pool is allocated to the shared register pool.

[0060] Figure 2 This is a schematic diagram of the structure of the private register pool and the shared register pool provided by the present invention, as shown below. Figure 2 As shown, the physical register resources are logically divided into two parts, one of which is located in Figure 2 The private register pool shown on the right contains private register blocks allocated to each active thread bundle, such as Warp0, Warp1, and Warp2. These are organized in the traditional Thread Local Register (TLR) format, ensuring backward compatibility and execution isolation within each thread bundle. Another part is located in... Figure 2 The shared register pool shown on the left, after deducting the space occupied by private needs from the total physical register resources, aggregates all remaining idle register space in a globally visible logical pool, namely the shared register pool. This pool contains multiple shared registers (such as...). Figure 2 The shared registers shown (such as A, B, and C) are accessible across Warp by all active thread bundles within the kernel.

[0061] The method provided in this invention accurately calculates the private register requirements of the kernel execution by combining hardware configuration, and transforms all remaining physical register space into a global shared register pool while ensuring the private requirements of traditional thread bundles. This breaks the isolation restrictions caused by the static division of traditional physical register resources into completely independent private register blocks, allowing idle registers to be reused by other thread bundles, thereby improving the utilization rate of underlying hardware resources and the performance of fine-grained parallel collaboration.

[0062] Based on any of the above embodiments, step 130, determining the shared base address corresponding to the shared register pool, includes: Step 131: Determine the end address of the private register pool in the physical register resource; Step 132: Configure the end address as the shared base address of the shared register pool so that the shared register pool and the private register pool are physically contiguous.

[0063] Specifically, in the physical register file (i.e., physical register resources) at the hardware level, the physical addresses of registers typically increase linearly from zero. Since the host prioritizes deducting and satisfying the space requirements of the private register pool during static partitioning, the private register pool occupies the first contiguous space starting from the address origin. The size of this contiguous space is the total private register requirement calculated above, and this requirement itself corresponds to the exact ending address of the private register pool within the physical register resources.

[0064] Subsequently, the host directly configures the end address of the aforementioned private register pool as the shared base address (SHARED_BASE) uniquely used by the entire shared register pool. This means that the shared register pool is constructed immediately adjacent to the end of the private register pool. Based on this shared base address, shared variables (such as shared registers A, B, and C) can all be linearly and continuously arranged with static offsets relative to this base address.

[0065] The method provided in this invention uses the end address of the private register pool as the shared base address of the shared register pool, so that the two logic pools form a linear and continuous layout in the underlying physical space. This not only eliminates the memory space fragmentation that may be caused by discrete allocation and achieves the maximum resource utilization, but also minimizes the modification of the hardware addressing logic. Only one register (for storing the shared base address) needs to be added to complete the management of multiple base addresses, simplifying the implementation complexity of the compiler.

[0066] Based on any of the above embodiments, step 130, which involves allocating a static offset relative to the shared base address for each cross-thread bundle shared variable in the shared register pool, includes: Step 133: Obtain the data type size of each cross-thread bundle shared variable; Step 134: According to the declaration order of each cross-thread bundle shared variable, and based on the data type size of each cross-thread bundle shared variable, allocate the static offset for each cross-thread bundle shared variable in the shared register pool so that each cross-thread bundle shared variable is arranged linearly and continuously in the shared register pool.

[0067] Specifically, during compilation, the compiler uses a built-in register allocation algorithm to process cross-thread bundle shared variable declarations extracted from the kernel code (such as scalars or arrays explicitly declared by the user using the keyword `cross_warp_shared`). The compiler calculates the storage size corresponding to the data type (such as floating-point, integer, or array of a certain length) of each shared variable, and then determines the number of physical registers that the variable actually needs to occupy at the hardware level (i.e., the data type size).

[0068] After determining the number of registers occupied by each shared variable (i.e., the data type size), the compiler sets an initial offset of zero. Then, it iterates through these variables in the order they are declared in the kernel code, assigning the current offset value directly as the static offset of the current variable, and then adding the data type size of the variable to the current offset value, and so on.

[0069] For example, such as Figure 2 As shown, shared register A corresponds to the first declared shared variable, for which a static offset + 0 is allocated. Shared register B corresponds to the second shared variable declared immediately after it. Since the data type size of the first shared variable is 4, a static offset + 4 is allocated to the second shared variable, and so on. This ensures that all shared variables present a linear and contiguous memory layout in the shared register pool. It should be understood that for each shared register in the shared register pool, its physical address is determined by the shared base address plus the static offset. Therefore, Figure 2 The "+0", "+4", "+8" etc. shown in the shared register pool directly reflect the mathematical logic of this address accumulation, indicating the relative position of the shared variable in the shared register pool from the starting address (i.e., the shared base address) (e.g., deviating from 0 units, deviating from 4 units, etc.).

[0070] The method provided in this invention obtains the data type size of the shared variable across thread bundles and allocates linear and continuous static offsets to it according to the declaration order. This avoids the complex multi-base address management and runtime dynamic address calculation overhead, which not only simplifies the implementation of the compiler's linear offset allocation algorithm, but also ensures the continuous layout of the shared register pool without storage fragmentation, greatly improving addressing efficiency and performance determinism.

[0071] Based on any of the above embodiments, before step 134, the method further includes: Analyze the lifetime of each cross-thread bundle shared variable in the kernel code to identify at least two target cross-thread bundle shared variables whose lifetimes do not overlap; Accordingly, in step 134, allocating the static offset for each cross-thread bundle shared variable in the shared register pool includes: In the shared register pool, the same static offset is assigned to the at least two target cross-thread bundle shared variables to indicate that the at least two target cross-thread bundle shared variables reuse the same physical register at runtime.

[0072] Specifically, before allocating static offsets, the compiler in the host machine uses control flow and data flow analysis techniques to perform a detailed lifecycle analysis of the lifetimes (i.e., the time from the first assignment to the last read) of various cross-thread bundle shared variables in the kernel code. Through this analysis, the compiler can accurately identify those shared variables that will not be used simultaneously at any point during kernel execution, and determine these variables whose lifecycles do not overlap at all as target cross-thread bundle shared variables.

[0073] Since these target cross-thread bundle shared variables will not experience access conflicts over time, the compiler breaks the conventional linear incrementing allocation logic when allocating static offsets for these target cross-thread bundle shared variables, directly assigning them the same static offset constant value. When the hardware device executes the translated target access instruction at runtime, because the static offsets fixed in the instruction are the same, they will be mapped and read / written to the same physical register unit in the shared register pool.

[0074] The method provided in this invention introduces a lifecycle analysis mechanism into the compiler's register allocation algorithm and allocates the same static offset to cross-thread bundle shared variables with non-overlapping lifecycles, thereby realizing time-sharing reuse of the same physical register in different execution stages. This not only supports the most aggressive compiler optimizations but also maximizes the utilization of on-chip physical register resources without increasing hardware capacity.

[0075] Based on any of the above embodiments, step 140 specifically includes: Step 141: Analyze the access statements in the kernel code for the shared variables across each thread bundle to determine the corresponding shared access mode; Step 142: Based on the shared access mode, merge or rearrange the memory access operations corresponding to the access statements to obtain an optimized memory access operation sequence. Step 143: Based on the shared base address and the static offset, convert the optimized memory access operation sequence into the target access instruction; The target access instruction is either a hardware atomic operation instruction or a normal memory access instruction, and the static offset is fixed in the target access instruction as a compile-time constant.

[0076] Specifically, when the compiler in the host machine processes the kernel code, it performs in-depth access pattern analysis on read and write access statements for shared variables across thread bundles. This includes analyzing the frequency of reads and writes to shared registers, dependencies, and loop structures to determine the corresponding shared access patterns. Here, shared access patterns refer to the characteristics of the kernel code's access behavior to these shared variables at runtime, such as frequent sequential reads, concurrent accumulation operations across thread bundles, or array index access with regular step sizes.

[0077] Once the specific shared access pattern is identified, the compiler will use these analysis results to perform aggressive optimizations. For example, if multiple independent reads are found for shared variables at consecutive static offsets, the compiler can merge these memory access operations into a single wide bit-width read; or, through instruction reordering techniques, it can interleave memory access instructions for shared registers with other independent computation instructions, thereby generating a memory access operation sequence with hidden latency and optimal execution efficiency.

[0078] Finally, during the code generation phase, the compiler generates specific hardware-level machine code based on the optimized sequence, i.e., converts it into target access instructions. For example, if the access statement involves ordinary read / write operations (such as index access of array elements), ordinary memory access instructions (such as the MOV instruction) are generated; if multiple threads concurrently update the same variable, hardware atomic operation instructions (such as the ATOMIC_ADD instruction) are generated. Furthermore, through the offset constant propagation mechanism, the previously allocated static offset no longer needs to be dynamically calculated through registers at runtime, but is directly hard-coded as compile-time constants within these target access instructions. For example, the form of the target access instruction can be an addressing mode based on the base address register identifier plus a fixed constant (i.e., a static offset).

[0079] The method provided in this invention analyzes the shared access patterns of kernel code to perform instruction-level merging and rearrangement optimization, and directly embeds static offsets as compile-time constants in the generated hardware atomic operation instructions or ordinary memory access instructions. This eliminates the computational overhead of dynamically calculating base addresses and offsets at runtime in traditional architectures, which not only makes the latency of all shared accesses completely deterministic, but also improves the throughput of the underlying execution pipeline.

[0080] Based on any of the above embodiments, the method further includes: Generate initialization instructions, which instruct the hardware device to load the shared base address into the shared base address register when the kernel starts.

[0081] Specifically, in order to support the hierarchical base addressing mode, the hardware device is configured with a dedicated hardware register, namely the shared base address register (such as the SR0 register). This register is globally visible to all active thread bundles and is specifically used to store the starting physical address of the shared register pool (i.e., the shared base address).

[0082] When the host compiles the kernel code, it generates one or more dedicated initialization instructions (such as assignment instructions) at the very beginning of the kernel entry point code sequence. When the hardware device receives the task and starts the kernel, it first executes the initialization instruction, directly loading and storing the unique shared base address constant value determined by the host during the static partitioning phase into the shared base address register. This establishes a unified addressing base for all subsequent cross-thread bundle coordinated memory access operations.

[0083] The method provided by this invention generates a special initialization instruction during the compilation stage, enabling the hardware device to preload a unique shared base address into a dedicated shared base address register when the kernel starts. On the one hand, this provides a globally unified and fast-obtained base address for subsequent target access instructions with fixed static offsets. On the other hand, it minimizes the modification of hardware addressing logic, requiring only the addition of a single shared base address register to achieve cross-thread bundle register-level sharing, thus achieving better compatibility with existing hardware architectures.

[0084] Based on any embodiment of the register access instruction generation method executed on the host side described above, this embodiment of the invention provides a corresponding register access method executed on the hardware device side. Figure 3 This is one of the flowcharts illustrating the register access method provided by the present invention, such as... Figure 3 As shown, this method is applied to a hardware device whose physical register resources are divided into a private register pool and a shared register pool based on the total private register requirements during kernel code runtime. The shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles. The method includes: Step 310: Receive register access instructions from the host, the register access instructions including the target access instructions obtained by the host after converting the access statements for cross-thread bundle shared variables in the kernel code.

[0085] Specifically, when the kernel code starts and is distributed to hardware devices (such as GPUs) for execution, the hardware devices receive and buffer a series of machine instructions (including register access instructions) generated by the host during compilation. These instruction streams contain low-level target access instructions generated by the host during the previous compilation phase, which transform high-level abstract access statements in the kernel code for cross-thread bundle shared variables. These target access instructions have their instruction format pre-defined with the key addressing parameters required to access the shared register pool.

[0086] Step 320: Decode the register access instruction to determine the addressing mode corresponding to the register access instruction.

[0087] Specifically, when a register access instruction enters the execution pipeline of the hardware device, the instruction decoding unit decodes the acquired register access instruction. Because this embodiment of the invention introduces a hierarchical base addressing execution model at the hardware level—that is, in addition to supporting the traditional addressing mode for accessing private registers of each warp—it also adds a multi-base addressing mode that supports parallel addressing. Therefore, by parsing the instruction's opcode or specific addressing flags, the decoding unit can accurately identify and determine the specific addressing mode used by the instruction, thereby determining whether the instruction requests access to traditionally isolated warp private registers in a private mode, or access to registers shared across warps in a shared mode.

[0088] Step 330: When the addressing mode is shared mode, obtain the shared base address corresponding to the shared register pool based on the register identifier carried in the register access instruction, and determine the first target physical address according to the shared base address and the static offset carried in the register access instruction. The static offset is the offset relative to the shared base address that the host pre-allocates in the shared register pool for the corresponding cross-thread bundle shared variable.

[0089] Specifically, when the instruction decoding unit determines that the addressing mode of the current instruction is shared mode, it indicates that the current register access instruction is a target access instruction. At this time, the hardware device will start the address calculation logic for the shared register pool. First, the hardware pipeline will directly read the shared base address (SHARED_BASE) that was loaded during the kernel startup phase from the specific register identifier carried in the instruction (such as an identifier pointing to the dedicated SR0 register).

[0090] Subsequently, the hardware device extracts the static offset (static_offset) hard-coded as a compile-time constant from the target access instruction and performs a simple addition operation with the read unified shared base address. The result of this operation (i.e., the shared base address plus the static offset) constitutes the precise first target physical address of the cross-thread bundle shared variable in the underlying physical register file. This address calculation process, because it does not rely on any dynamic variables such as thread channel identifiers, eliminates the overhead of dynamic base address calculation in traditional architectures. It should be understood that the static offset read by the hardware device when executing instructions is not dynamically calculated at kernel runtime, but is statically determined by the host-side compiler during the early compilation stage based on the corresponding cross-thread bundle shared variables and directly embedded in the issued target access instruction. After decoding instructions in shared addressing mode, the hardware device only needs to directly extract the static offset carried in the instruction and add it to the shared base address to accurately locate the specific physical register, thereby eliminating the runtime dynamic address calculation overhead and ensuring extremely low latency for cross-thread bundle data sharing. Step 340: Access the corresponding shared register in the shared register pool according to the first target physical address.

[0091] Specifically, after obtaining the first target physical address, the instruction execution unit of the hardware device will directly initiate a read or write request to the physical register file, thereby performing high-speed data access to the physical register unit in the shared register pool corresponding to that physical address. Whether it is a normal register read or write, or a hardware atomic addition operation executed concurrently across threads, it directly operates on the high-speed SRAM unit pointed to by that physical address (i.e., the first target physical address).

[0092] The method provided in this invention parses the target access instruction and identifies the shared addressing mode on the hardware device side. It quickly obtains the globally unique shared base address using the register identifier carried in the instruction and directly calculates the target physical address by combining it with the static offset embedded in the instruction. This achieves efficient access to shared registers in the underlying hardware pipeline. This invention eliminates the need for data exchange between different thread bundles to rely on slow shared memory or global memory. It not only reduces communication latency and synchronization overhead in fine-grained cross-thread bundle collaboration but also improves the utilization rate of physical register resources through minimal modification of addressing logic and simple static address calculation.

[0093] Based on any of the above embodiments, step 340 specifically includes: Step 341: Obtain the current access status of the target shared register corresponding to the first target physical address through the configured shared access status register. The shared access status register records the access status of each shared register in the shared register pool. Step 342: Based on the current access state, perform conflict detection on the current thread's access to the target shared register; Step 343: If no conflict is detected, perform a hardware atomic operation based on the shared base address for the target shared register and update the access status of the target shared register in the shared access status register.

[0094] Specifically, because the shared register pool is globally visible, different warps may attempt to read from or write to the same shared register at the same time. To achieve hardware-level cross-warp synchronization, a dedicated shared access status register is added inside the hardware device. When the execution pipeline is about to access the first target physical address, it will first query this status register to obtain information on whether the target shared register corresponding to that address is currently occupied or locked by another warp.

[0095] The instruction execution unit of the hardware device assesses, based on the acquired current access state, whether the read / write or atomic operation to be executed by the current thread bundle (i.e., the thread bundle currently accessing the first target physical address) will cause a data contention with other ongoing operations. For example, if the current access state indicates that the register (i.e., the register corresponding to the first target physical address) is in the exclusive write cycle of another warp, an access conflict is detected, and the operation of the current warp may be briefly suspended or retried.

[0096] If the current access is confirmed to be safe (i.e., no conflict is detected), the hardware execution unit will directly execute the memory access operation indicated by the instruction on the target shared register, such as an atomic accumulation based on a single shared base address (e.g., ATOMIC_ADD), to ensure data integrity. Simultaneously, the execution unit will modify and update the corresponding status bits in the shared access status register to broadcast the latest access status of that shared register to other active warps in the system.

[0097] The method provided in this invention introduces a dedicated shared access status register at the hardware level for conflict detection and performs cross-thread bundle data read and write operations in conjunction with hardware atomic operations. This enables efficient and secure cross-thread bundle data consistency assurance at the register level without relying on slow shared memory and complex explicit synchronization barriers, thereby optimizing the execution performance of fine-grained cooperative algorithms.

[0098] Based on any of the above embodiments, the method further includes: When the addressing mode is private mode, the second target physical address is calculated based on the private base address of the current thread, the thread channel identifier, and the local offset, and the corresponding private register in the private register pool is accessed according to the second target physical address.

[0099] Specifically, when the instruction decoding unit of the hardware device determines that the current instruction is not a cross-thread bundle shared access instruction, but a traditional ordinary instruction for accessing the thread-local register (TLR), its addressing mode is determined to be private mode. At this time, the hardware device will revert to the traditional dynamic address calculation logic: extract the private base address (WARP_BASE) specific to the current thread bundle, combine it with the current thread's index within its respective warp (i.e., the thread channel identifier, denoted as Lane_ID), and the local offset (Offset) carried in the instruction for each thread, to dynamically calculate the second target physical address, for example, the calculation formula is WARP_BASE + Lane_ID. R_per_thread+Offset. Subsequently, the hardware pipeline will accurately hit and access the private register unit exclusive to that thread in the physically isolated private register pool based on this second target physical address.

[0100] The method provided by the embodiments of the present invention distinguishes between shared mode and private mode during the instruction decoding and execution stages, and adopts the traditional dynamic addressing mechanism based on thread channel identifier and private base address in private mode. This ensures that the unified base address architecture of the present invention has good backward compatibility with the existing GPU programming model and hardware execution model, so that thread-private computing tasks and cross-thread bundle shared tasks can run in parallel on the same physical hardware without interfering with each other.

[0101] Based on any of the above embodiments Figure 4 This is the second flowchart illustrating the register access method provided by the present invention, as shown below. Figure 4 As shown, this embodiment of the invention further details the complete logic flow for implementing register access in the underlying execution pipeline of a hardware device. Specifically, it includes the following steps: First, the pipeline enters the instruction receiving phase. The hardware device retrieves the machine instruction stream compiled and issued by the host from the instruction cache. The instructions received at this stage include both traditional local register access instructions used to complete independent computation tasks for each thread, and target access instructions carrying static offsets, which are converted from high-level cross-thread bundle shared variables by the host during compilation.

[0102] Next, the instruction decoding stage begins. The instruction decoding unit of the hardware device parses the received machine instruction, extracting the opcode, operands, and specific register flags. Through decoding, the underlying hardware can accurately identify the specific operational intent of the current instruction and the register addressing parameters it relies on.

[0103] Next, the addressing mode determination phase begins. The instruction decoding unit routes the current instruction to different address calculation logic branches based on the parsed register identifier or specific instruction type. If the instruction references a base register specifically pointing to the shared register pool (e.g., the SR0 register storing SHARED_BASE), it is determined that the current instruction is in shared mode; otherwise, if the instruction uses regular thread-local register (TLR) operands, it is determined that the current instruction is in private mode.

[0104] When the system is determined to be in private mode, the pipeline starts from... Figure 4 The left branch shown enters the private address calculation stage. At this point, the hardware device reverts to the traditional dynamic address calculation logic: based on the private base address (WARP_BASE) of the current thread's thread bundle, the channel identifier (Lane_ID) of the thread within its thread bundle, and the local offset carried in the instruction, dynamic multiplication and addition operations are performed to obtain the second target physical address. This process ensures the execution isolation of each thread within the thread bundle, maintaining the traditional private calculation state.

[0105] When the system is determined to be in shared mode, the pipeline starts from... Figure 4 The right-hand branch, as shown, proceeds to the shared address calculation stage. Here, the hardware directly reads the unified shared base address configured in the globally visible shared base address register and adds it directly to the static offset hard-coded within the target access instruction to obtain the first target physical address. This process achieves precise location of the shared physical unit with extremely low computational overhead.

[0106] Finally, both addressing branches converge into the register access phase. Whether the private physical address is calculated through dynamic addressing or the shared physical address is obtained by adding a static offset to a unified base address, the execution unit of the hardware device will eventually send these exact physical addresses to the underlying physical register resources and efficiently perform data read, write, or hardware-level atomic operations on the corresponding SRAM memory units.

[0107] The register access instruction generation apparatus provided by the present invention is described below. The register access instruction generation apparatus described below and the register access instruction generation method described above can be referred to in correspondence.

[0108] Based on any of the above embodiments Figure 5 This is a schematic diagram of the register access instruction generation device provided by the present invention, as shown below. Figure 5 As shown, the device is used in a host computer and includes: Extraction module 510 is used to obtain the kernel code to be processed and extract at least one cross-thread bundle shared variable declared in the kernel code; The partitioning module 520 is used to determine the total private register requirement of the kernel code when it runs on the hardware device, and based on the total private register requirement, divide the physical register resources of the hardware device into a private register pool and a shared register pool. The shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles. The allocation module 530 is used to determine the shared base address corresponding to the shared register pool and allocate a static offset relative to the shared base address in the shared register pool for each cross-thread bundle shared variable; The conversion module 540 is used to convert the access statements for the cross-thread bundle shared variables in the kernel code into target access instructions based on the shared base address and the static offset. The target access instructions are used to instruct the hardware device to access the corresponding shared registers in the shared register pool based on the shared base address and the static offset.

[0109] The apparatus provided in this invention divides physical register resources into a private register pool that ensures compatibility and a shared register pool that supports cross-thread bundle collaboration during compilation. It also introduces an addressing allocation mechanism based on a single shared base address and a static offset. This enables cross-thread bundle shared variables in the kernel code to be compiled into low-level target access instructions that directly access shared registers. As a result, efficient register-level data sharing with deterministic latency at the thread bundle level is achieved without adding complex hardware logic. This improves the execution performance of fine-grained cross-thread bundle collaboration algorithms and the overall utilization of hardware register resources.

[0110] Based on any of the above embodiments, the partitioning module is specifically used for: Based on the kernel code, determine the number of private registers required for each thread; The total private register requirement is calculated based on the number of private registers, the thread bundle size of the hardware device, and the maximum number of concurrent thread bundles. If the total private register requirement does not exceed the physical register resources, the space in the physical register resources that matches the size of the total private register requirement is divided into the private register pool. The remaining available space in the physical register resources, excluding the private register pool, is divided into the shared register pool.

[0111] Based on any of the above embodiments, the allocation module is specifically used for: Determine the end address of the private register pool within the physical register resource; Configure the end address as the shared base address of the shared register pool so that the shared register pool and the private register pool are physically contiguous.

[0112] Based on any of the above embodiments, the allocation module is specifically used for: Obtain the data type size of each cross-thread bundle shared variable; Based on the declaration order of each cross-thread bundle shared variable and the data type size of each cross-thread bundle shared variable, the static offset is allocated to each cross-thread bundle shared variable in the shared register pool so that each cross-thread bundle shared variable is arranged linearly and continuously in the shared register pool.

[0113] Based on any of the above embodiments, the device further includes an analysis module, the analysis module being used for: Analyze the lifetime of each cross-thread bundle shared variable in the kernel code to identify at least two target cross-thread bundle shared variables whose lifetimes do not overlap; Accordingly, the allocation module is also used for: In the shared register pool, the same static offset is assigned to the at least two target cross-thread bundle shared variables to indicate that the at least two target cross-thread bundle shared variables reuse the same physical register at runtime.

[0114] Based on any of the above embodiments, the conversion module is specifically used for: Analyze the access statements in the kernel code for the shared variables across each thread bundle to determine the corresponding shared access mode; Based on the shared access mode, the memory access operations corresponding to the access statements are merged or rearranged to obtain an optimized memory access operation sequence. Based on the shared base address and the static offset, the optimized memory access operation sequence is converted into the target access instruction; The target access instruction is either a hardware atomic operation instruction or a normal memory access instruction, and the static offset is fixed in the target access instruction as a compile-time constant.

[0115] Based on any of the above embodiments, the device further includes a generation module, the generation module being used for: Generate initialization instructions, which instruct the hardware device to load the shared base address into the shared base address register when the kernel starts.

[0116] The register access device provided by the present invention is described below. The register access device described below and the register access method described above can be referred to in correspondence.

[0117] Based on any of the above embodiments Figure 6 This is a schematic diagram of the register access device provided by the present invention, as shown below. Figure 6 As shown, this device is applied to a hardware device whose physical register resources are divided into a private register pool and a shared register pool based on the total private register requirements during kernel code runtime. The shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles. The device includes: The receiving module 610 is used to receive register access instructions from the host, the register access instructions including the target access instructions obtained by the host after converting the access statements for cross-thread bundle shared variables in the kernel code; Decoding module 620 is used to decode the register access instruction and determine the addressing mode corresponding to the register access instruction; The determination module 630 is used to, when the addressing mode is shared mode, obtain the shared base address corresponding to the shared register pool based on the register identifier carried in the register access instruction, and determine the first target physical address according to the shared base address and the static offset carried in the register access instruction. The static offset is the offset relative to the shared base address that the host pre-allocates in the shared register pool for the corresponding cross-thread bundle shared variable. Access module 640 is used to access the corresponding shared register in the shared register pool according to the first target physical address.

[0118] The apparatus provided in this invention parses the target access instruction and identifies the shared addressing mode on the hardware device side. It quickly obtains the globally unique shared base address using the register identifier carried in the instruction and directly calculates the target physical address by combining it with the static offset embedded in the instruction. This achieves efficient access to shared registers in the underlying hardware pipeline. This invention eliminates the need for data exchange between different thread bundles to rely on slow shared memory or global memory. It not only reduces communication latency and synchronization overhead in fine-grained cross-thread bundle collaboration but also improves the utilization rate of physical register resources through minimal modification of addressing logic and simple static address calculation.

[0119] Based on any of the above embodiments, the access module is specifically used for: The current access status of the target shared register corresponding to the first target physical address is obtained through the configured shared access status register. The shared access status register records the access status of each shared register in the shared register pool. Based on the current access state, conflict detection is performed on the current thread's access to the target shared register. If no conflict is detected, a hardware atomic operation based on the shared base address is performed on the target shared register, and the access status of the target shared register in the shared access status register is updated.

[0120] Based on any of the above embodiments, the access module is further configured to: When the addressing mode is private mode, the second target physical address is calculated based on the private base address of the current thread, the thread channel identifier, and the local offset, and the corresponding private register in the private register pool is accessed according to the second target physical address.

[0121] Based on any of the above embodiments, according to the register access instruction generation method executed by the host side and the register access method executed by the hardware device side, the present invention provides a corresponding hardware device to support the implementation of the above-mentioned hierarchical base addressing and cross-thread bundle sharing mechanism at the underlying physical architecture. Figure 7 This is a schematic diagram of the hardware device provided by the present invention, such as... Figure 7 As shown, the hardware device (such as a GPU) includes at least one Streaming Processor Cluster (SPC), which is the basic unit for performing core computations and thread scheduling. Each streaming processor cluster specifically includes: Physical register resource 710 is used to be divided into a private register pool and a shared register pool, wherein the shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles; Shared base address register 720 is used to store the shared base address of the shared register pool during the kernel startup phase; The instruction decoding unit 730 is used to receive register access instructions from the host, decode the register access instructions, determine the addressing mode corresponding to the register access instructions, and the register access instructions include the target access instructions obtained by the host after converting the access statements for cross-thread bundle shared variables in the kernel code. The instruction execution unit 740 is configured to access the corresponding shared register in the shared register pool based on the shared base address stored in the shared base address register 720 and the static offset carried in the register access instruction when the addressing mode is shared mode. The static offset is the offset relative to the shared base address that the host pre-allocates in the shared register pool for the corresponding cross-thread bundle shared variable.

[0122] Specifically, within a streaming processor cluster, the physical register resource (i.e., the physical register file) is a high-speed static random access memory (SRAM) used for high-speed storage. Before the kernel code runs, this physical space has been logically divided into two parts: one part is a private register pool that ensures execution isolation and backward compatibility within traditional thread bundles; the other part is a shared register pool that breaks the traditional isolation restrictions and consists of the remaining available space. The shared registers in this pool are globally visible to all active thread bundles (Warp) in the current kernel and support cooperative access.

[0123] To support a unified base address architecture, a shared base address register (such as the SR0 register) is set up inside the streaming processor cluster. When the kernel code issued by the host starts executing, the hardware device executes an initialization instruction, which loads the starting physical address of the shared register pool (i.e., SHARED_BASE) that was determined at compile time and keeps it residing in the register for subsequent instructions to call at any time.

[0124] At the front end of the hardware pipeline, the instruction decoding unit is responsible for receiving the machine instruction stream generated by the host compiler. By decoding the instruction opcode or register operand identifier, this unit can identify whether the current instruction uses a traditional private mode or a shared mode for target access instructions.

[0125] Once the shared addressing mode is defined, the instruction execution unit no longer needs to rely on thread channel identifiers to perform complex dynamic address multiplication and addition calculations as in traditional architectures. Instead, it directly extracts a unified shared base address from the shared base address register and simply adds it to the static offset that is directly embedded in the current target access instruction. This allows for precise location and high-speed reading and writing of the corresponding shared register unit in the physical register resource.

[0126] The hardware device provided in this invention achieves an architecture upgrade with minimal hardware complexity and minimal modification to addressing logic by statically allocating physical register resources within a streaming processor cluster and setting up a dedicated shared base address register to cooperate with the static addressing logic of the instruction decoding and execution unit. This hardware device not only maintains good backward compatibility with existing traditional proprietary computing architectures but also eliminates the overhead of dynamic base address calculation during cross-thread communication, thereby improving the utilization rate of physical hardware resources.

[0127] Based on any embodiment, such as Figure 7 As shown, the device also includes: The shared access status register 750 is used to record the access status of each currently active thread bundle to each shared register in the shared register pool; The instruction execution unit 740 is further configured to query the access status recorded in the shared access status register 750 when performing cross-thread bundle register access operations in the shared mode, so as to perform access conflict detection.

[0128] Specifically, since the shared register pool is open across thread bundles, it inevitably faces the risk of data contention when multiple thread bundles concurrently read and write to the same physical address. To further ensure data consistency and execution security when multiple thread bundles concurrently access the shared register pool, this embodiment of the invention extends and improves the internal components of the hardware device. Specifically, a dedicated shared access status register is configured in the hardware. Each status bit of this register is mapped to a physical register unit in the shared register pool, recording in real time and dynamically which thread bundle is currently reading, writing, or locking which shared register.

[0129] Before the instruction execution unit prepares to perform a memory access operation on the calculated target shared register (especially a hardware atomic operation instruction), it first performs a high-speed query of the shared access status register at the hardware level. By comparing the access intent of the current thread bundle with the current access status of the target register, the execution unit can quickly complete conflict detection (e.g., determining whether it is under the exclusive write protection period of another warp). Only when no access conflict is detected will the instruction execution unit issue a hardware memory access or atomic operation based on the shared base address, and synchronously update the status register after the operation is completed to release the occupied memory or refresh the status.

[0130] This invention, through configuring a shared access status register in the hardware device and enabling the instruction execution unit to perform strict conflict detection and status updates at the underlying level, constructs a highly efficient and low-latency cross-thread bundle synchronization and conflict handling mechanism at the register level. This mechanism eliminates the need for developers to explicitly invoke complex synchronization barriers at the software level, ensuring the safety and data consistency of cross-thread bundle concurrent operations while maximizing the execution performance of fine-grained parallel cooperative algorithms at the hardware level.

[0131] Based on any of the above embodiments Figure 8 This is a schematic diagram of the host structure provided by the present invention, as shown below. Figure 8As shown, the host may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other through the communication bus 840. The processor 810 can invoke logical instructions in the memory 830 to execute a register access instruction generation method. This method includes: acquiring kernel code to be processed and extracting at least one cross-thread bundle shared variable declared in the kernel code; determining the total private register requirement of the kernel code when running on a hardware device, and based on the total private register requirement, dividing the physical register resources of the hardware device into a private register pool and a shared register pool, wherein the shared register pool includes at least one shared register accessible to all thread bundles; determining a shared base address corresponding to the shared register pool, and allocating a static offset relative to the shared base address for each cross-thread bundle shared variable in the shared register pool; and converting access statements in the kernel code for each cross-thread bundle shared variable into target access instructions based on the shared base address and the static offset. The target access instructions instruct the hardware device to access the corresponding shared register in the shared register pool based on the shared base address and the static offset.

[0132] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to related technologies, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0133] Based on any of the above embodiments, this invention provides a server, including a host as described in the foregoing embodiments, and a hardware device as described in any of the foregoing embodiments that is communicatively connected to the host. The host and the hardware device can exchange data and instructions via a communication bus, such as a PCIe (Peripheral Component Interconnect express) bus and a communication interface.

[0134] In this server's collaborative workflow, the host is primarily responsible for system control, kernel code compilation, and task distribution. Specifically, when the host (including the CPU and memory) runs the compiler or computation program stored internally, it processes the source code containing cross-thread bundle shared variables. During the compilation phase, the host executes an internal register allocation algorithm to divide the physical register resources on the hardware device into a private register pool that ensures backward compatibility and a shared register pool for collaborative access by all thread bundles, based on the total private register requirements for the current kernel code execution. Simultaneously, the host is responsible for determining the starting position of the physically contiguous shared register pool, i.e., the shared base address, and allocating static offsets to each extracted cross-thread bundle shared variable according to its declaration order, ensuring that the cross-thread bundle shared variables are arranged contiguously within the shared register pool. Finally, the host converts the high-level shared access statements in the source code into target access instructions with fixed static offsets, and then sends these instructions and related kernel tasks to the hardware device through the communication interface.

[0135] Hardware devices (such as GPUs) are primarily responsible for parallel fine-grained computation and actual hardware memory access. During kernel startup, the hardware device first executes initialization instructions generated by the host, loading the shared base address into dedicated hardware registers (such as SR0). In the execution pipeline, when the hardware device receives a target access instruction from the host, its instruction decoding unit decodes the received instruction and determines its addressing mode. If it is determined to be in shared mode, the instruction execution unit reads the shared base address stored in SR0 based on the register identifier carried in the instruction, and directly combines it with the compile-time constant, i.e., the static offset, carried in the instruction to calculate the exact target physical address, thereby enabling fast access to the corresponding physical registers in the shared register pool.

[0136] The server provided in this embodiment of the invention deeply integrates the host's static compilation scheduling mechanism with the dynamic execution architecture of the hardware device to construct a software and hardware co-working architecture. This architecture breaks the physical limitation of strict isolation of traditional thread bundle level registers, enabling idle register resources to be reused across thread bundles and improving the overall utilization of hardware resources.

[0137] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the register access instruction generation method provided by the above methods. The method includes: obtaining kernel code to be processed and extracting at least one cross-thread bundle shared variable declared in the kernel code; determining the total private register requirement of the kernel code when running on a hardware device, and dividing the physical register resources of the hardware device into a private register pool and a shared register pool based on the total private register requirement, wherein the shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles; determining the shared base address corresponding to the shared register pool, and allocating a static offset relative to the shared base address for each cross-thread bundle shared variable in the shared register pool; and converting the access statements for each cross-thread bundle shared variable in the kernel code into target access instructions based on the shared base address and the static offset, wherein the target access instructions are used to instruct the hardware device to access the corresponding shared register in the shared register pool based on the shared base address and the static offset.

[0138] When the computer program is executed by the processor, the computer can also execute the register access methods provided by the above methods. These methods are applied to hardware devices, where the physical register resources of the hardware device are divided into a private register pool and a shared register pool based on the total private register requirements during kernel code execution. The shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles. The method includes: receiving a register access instruction from the host, the register access instruction including a target access instruction obtained by the host after converting access statements for cross-thread bundle shared variables in the kernel code; decoding the register access instruction to determine the addressing mode corresponding to the register access instruction; if the addressing mode is shared mode, obtaining the shared base address corresponding to the shared register pool based on the register identifier carried in the register access instruction, and determining a first target physical address based on the shared base address and the static offset carried in the register access instruction, the static offset being the offset relative to the shared base address pre-allocated by the host for the corresponding cross-thread bundle shared variable in the shared register pool; and accessing the corresponding shared register in the shared register pool based on the first target physical address.

[0139] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the register access instruction generation method provided by the above methods. The method includes: obtaining kernel code to be processed and extracting at least one cross-thread bundle shared variable declared in the kernel code; determining the total private register requirement of the kernel code when running on a hardware device, and based on the total private register requirement, dividing the physical register resources of the hardware device into a private register pool and a shared register pool, wherein the shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles; determining the shared base address corresponding to the shared register pool, and allocating a static offset relative to the shared base address for each cross-thread bundle shared variable in the shared register pool; and converting access statements for each cross-thread bundle shared variable in the kernel code into target access instructions based on the shared base address and the static offset. The target access instructions are used to instruct the hardware device to access the corresponding shared register in the shared register pool based on the shared base address and the static offset.

[0140] When executed by a processor, this computer program implements the register access methods provided by the above methods. These methods are applied to a hardware device whose physical register resources are divided into a private register pool and a shared register pool based on the total private register requirements during kernel code execution. The shared register pool includes at least one shared register accessible to all thread bundles. The method includes: receiving a register access instruction from a host, the register access instruction including a target access instruction obtained by the host after converting access statements for cross-thread bundle shared variables in the kernel code; decoding the register access instruction to determine the addressing mode corresponding to the register access instruction; if the addressing mode is shared mode, obtaining the shared base address corresponding to the shared register pool based on the register identifier carried in the register access instruction, and determining a first target physical address based on the shared base address and the static offset carried in the register access instruction, the static offset being an offset relative to the shared base address pre-allocated by the host for the corresponding cross-thread bundle shared variable in the shared register pool; and accessing the corresponding shared register in the shared register pool based on the first target physical address.

[0141] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0142] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of software products. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0143] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for generating register access instructions, characterized in that, The method is applied to a host, and the method includes: Obtain the kernel code to be processed, and extract at least one cross-thread bundle shared variable declared in the kernel code; Determine the total private register requirement of the kernel code when it runs on the hardware device, and based on the total private register requirement, divide the physical register resources of the hardware device into a private register pool and a shared register pool. The shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles. Determine the shared base address corresponding to the shared register pool, and allocate a static offset relative to the shared base address in the shared register pool for each cross-thread bundle shared variable; Based on the shared base address and the static offset, the access statements in the kernel code for the shared variables across each thread bundle are converted into target access instructions. The target access instructions are used to instruct the hardware device to access the corresponding shared registers in the shared register pool based on the shared base address and the static offset.

2. The register access instruction generation method according to claim 1, characterized in that, The step of determining the total private register requirements of the kernel code when running on the hardware device, and dividing the physical register resources of the hardware device into a private register pool and a shared register pool based on the total private register requirements, includes: Based on the kernel code, determine the number of private registers required for each thread; The total private register requirement is calculated based on the number of private registers, the thread bundle size of the hardware device, and the maximum number of concurrent thread bundles. If the total private register requirement does not exceed the physical register resources, the space in the physical register resources that matches the size of the total private register requirement is divided into the private register pool. The remaining available space in the physical register resources, excluding the private register pool, is divided into the shared register pool.

3. The register access instruction generation method according to claim 2, characterized in that, Determining the shared base address corresponding to the shared register pool includes: Determine the end address of the private register pool within the physical register resource; Configure the end address as the shared base address of the shared register pool so that the shared register pool and the private register pool are physically contiguous.

4. The register access instruction generation method according to claim 1, characterized in that, The allocation of static offsets relative to the shared base address for each cross-thread bundle shared variable in the shared register pool includes: Obtain the data type size of each cross-thread bundle shared variable; Based on the declaration order of each cross-thread bundle shared variable and the data type size of each cross-thread bundle shared variable, the static offset is allocated to each cross-thread bundle shared variable in the shared register pool so that each cross-thread bundle shared variable is arranged linearly and continuously in the shared register pool.

5. The register access instruction generation method according to claim 4, characterized in that, Before the step of allocating the static offset for each cross-thread bundle shared variable in the shared register pool, the method further includes: Analyze the lifetime of each cross-thread bundle shared variable in the kernel code to identify at least two target cross-thread bundle shared variables whose lifetimes do not overlap; The process of allocating the static offset for each cross-thread bundle shared variable in the shared register pool includes: In the shared register pool, the same static offset is assigned to the at least two target cross-thread bundle shared variables to indicate that the at least two target cross-thread bundle shared variables reuse the same physical register at runtime.

6. The register access instruction generation method according to any one of claims 1 to 5, characterized in that, The step of converting access statements in the kernel code for the shared variables across thread bundles into target access instructions based on the shared base address and the static offset includes: Analyze the access statements in the kernel code for the shared variables across each thread bundle to determine the corresponding shared access mode; Based on the shared access mode, the memory access operations corresponding to the access statements are merged or rearranged to obtain an optimized memory access operation sequence. Based on the shared base address and the static offset, the optimized memory access operation sequence is converted into the target access instruction; The target access instruction is either a hardware atomic operation instruction or a normal memory access instruction, and the static offset is fixed in the target access instruction as a compile-time constant.

7. The register access instruction generation method according to any one of claims 1 to 5, characterized in that, Also includes: Generate initialization instructions, which instruct the hardware device to load the shared base address into the shared base address register when the kernel starts.

8. A register access method, characterized in that, The method is applied to a hardware device, wherein the physical register resources of the hardware device are divided into a private register pool and a shared register pool based on the total private register requirements during kernel code runtime. The shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles. The method includes: Receive register access instructions from the host, the register access instructions including the target access instructions obtained by the host after converting the access statements in the kernel code for cross-thread bundle shared variables; Decode the register access instruction to determine the addressing mode corresponding to the register access instruction; When the addressing mode is shared mode, the shared base address corresponding to the shared register pool is obtained based on the register identifier carried in the register access instruction, and the first target physical address is determined according to the shared base address and the static offset carried in the register access instruction. The static offset is the offset relative to the shared base address that the host pre-allocates in the shared register pool for the corresponding cross-thread bundle shared variable. Based on the first target physical address, the corresponding shared register in the shared register pool is accessed.

9. The register access method according to claim 8, characterized in that, The step of accessing the corresponding shared register in the shared register pool based on the first target physical address includes: The current access status of the target shared register corresponding to the first target physical address is obtained through the configured shared access status register. The shared access status register records the access status of each shared register in the shared register pool. Based on the current access state, conflict detection is performed on the current thread's access to the target shared register. If no conflict is detected, a hardware atomic operation based on the shared base address is performed on the target shared register, and the access status of the target shared register in the shared access status register is updated.

10. The register access method according to claim 8, characterized in that, The method further includes: When the addressing mode is private mode, the second target physical address is calculated based on the private base address of the current thread, the thread channel identifier, and the local offset, and the corresponding private register in the private register pool is accessed according to the second target physical address.

11. A host computer, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the register access instruction generation method as described in any one of claims 1 to 7.

12. A hardware device, characterized in that, include: Physical register resources are used to divide the space into a private register pool and a shared register pool, wherein the shared register pool includes at least one shared register that can be accessed collaboratively by all thread bundles. A shared base address register is used to store the shared base address of the shared register pool during the kernel startup phase; The instruction decoding unit is used to receive register access instructions from the host, decode the register access instructions, determine the addressing mode corresponding to the register access instructions, and the register access instructions include the target access instructions obtained by the host after converting the access statements for cross-thread bundle shared variables in the kernel code. The instruction execution unit is configured to access the corresponding shared register in the shared register pool based on the shared base address stored in the shared base address register and the static offset carried in the register access instruction when the addressing mode is shared mode. The static offset is the offset relative to the shared base address that the host pre-allocates in the shared register pool for the corresponding cross-thread bundle shared variable.

13. The hardware device according to claim 12, characterized in that, Also includes: A shared access status register is used to record the access status of each currently active thread bundle to each shared register in the shared register pool; The instruction execution unit is further configured to query the access status recorded in the shared access status register when performing cross-thread bundle register access operations in the shared mode, so as to perform access conflict detection.

14. A server, characterized in that, It includes the host as described in claim 11, and the hardware device as described in claim 12 or 13 that is communicatively connected to the host.

15. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the register access instruction generation method as described in any one of claims 1 to 7, or the register access method as described in any one of claims 8 to 10.

Images