Memory access method of computing device and related device

Abstract

The memory access method of the computing device and the related device and method are applied to a first computing device associated with an open segment cache. The method comprises the following steps: first, in response to a memory access instruction initiated by a meta-thread executed on the first computing device, obtaining a target open segment address and a target offset from the memory access instruction; then, based on the target open segment address, obtaining a corresponding open segment data structure from the local memory of the first computing device, wherein the open segment data structure at least comprises a target physical device identifier and a target physical base address; thereafter, based on the target physical base address and the target offset, determining an actual physical access address; finally, based on the target physical device identifier, initiating a physical memory access request carrying the actual physical access address to a second computing device, thereby improving the compatibility and efficiency of data communication between multiple heterogeneous processor nodes in an extended network.

Description

Technical Field

[0001] This application relates to the field of computational data processing technology, and in particular to memory access methods and related devices for computing devices. Background Technology

[0002] With the rapid development of artificial intelligence and large-scale distributed computing technologies, scale-up networks built from various heterogeneous processors (such as Central Processing Units (CPUs), Graphics Processing Units (GPUs), Neural Processing Units (NPUs), and Tensor Processing Units (TPUs), all of which are various heterogeneous computing units (X Processing Units, XPUs)) have become the core computing architecture for breaking through the upper limit of single-chip computing power. In such cluster systems with deep collaboration among multiple devices, in order to achieve efficient model parallelism and data interaction, threads within each computing node need to have the ability to directly access each other's memory (Peer Memory).

[0003] In existing interconnect architectures, cross-device memory access typically relies on virtual addressing mechanisms, which embed a virtual device identifier (Virtual XPU ID) in the virtual address of the operation instruction. Subsequently, the system uses the underlying Memory Management Unit (MMU) and page table to dynamically translate the virtual address and virtual device identifier into the real physical base address and physical device identifier per page, and then completes the data access operation between devices through network routing.

[0004] However, existing cross-device memory access schemes based on page table mapping all rely on the underlying hardware support of the processing chip for virtual addressing and memory management units. Due to significant differences in the architectural designs of various AI accelerators, some XPU hardware customized for extreme computing power or specific scenarios does not support virtual addressing mechanisms at the underlying level, and some even lack complex memory management units. Furthermore, page table mapping requires address translation at a fixed page granularity, which can easily lead to high address translation overhead and memory access latency when handling massive and fine-grained inter-device data interactions. Consequently, on XPU devices lacking virtual address support, their internal meta threads or thread units cannot directly issue cross-device memory access instructions to the system using existing page table mechanisms. This results in severe compatibility issues in data communication between heterogeneous processors in upscaled networks, preventing direct physical memory penetration without virtual addressing, and leading to poor compatibility and efficiency of cross-device memory access in distributed computing clusters. Summary of the Invention

[0005] This application provides a memory access method and related equipment for a computing device, which can improve the compatibility and efficiency of cross-device memory access in a distributed computing cluster.

[0006] To achieve the above objectives, a first aspect of this application provides a memory access method for a computing device, the method comprising:

[0007] In response to a memory access instruction initiated by a meta-thread executed on the first computing device, the target open segment address and the target offset are obtained from the memory access instruction;

[0008] Based on the target open segment address, the corresponding open segment data structure is obtained from the local memory of the first computing device, wherein the open segment data structure includes at least the target physical device identifier and the target physical base address;

[0009] Based on the target physical base address and the target offset, the actual physical access address is determined;

[0010] Based on the target physical device identifier, a physical memory access request carrying the actual physical access address is initiated to the second computing device.

[0011] In some embodiments, the first computing device is associated with an open segment cache; obtaining the corresponding open segment data structure from the local memory of the first computing device based on the target open segment address includes:

[0012] Send the target open segment address to the open segment cache for querying;

[0013] If a cache entry corresponding to the target open segment address is found in the open segment cache, the target physical device identifier and the target physical base address are directly obtained from the cache entry;

[0014] If not found, the local memory is accessed according to the target open segment address to obtain the open segment data structure, and the obtained open segment data structure is stored in the open segment cache.

[0015] In some embodiments, the first computing device includes a hardware hub and at least one computing unit, wherein the open segment cache is deployed inside the computing unit or inside the hardware hub.

[0016] In some embodiments, sending the target open segment address to the open segment cache for querying includes:

[0017] The target open segment address is sent to the open segment cache deployed inside the computing unit, and the target physical device identifier and the target physical base address are determined in the computing unit;

[0018] Alternatively, the target open segment address can be sent to the open segment cache deployed inside the hardware hub, and the target physical device identifier and the target physical base address can be determined in the hardware hub.

[0019] In some embodiments, the memory access instruction does not carry a virtual address, and the initiation of the memory access instruction includes any one of the following steps:

[0020] In response to a load instruction initiated by the metathread of the first computing device, a memory access instruction is generated for reading data from the actual physical access address of the second computing device;

[0021] In response to a storage instruction initiated by the metathread of the first computing device, a memory access instruction is generated for writing data from the actual physical access address of the second computing device;

[0022] In response to an atomic instruction initiated by the metathread of the first computing device, a memory access instruction is generated for performing atomic operations from the actual physical access address of the second computing device.

[0023] In some embodiments, initiating a physical memory access request carrying the actual physical access address to the second computing device based on the target physical device identifier includes:

[0024] Based on the target open segment address, determine the corresponding open segment size from the open segment data structure;

[0025] Based on the target offset and the size of the open segment, an out-of-bounds determination is performed to obtain the out-of-bounds determination result;

[0026] When the boundary determination result indicates that the target offset has not exceeded the boundary, a physical memory access request is initiated to the second computing device.

[0027] In some embodiments, the memory access instruction further includes the number of data elements to be accessed and the data type. The step of determining the boundary based on the target offset and the open segment size to obtain the boundary determination result includes:

[0028] Determine the corresponding displacement step size based on the data type described above;

[0029] For each data element to be accessed, the index of the data element is shifted left based on the displacement step size to obtain the left shift result. The left shift result is then summed with the target offset to obtain the actual offset address of each data element.

[0030] When the actual offset address of the element is greater than or equal to the size of the open segment, an out-of-bounds determination result is generated to indicate that the target offset has exceeded the bounds, and physical memory access requests for the data element are intercepted.

[0031] When the actual offset address of the element is less than the size of the open segment, an out-of-bounds determination result is generated, indicating that the target offset has not exceeded the bounds.

[0032] In some embodiments, prior to the memory access instruction initiated in response to a metathread executed on the first computing device, the method further includes:

[0033] Obtain predefined memory segment information of the second computing device, which includes logical device identifier, logical base address, and logical size;

[0034] The logical device identifier is mapped and converted into the target physical device identifier corresponding to the second computing device in the extended network;

[0035] Based on the target physical device identifier, the logical base address, and the logical size, a memory object is constructed and stored in the open segment cache.

[0036] In some embodiments, after constructing the memory object and storing the memory object in the open segment cache, the method further includes:

[0037] When the memory access instruction is executed by the meta-thread, the memory object in the open segment cache is kept in an unmodifiable static locked state;

[0038] Before extracting the memory object, the access permission of the memory access instruction is checked based on the read and write permission feature bits in the memory object to obtain the access permission check result. When the access permission check result indicates that the memory object has read and write permissions, the extraction operation of the memory object is performed.

[0039] To achieve the above objectives, a second aspect of this application provides another method for accessing memory in a computing device, the method comprising:

[0040] The system receives a physical memory access request from a first computing device. The physical memory access request carries an actual physical access address. The actual physical access address is determined by the first computing device based on a target physical base address and a target offset. The target physical base address is obtained by the first computing device based on a target open segment address and by obtaining the corresponding open segment data structure from the local memory of the first computing device. The target open segment address and the target offset are obtained by the first computing device from the memory access instructions initiated by the meta-thread executed above.

[0041] Based on the physical memory access request, determine the corresponding memory access instruction type;

[0042] In the local physical memory of the second computing device, the corresponding memory access operation is executed according to the memory access instruction type and the actual physical access address.

[0043] To achieve the above objectives, a third aspect of the present application provides a computing device memory access system, including a first computing device and a second computing device that are communicatively connected to each other;

[0044] The first computing device is configured to respond to a memory access instruction initiated by a meta-thread executed on the first computing device, obtain a target open segment address and a target offset from the memory access instruction, obtain a corresponding open segment data structure from the local memory of the first computing device based on the target open segment address, wherein the open segment data structure includes at least a target physical device identifier and a target physical base address, determine an actual physical access address based on the target physical base address and the target offset, and initiate a physical memory access request carrying the actual physical access address to the second computing device based on the target physical device identifier.

[0045] The second computing device is configured to receive a physical memory access request from the first computing device, the physical memory access request carrying an actual physical access address, and based on the physical memory access request, determine the corresponding memory access instruction type, and execute the corresponding memory access operation in the local physical memory of the second computing device according to the memory access instruction type and the actual physical access address.

[0046] To achieve the above objectives, a fourth aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the memory access method of a computing device as described in the first aspect or the memory access method of a computing device as described in the second aspect.

[0047] To achieve the above objectives, a fifth aspect of the present application provides a storage medium, which is a computer-readable storage medium storing a computer program that, when executed by a processor, implements the memory access method of a computing device as described in the first aspect or the memory access method of a computing device as described in the second aspect.

[0048] The memory access method and related apparatus for a computing device proposed in this application include: First, in response to a memory access instruction initiated by a meta-thread executed on a first computing device, obtaining a target open segment address and a target offset from the memory access instruction; then, based on the target open segment address, obtaining a corresponding open segment data structure from the local memory of the first computing device, wherein the open segment data structure includes at least a target physical device identifier and a target physical base address; subsequently, determining the actual physical access address based on the target physical base address and the target offset; and finally, based on the target physical device identifier, initiating a physical memory access request carrying the actual physical access address to a second computing device. This application embodiment maintains an open segment data structure in the local memory of the first computing device. This allows the meta-thread executing on the first computing device to directly carry the target open segment address and target offset when initiating cross-device memory access instructions, without embedding complex virtual addresses in the instructions. Subsequently, the system directly obtains the corresponding open segment data structure from the local memory of the first computing device through the target open segment address, thereby parsing the corresponding target physical device identifier and target physical base address. Combined with the target offset, the actual physical access address is accurately located, and then a physical memory access request is directly initiated. The solution of this application utilizes the direct mapping of data structures in local memory, eliminating the deep dependence of traditional cross-device memory communication on virtual addressing mechanisms, memory management units, and page tables. This enables various heterogeneous computing accelerators (such as XPUs customized for specific scenarios) that do not support virtual addressing or are not equipped with complex memory management units to achieve direct access to the memory of the peer device. In addition, since there is no need to perform a cumbersome address translation process based on fixed page granularity, the address translation overhead and memory access latency generated during massive data interaction are eliminated, thereby improving the compatibility and efficiency of data communication between multiple heterogeneous processor nodes in the extended network.

[0049] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0050] Figure 1 This is a schematic diagram of a typical distributed computing cluster topology provided in an embodiment of this application.

[0051] Figure 2 This is a flowchart of a virtual memory data processing method applied in a computing device of a first computing device, provided in another embodiment of this application.

[0052] Figure 3This is a flowchart of an open segment cache generation method provided in another embodiment of this application.

[0053] Figure 4 This is a schematic diagram of an open segment object mapping and generation process provided in another embodiment of this application.

[0054] Figure 5 This is a schematic diagram illustrating the hierarchical storage and mapping relationship between an open segment object in local memory and an open segment cache, provided in another embodiment of this application.

[0055] Figure 6 This is a flowchart illustrating the initiation of a memory access instruction according to another embodiment of this application.

[0056] Figure 7 yes Figure 2 The flowchart for step 202.

[0057] Figure 8 This is a schematic diagram of two typical physical deployment locations of an open segment cache within a first computing device, provided in another embodiment of this application.

[0058] Figure 9 This is a flowchart for determining the target physical device identifier and the target physical base address, provided in another embodiment of this application.

[0059] Figure 10 This is a schematic diagram of the logic flow for underlying physical addressing and translation based on open segment addresses, provided in another embodiment of this application.

[0060] Figure 11 This is a flowchart for boundary crossing determination provided in another embodiment of this application.

[0061] Figure 12 yes Figure 10 The flowchart for step 1002.

[0062] Figure 13 This is a schematic diagram of the logic flow of an out-of-bounds determination process based on physical addressing, provided in another embodiment of this application.

[0063] Figure 14 This is a flowchart of an authorization verification provided in another embodiment of this application.

[0064] Figure 15 This is a flowchart of a virtual memory data processing method applied in a computing device of a second computing device, provided in another embodiment of this application.

[0065] Figure 16 This is a schematic diagram of the structure of a computing device memory access system provided in another embodiment of this application.

[0066] Figure 17This is a schematic diagram of the hardware structure of an electronic device provided in another embodiment of this application. Detailed Implementation

[0067] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0068] It should be noted that although functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart.

[0069] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0070] With the rapid development of artificial intelligence and large-scale distributed computing technologies, scale-up networks built from various heterogeneous processors (such as Central Processing Units (CPUs), Graphics Processing Units (GPUs), Neural Processing Units (NPUs), and Tensor Processing Units (TPUs), all of which are various heterogeneous computing units (X Processing Units, XPUs)) have become the core computing architecture for breaking through the upper limit of single-chip computing power. In such cluster systems with deep collaboration among multiple devices, in order to achieve efficient model parallelism and data interaction, threads within each computing node need to have the ability to directly access each other's memory (Peer Memory).

[0071] Reference Figure 1 This is a schematic diagram of a typical distributed computing cluster topology provided in an embodiment of this application. Figure 1 As shown, this distributed computing cluster contains multiple interconnected processor devices (representing various heterogeneous computing units, XPUs). These processor devices form an interconnected network through underlying communication links to collaboratively execute complex, massively parallel computing tasks. Figure 1In this multi-device deep collaborative cluster architecture, when any processor device acts as the initiator, in order to reduce communication latency and improve overall system bandwidth, its internal computing threads typically need to be able to cross node boundaries and directly access other processor devices in the interconnect network (i.e., Figure 1 The ability of peer memory in interconnected devices to support efficient model parallelism and data interaction.

[0072] In the existing interconnection architecture (such as Figure 1 In the distributed computing cluster shown, cross-device memory access typically relies on a virtual addressing mechanism, which embeds a virtual device identifier (Virtual XPU ID) in the virtual address of the operation instruction. Then, the system uses the underlying Memory Management Unit (MMU) and Page Table to dynamically translate the virtual address and virtual device identifier into the real physical base address and physical device identifier per page, and then completes the data access operation between devices through network routing.

[0073] However, existing cross-device memory access schemes based on page table mapping all rely on the underlying hardware support of the processing chip for virtual addressing and memory management units. Due to significant differences in the architectural designs of various AI accelerators, some XPU hardware customized for extreme computing power or specific scenarios does not support virtual addressing mechanisms at the underlying level, and some even lack complex memory management units. Furthermore, page table mapping requires address translation at a fixed page granularity, which can easily lead to high address translation overhead and memory access latency when handling massive and fine-grained inter-device data interactions. Consequently, on XPU devices lacking virtual address support, their internal meta threads or thread units cannot directly issue cross-device memory access instructions to the system using existing page table mechanisms. This results in severe compatibility issues in data communication between heterogeneous processors in upscaled networks, preventing direct physical memory penetration without virtual addressing, and leading to poor compatibility and efficiency of cross-device memory access in distributed computing clusters.

[0074] To improve the compatibility and efficiency of cross-device memory access in distributed computing clusters, this embodiment maintains an open segment data structure in the local memory of the first computing device. This allows the meta-thread executing on the first computing device to directly carry the target open segment address and target offset when initiating cross-device memory access instructions, without embedding complex virtual addresses in the instructions. Subsequently, the system directly retrieves the corresponding open segment data structure from the local memory of the first computing device using the target open segment address, thereby parsing the corresponding target physical device identifier and target physical base address. Combined with the target offset, the system accurately locates the actual physical access address and directly... Initiating a physical memory access request; the solution in this application utilizes direct mapping of data structures in local memory, eliminating the deep dependence of traditional cross-device memory communication on virtual addressing mechanisms, memory management units, and page tables. This enables various heterogeneous computing accelerators (such as XPUs customized for specific scenarios) that do not support virtual addressing or are not equipped with complex memory management units to achieve direct access to the memory of peer devices. In addition, since there is no need to perform a cumbersome address translation process based on fixed page granularity, the address translation overhead and memory access latency generated during massive data interaction are eliminated, thereby improving the compatibility and efficiency of data communication between multiple heterogeneous processor nodes in the extended network.

[0075] The memory access method and related devices of the computing device provided in the embodiments of this application will be further described below. First, a first computing device applied in a distributed computing cluster (i.e., such as...) will be described. Figure 1 The memory access method of any processor device shown (which can be any kind of heterogeneous computing unit) is described in this scheme. An open segment cache is associated with the first computing device so that when the meta thread initiates a cross-device memory access instruction, it does not need to embed a complex virtual address in the instruction, but directly carries the target open segment address and the target offset, as described below.

[0076] Reference Figure 2 This is an optional flowchart of a memory access method for a computing device applied to a first computing device, provided in an embodiment of this application. Figure 2 The method may include, but is not limited to, steps 201 to 204. It is also understood that this embodiment... Figure 2 The order of steps 201 to 204 is not specifically limited. The order of steps can be adjusted or some steps can be reduced or added according to actual needs.

[0077] Step 201: In response to a memory access instruction initiated by a meta-thread executed on the first computing device, obtain the target open segment address and the target offset from the memory access instruction.

[0078] Step 201 is described in detail below.

[0079] In step 201 of some embodiments, the underlying hardware or driver system of the first computing device responds to a memory access instruction initiated by a meta-thread executing on the first computing device and obtains the target open segment address and target offset from the memory access instruction. Specifically, when a meta-thread executing inside the first computing device (e.g., a heterogeneous accelerated computing unit performing distributed computing tasks) generates a need to directly access the memory of another device, it will actively issue the memory access instruction at the underlying level.

[0080] This memory access instruction differs from traditional addressing instructions that carry virtual addresses. Instead, it is a low-level interactive instruction specifically designed to achieve direct physical addressing, such as load, store, or atomic operation instructions targeting the other party's physical memory. The solution in this application, by parsing this instruction, can extract several core addressing parameters: target open segment address, target offset, number of data elements to be accessed, and data type. Specifically, the "target open segment address" is an address pointer or identifier pointing to a specific "open segment data structure" pre-stored in the local memory of the first computing device, enabling the meta-thread to directly access local memory to complete physical address translation without being limited to specific open segment cache hardware implementations. The "target offset" represents the specific relative position or byte offset length of the data that the current meta-thread expects to access within the target memory region on the other end. The "number of data elements to be accessed" defines the total number of independent data units expected to be read or written consecutively in this cross-device memory access operation, thus clarifying the data batch size of a single low-level physical memory access instruction.

[0081] In some embodiments, the first computing device is also associated with an open segment cache, which is a hardware cache structure that differs from traditional page tables. The open segment cache pre-records the mapping relationship between logical device views and physical hardware topology. The open segment cache is used to temporarily cache frequently accessed open segment data structures, which can further improve the lookup speed of the underlying physical address and effectively reduce cross-device memory access latency.

[0082] In the scheme of this application, an open segment cache is associated with the first computing device, so that when the meta thread initiates a cross-device memory access instruction, it does not need to embed a complex virtual address in the instruction, but directly carries the target open segment address and the target offset; therefore, the following describes in detail how to establish the open segment cache.

[0083] Reference Figure 3 Prior to responding to a memory access instruction initiated by a meta-thread executed on the first computing device, the memory access method for the computing device provided in this application further includes the open segment cache generation steps shown in steps 301 to 303.

[0084] Step 301: Obtain the predefined memory segment information of the second computing device. The memory segment information of the second computing device includes the logical device identifier, logical base address, and logical size.

[0085] Step 302: Map the logical device identifier to the target physical device identifier corresponding to the second computing device in the extended network.

[0086] Step 303: Based on the target physical device identifier, logical base address, and logical size, construct a memory object and store the memory object in the open segment cache.

[0087] Steps 301 to 303 are described in detail below.

[0088] In step 301 of some embodiments, before performing actual cross-device memory data interaction, the first computing device first obtains predefined memory segment information of the second computing device through system software or a driver. Here, "memory segment information" refers to the configuration parameters of a contiguous storage space that the second computing device (i.e., the peer interconnect device in the extended network) opens to and allows to be shared with the first computing device.

[0089] Specifically, the memory segment information of the second computing device includes a logical device identifier, a logical base address, and a logical size. The "logical device identifier" is a virtualized device number visible to user space or applications (e.g., consecutively arranged numbers like 0, 1, 2, etc.), which shields the software layer from the complex underlying hardware physical topology. The "logical base address" represents the starting position of this open memory segment in the logical address space. The "logical size" defines the range of data capacity contained in this memory segment, thus providing the necessary logical view foundation for subsequent software-hardware decoupling and underlying physical addressing mapping.

[0090] In step 302 of some embodiments, the underlying operating system or device driver of the first computing device (or the underlying operating system or device driver associated with the first computing device) maps the logical device identifier to the target physical device identifier of the second computing device in the scale-up network. Since the first computing device and the second computing device are physically interconnected through the scale-up network, the underlying hardware routing and data transmission mechanism can only identify the actual physical hardware number of the device and cannot directly process the logical number of the upper layer.

[0091] Therefore, this application's solution involves searching a pre-maintained device topology mapping table to accurately translate and convert the user-level, continuous logical device identifiers into target physical device identifiers that have unique routing direction in the actual physical interconnection network for the second computing device. This decoupled mapping and conversion operation ensures both the generality and portability of the upper-layer application code and meets the strict physical addressing requirements of direct point-to-point communication in the underlying hardware network.

[0092] In step 303 of some embodiments, the first computing device constructs a memory object based on the target physical device identifier, logical base address, and logical size, and stores the memory object in an open segment cache. Specifically, after completing the conversion from logical device identifier to physical device identifier, the first computing device structurally encapsulates the "target physical device identifier" (which has real network routing significance) with the "logical base address" and "logical size" (which define the start and boundary range of memory access), and combines them to generate a memory object with an open segment (Aperture) data structure.

[0093] Once constructed, the first computing device distributes and permanently stores the memory object in its dedicated hardware storage structure, namely the Aperture Cache. By pre-residing these core mapping relationships and boundary information in the underlying cache close to the computing unit or hardware hub, the first computing device can directly perform extremely low-latency table lookups and indexes from the underlying hardware during subsequent runtime, without relying on system software intervention.

[0094] Reference Figure 4 This is a schematic diagram illustrating an open segment object mapping and generation process provided in an embodiment of this application. For example... Figure 4 As shown, before performing direct physical memory access across devices, the first computing device first defines the other device's memory segment information on the software or driver side. This information explicitly includes the logical device identifier (i.e., Figure 4The logical device identifier (XPU ID), logical base address, and logical size are defined in the data structure. To shield the user space from the topological complexity of the underlying physical communication network, the logical device identifier typically uses a continuous numbering format from 0 to the total number of processors minus 1 (i.e., from 0 to the total number of XPUs - 1). Subsequently, the first computing device performs a decoupling transformation from the logical view to the underlying physical view, accurately mapping the continuous logical device identifier to the physical device identifier (i.e., the physical XPU ID) that is actually routable in the extended network. Based on this physical device identifier, along with the aforementioned base address and size data, a structured open segment (Aperture) memory object is created. Then, the first computing device passes the memory address of the Aperture object to the system kernel operating the first computing device, so that it can be distributed and permanently stored in the open segment cache at the bottom layer of the first computing device. Finally, through the above series of initialization processes, the first computing device successfully obtains the open segment address bound to the target device. This address will be directly distributed to the metathread of the computing device, thus laying the necessary data foundation for bypassing the page table mechanism in the subsequent runtime state and directly completing secure cross-device physical memory access at the hardware layer through a simple open segment address index.

[0095] Reference Figure 5 This is a schematic diagram illustrating the hierarchical storage and mapping relationship between open segment objects in local memory and open segment cache, provided in an embodiment of this application. For example... Figure 5 As shown, during the offline configuration or initialization phase of the first computing device, when the underlying driver or operator of the first computing device creates multiple open segment memory objects globally required by the first computing device based on the target physical device identifier, logical base address, and logical size (e.g., ... Figure 5 After the open segments 0 to 7 are fully maintained in the "Memory" structure on the right, these memory objects will initially reside statically in the large local memory of the computing device. However, considering the extremely low latency addressing requirements at runtime and the physical limitations of the underlying hardware cache capacity, the first computing device will selectively allocate some of the currently urgently needed or frequently accessed open segment objects (e.g., open segments 0 to 7) based on the access policy or the activity of instruction execution. Figure 5The open segments 0, 1, 4, and 6 (pointed to by the arrows on the left) are extracted from local mass memory and precisely mapped and persisted to the dedicated hardware layer within the first computing device, namely the open segment cache (ApertureCache). This hierarchical transfer design from global memory to local hardware cache not only ensures the integrity of the open memory segment topology information of all peer devices in the extended network, but also ensures that when the metathread of the first computing device subsequently initiates cross-device memory access instructions, the underlying hardware logic can directly and quickly hit the physical attributes of the target memory object in the local open segment cache with the shortest possible clock cycle. This lays a crucial hardware storage foundation for completely abandoning traditional page tables and achieving ultra-fast cross-device physical pass-through without virtual addressing.

[0096] Through steps 301 to 303 above, by pre-defining the logical memory segment information of the peer device before the actual memory access instruction is initiated, and statically converting it into a memory object containing the real physical device identifier and addressing boundaries, and then sending it to the underlying hardware cache, the solution of this application effectively achieves complete decoupling between the user-mode logical device view and the underlying hardware physical topology. This pre-construction stage not only eliminates the need for applications to be aware of complex underlying physical interconnect details, but more importantly, it transforms the cumbersome page table translation work, which originally needed to be dynamically executed by the Memory Management Unit (MMU) every time memory access was performed, into a one-time static mapping configuration. This lays the core data foundation for the subsequent hardware to directly perform page table lookup-free addressing and out-of-bounds safety checks with a single instruction in runtime, thereby fundamentally ensuring extremely high bandwidth efficiency and security of cross-device memory communication between heterogeneous processors in a distributed cluster.

[0097] Furthermore, the memory access instructions in the embodiments of this application can be of various types, as described below.

[0098] Reference Figure 6 The memory access instruction does not carry a virtual address. The initiation of the memory access instruction includes at least one of the following steps 601 to 603.

[0099] Step 601: In response to a load instruction initiated by the metathread of the first computing device, generate a memory access instruction for reading data from the actual physical access address of the second computing device.

[0100] Step 602: In response to a storage instruction initiated by the metathread of the first computing device, generate a memory access instruction for writing data from the actual physical access address of the second computing device.

[0101] Step 603: In response to an atomic instruction initiated by the meta-thread of the first computing device, generate a memory access instruction for performing atomic operations from the actual physical access address of the second computing device.

[0102] Steps 601 to 603 are described in detail below.

[0103] In step 601 of some embodiments, when performing a cross-device data fetch operation, a memory access instruction for reading data from the actual physical access address of the second computing device is generated in response to a load instruction initiated by the meta thread of the first computing device. In this process, a "meta thread" refers to the basic scheduling unit that executes computing tasks in the underlying hardware of the first computing device (e.g., various heterogeneous AI accelerators); and a "load instruction (i.e., load_peer instruction)" refers to a read operation instruction for fetching external data into a local register or local cache.

[0104] Since this application aims to eliminate the virtual addressing mechanism, when a meta-thread needs to read data from the peer, the underlying hardware or instruction scheduling module will not generate traditional opcodes with virtual addresses. Instead, it will directly encapsulate the pre-determined target open segment information to generate a memory access instruction specifically for physical passthrough. This memory access instruction can penetrate the network and directly use the parsed "actual physical access address" to accurately read the target data from the physical storage medium corresponding to the second computing device and send it back to the first computing device, thereby achieving extremely low-latency cross-chip data loading.

[0105] In step 602 of some embodiments, when performing a cross-device data push operation, a memory access instruction for writing data from the actual physical access address of the second computing device is generated in response to a storage instruction initiated by the meta-thread of the first computing device. Corresponding to the load operation, the "storage instruction (i.e., the store_peer instruction)" refers to a write operation instruction whereby the first computing device refreshes and saves locally computed data or intermediate results to external storage. In this step, when the meta-thread issues a request to write data to the peer's memory, the first computing device also skips the page table mapping stage of the Memory Management Unit (MMU) and directly generates a memory access instruction without any virtual addressing overhead. This instruction directly and precisely writes the valid data locally on the first computing device to the physical storage unit pointed to by the "actual physical access address" of the second computing device. This process ensures that in a large-scale parallel computing cluster, heterogeneous processor nodes can share and update distributed data at high speed and high bandwidth using the most direct physical communication method.

[0106] In step 603 of some embodiments, for the critical concurrency synchronization scenario in distributed computing, a memory access instruction for performing atomic operations from the actual physical access address of the second computing device is generated in response to the atomic instruction initiated by the meta-thread of the first computing device. An "atomic instruction" (i.e., an atomic_peer instruction) is a single, indivisible computation instruction that cannot be interrupted during execution. It is commonly used in locking mechanisms, counter updates, and state synchronization in multi-threaded or multi-node environments to avoid data contention. In this step, the meta-thread can not only directly read and write to the peer's memory but also directly initiate hardware-level concurrency control requests to the peer's memory. The memory access instruction for atomic operations generated by the first computing device can directly trigger and complete atomic operations such as "read-modify-write back" natively on the data storage bit corresponding to the "actual physical access address" of the second computing device. This design of directly performing synchronization operations on the peer's physical address avoids the high communication overhead caused by calls to the first computing device or complex software locks, greatly ensuring data consistency during multi-device collaboration.

[0107] Through steps 601 to 603 above, by defining three core physical operations—load, store, and atomic—that do not carry virtual addresses, a complete and comprehensive cross-device direct memory access instruction set is provided for the first computing device. This not only enables the computing device to cover all necessary distributed computing communication scenarios at the underlying hardware level, such as data reading, data writing, and multi-node state synchronization, but also completely blocks the dependence of traditional instructions on the virtual memory page table translation mechanism by forcibly binding the actual physical access address directly during the instruction generation stage. This streamlined and low-level instruction set design maximizes the release of the interconnect bandwidth of the extended network and greatly reduces the hardware overhead and end-to-end latency of collaborative memory access between heterogeneous processors.

[0108] Step 202: Based on the target open segment address, obtain the corresponding open segment data structure from the local memory of the first computing device, wherein the open segment data structure includes at least the target physical device identifier and the target physical base address.

[0109] Step 202 will be described in detail below.

[0110] In step 202 of some embodiments, after obtaining the aforementioned instruction parameters, the first computing device retrieves the corresponding open segment data structure from its local memory based on the target open segment address. Specifically, the first computing device uses the extracted target open segment address as an index key or pointer to directly access its local memory to read the corresponding open segment data structure. This open segment data structure includes at least a target physical device identifier and a target physical base address. The target physical device identifier is the actual physical hardware number or underlying routing address of the target peer processor in the extended network, and the target physical base address is the starting absolute physical address of the memory data segment shared with the first computing device in the local physical memory of the target peer processor.

[0111] By retrieving the data structure directly from local memory, the processing system enables the metathread to switch the addressing target from a logical object in the local view to a physical hardware node in the global view without relying on hardware cache.

[0112] When the first computing device is associated with an open segment cache, the target open segment address can be directly used as the index key value and input into the open segment cache for fast hardware-level table lookup retrieval, thereby hitting and reading the corresponding underlying hardware attribute data, such as the target physical device identifier and the target physical base address, as described in detail below.

[0113] Reference Figure 7 The process of obtaining the corresponding open segment data structure from the local memory of the first computing device based on the target open segment address includes the following steps 701 to 703.

[0114] Step 701: Send the target open segment address to the open segment cache for querying.

[0115] Step 702: If a cache entry corresponding to the target open segment address is found in the open segment cache, the target physical device identifier and the target physical base address are directly obtained from the cache entry.

[0116] Step 703: If not found, access local memory according to the target open segment address to obtain the open segment data structure, and store the obtained open segment data structure in the open segment cache.

[0117] Steps 701 to 703 are described in detail below.

[0118] In step 701 of some embodiments, the underlying hardware address resolution logic of the first computing device uses the "target open segment address" extracted from the memory access instruction as a search keyword and sends it to a specially configured "open segment cache" through an internal high-speed data path for the first round of hardware-level table lookup. This step is the first high-speed line of defense for performing page table-free physical addressing.

[0119] In step 702 of some embodiments, when the underlying hardware matches the corresponding item in the open segment cache, the underlying hardware controller does not need to go out across storage levels to access the local main memory with a larger capacity but higher read latency. Instead, it directly extracts the target physical device identifier and target physical base address required for cross-device communication from the open segment cache with extremely low clock cycles (such as a few cycles) to improve the data throughput of the extended network.

[0120] In step 703 of some embodiments, if no corresponding item is found in the open segment cache, the underlying hardware controller will execute a fallback strategy, using the target open segment address to directly address and access the local large-capacity memory of the first computing device, and accurately read the complete open segment data structure from it. After the local memory is extracted, the processing system dynamically writes the obtained open segment data structure back and allocates it to the open segment cache. Through this dynamic loading and updating mechanism, the first computing device can make full use of the time in the meta-thread memory access process to ensure that subsequent associated accesses to the same open segment can be directly obtained from the open segment cache, thereby improving the utilization rate of data resources.

[0121] In some embodiments of this application, the first computing device specifically includes a hardware hub and at least one computing unit in its underlying physical architecture. Specifically, the "Compute Unit (CU)" serves as the core computing power carrier of the first computing device, primarily responsible for providing the physical operating environment for instruction execution and computing power scheduling for the internal meta-threads, and is the direct source of cross-device memory access instructions; while the "hardware hub (e.g., a die hub or input / output die, etc.)" is the routing hub for cross-chip or cross-die communication between the internal computing units and the external extended network, responsible for unified physical forwarding and network interconnection control of data flows crossing chip boundaries.

[0122] Reference Figure 8 This is a schematic diagram illustrating two typical physical deployment locations of an open segment cache within a first computing device, provided in an embodiment of this application. For example... Figure 8 As shown in the embodiment on the left, the open segment cache can be directly deployed inside the computing unit of the first computing device. In this architecture, when the meta-thread in the computing unit initiates a cross-device memory access instruction, the target physical device identifier and the target physical base address can be determined directly from the open segment cache inside the computing unit with extremely low clock cycle latency. Then, the routing request carrying the actual physical access address is sent out sequentially and passes through the core hub and input / output cores to reach the external extended network.

[0123] In addition, such as Figure 8As shown in another embodiment on the right, the open segment cache can also be deployed internally within the first computing device as a hardware hub for unified communication (e.g., Figure 8 Within the core (the central hub), in this architecture, computing units only need to send the raw access request containing the target open segment address to the core. The core central hub then centrally and uniformly completes the address mapping translation to the underlying physical hardware before crossing the chip boundary, and then outputs it to the extended network via the input / output core. This flexible open segment cache hardware deployment architecture can not only be optimized according to the internal area constraints and communication bandwidth requirements of different heterogeneous processors, but also ensures that the system can efficiently and seamlessly complete page table-free hardware-level physical address mapping, regardless of whether the cache is located at the edge of the computing core or the data routing hub. This provides a solid and highly flexible underlying architectural support for the entire cross-device physical memory traversal mechanism.

[0124] Based on this, refer to Figure 9 Based on the target open segment address, the corresponding open segment data structure is obtained from the local memory of the first computing device, including at least one of the following steps 901 to 902.

[0125] Step 901: Send the target open segment address to the open segment cache deployed inside the computing unit so that the target physical device identifier and the target physical base address can be determined in the computing unit.

[0126] Step 902: Alternatively, send the target open segment address to the open segment cache deployed inside the hardware hub so that the target physical device identifier and the target physical base address can be determined in the hardware hub.

[0127] In step 901 of some embodiments, the first computing device sends the target open segment address to an open segment cache deployed within the computing unit to facilitate the determination of the target physical device identifier and the target physical base address within the computing unit. Specifically, when the underlying hardware architecture adopts a deployment scheme close to the computing core, the open segment cache is directly integrated within the physical layout of the computing unit. Therefore, when a meta-thread generates a cross-device memory access request and issues a memory access instruction, the instruction parsing logic will use the shortest internal chip data path to directly deliver the obtained target open segment address to the open segment cache within the computing unit for hardware-level table lookup. Since the entire mapping index operation is completed in a closed loop within the computing unit, the first computing device can quickly hit and output the target physical device identifier and the target physical base address required for cross-device communication with extremely low clock cycle latency, thereby achieving extremely fast local response to memory access instructions.

[0128] In step 902 of some embodiments, the first computing device sends the target open segment address to an open segment cache deployed inside the hardware hub, so as to determine the target physical device identifier and the target physical base address in the hardware hub. In this implementation architecture, the "hardware hub (e.g., chip hub or input / output chip)" is the global data routing and communication control hub within the first computing device responsible for connecting various computing units with the external scale-up network. When a centralized hardware deployment architecture is adopted, the computing unit no longer maintains a specific memory mapping table, but instead sends the obtained target open segment address to the hardware hub of the first computing device via the on-chip interconnect bus. Subsequently, the open segment cache centrally deployed inside the hardware hub uniformly receives parsing requests from various computing units and performs centralized table lookup processing before the data stream actually crosses the chip physical boundary and is output to the external network to determine the target physical device identifier and the target physical base address. This implementation method, which pushes the open segment cache down to the communication hub, is particularly suitable for scenarios where multiple computing units share a peer interconnect topology. It can not only effectively save valuable silicon wafer area inside the computing unit, but also achieve unified physical addressing and management of multiple computing cores.

[0129] Through steps 901 to 902 above, by allowing the open segment cache used for page table-free address mapping to be flexibly configured inside the computing unit close to the instruction execution end, or recessed into the hardware hub responsible for global network routing, the solution of this application empowers heterogeneous computing chip designers with the ability to optimize the architecture between extremely low addressing latency and high energy-efficient area utilization. Regardless of the deployment path adopted, this mechanism can ensure that the first computing device, without abandoning the traditional memory management unit, accurately and efficiently completes the direct conversion from logical open segment addresses to underlying real physical hardware routing characteristics, thereby providing a solid and highly flexible underlying hardware architecture support for subsequent high-bandwidth, low-latency cross-device physical memory access requests.

[0130] Step 203: Determine the actual physical access address based on the target physical base address and the target offset.

[0131] Step 203 will be described in detail below.

[0132] In step 203 of some embodiments, the hardware control logic of the first computing device further determines the actual physical access address based on the target physical base address and the target offset. Specifically, the first computing device performs a fusion calculation (such as address summation logic of base address plus offset) with the target physical base address representing the start position of the target memory segment retrieved from the open segment cache and the target offset representing the relative position directly parsed from the original memory access instruction. This calculation process is executed directly and independently at the hardware level, without relying on the cumbersome virtual address translation at the page granularity by the memory management unit (MMU); through the direct operation of the base address and offset, the "actual physical access address" can be obtained, which precisely and absolutely points to the real physical space location of the target data in the underlying physical storage medium of the second computing device.

[0133] Reference Figure 10 This is a schematic diagram illustrating the logical flow of low-level physical addressing and translation based on open segment addresses, provided in an embodiment of this application. For example... Figure 10 As shown, when the underlying hardware executes the page-free addressing mechanism, the first computing device first uses the "open segment address" obtained from the memory access instruction as the input index parameter for the underlying hardware lookup logic. Subsequently, the hardware of the first computing device directly executes a dedicated lookup mechanism, that is, it quickly retrieves and locates the open segment memory object corresponding to the address in the local XPU memory (i.e., open segment cache), and accurately extracts the "physical XPU ID" (i.e., target physical device identifier) ​​and the bound target physical base address recorded in the specific field of the object. Finally, the underlying hardware logic performs a fusion operation such as adding the extracted target physical base address and the target offset carried in the original access instruction, thereby completing the "output physical address" operation (i.e., determining the actual physical access address used for final network routing).

[0134] Step 204: Based on the target physical device identifier, initiate a physical memory access request carrying the actual physical access address to the second computing device.

[0135] Step 204 will be described in detail below.

[0136] In step 204 of some embodiments, the underlying interconnect routing mechanism of the first computing device initiates a physical memory access request carrying the actual physical access address to the second computing device based on the target physical device identifier. At this time, the first computing device already possesses the absolute physical information required for precise cross-device communication. The first computing device then uses the target physical device identifier as the destination identifier for network routing, establishes a communication link through the scale-up network between devices, and sends the physical memory access request, encapsulated with the actual physical access address and the corresponding read / write operation nature, to the designated second computing device.

[0137] Since the request carries the processed real absolute physical address, the second computing device can directly respond to the request by performing point-to-point data access on its local physical memory medium without having to perform any address translation work again at the receiving end.

[0138] Because the virtual addressing-free scheme provided in this application abandons the traditional virtual page table mapping mechanism, the first processor loses the memory isolation and boundary protection functions provided by the page table when directly initiating low-level physical communication. Therefore, the scheme in this application still needs to perform out-of-bounds judgment checks, as described below.

[0139] Reference Figure 11 Based on the target physical device identifier, a physical memory access request carrying the actual physical access address is initiated to the second computing device, including the following steps 1101 to 1103.

[0140] Step 1101: Determine the corresponding open segment size from the open segment data structure based on the target open segment address.

[0141] Step 1102: Based on the target offset and the size of the open segment, perform an out-of-bounds judgment to obtain the out-of-bounds judgment result.

[0142] Steps 1101 to 1102 are described in detail below.

[0143] In step 1101 of some embodiments, to ensure the security of cross-device memory access in an environment free from traditional page table mechanisms, the underlying hardware or instruction scheduling module of the first computing device determines the corresponding open segment size from the open segment data structure based on the target open segment address. Specifically, when performing a lookup operation for physical address mapping, the first computing device not only extracts the target physical device identifier and the target physical base address using the target open segment address as an index, but also simultaneously reads the "open segment size" attribute field from the open segment data structure. The "open segment size" explicitly defines the byte length or maximum capacity limit of the contiguous physical memory space that the second computing device (i.e., the peer device in the internetwork) opens and allows to be shared with the first computing device. Through this step, the underlying hardware of the first computing device has already locally determined the legal physical boundary information of the peer target memory region before initiating an actual network request.

[0144] In step 1102 of some embodiments, the access control logic of the underlying hardware of the first computing device performs an out-of-bounds check based on the target offset and the open segment size, and obtains an out-of-bounds check result. Here, the "target offset" refers to the relative distance between the data location that the execution thread of the first computing device actually expects to operate on in this memory access instruction and the starting point of the memory segment; while the "out-of-bounds check (OOB check)" refers to the process by which the hardware logic circuit compares and verifies the target offset (or the actual offset addressing amount combined with the data bit width) with the obtained "open segment size". The underlying hardware of the first computing device uses real-time arithmetic comparison logic to check whether the range of data addresses currently expected to be accessed exceeds the maximum capacity limit specified by the memory object, as described below.

[0145] Reference Figure 12 The memory access instruction also includes the number of data elements to be accessed and the data type. Based on the target offset and the size of the open segment, an out-of-bounds judgment is performed to obtain the out-of-bounds judgment result, including the following steps 1201 to 1204.

[0146] Step 1201: Determine the corresponding displacement step size based on the data type.

[0147] Step 1202: For each data element to be accessed, perform a left shift operation on the index of the data element based on the displacement step size to obtain the left shift operation result, and sum the left shift operation result with the target offset to obtain the actual offset address of each data element.

[0148] Step 1203: When the actual offset address of an element is greater than or equal to the size of the open segment, generate an out-of-bounds judgment result indicating that the target offset has exceeded the bounds, and intercept physical memory access requests for the data element.

[0149] Step 1204: When the actual offset address of the element is less than the size of the open segment, generate an out-of-bounds judgment result indicating that the target offset has not exceeded the bounds.

[0150] Steps 1201 to 1204 are described in detail below.

[0151] In step 1201 of some embodiments, the underlying hardware control logic of the first computing device determines the corresponding shift step size based on the data type. Since the memory access instruction contains the number of data elements to be accessed (Count) and the data type (Data Type), the first computing device needs to first parse the "data type" to obtain the underlying bit width information. The "data type" represents the basic byte length occupied by a single data element in physical memory (e.g., 8-bit, 16-bit, 32-bit, or 64-bit data), while the "shift step size (Data Type Shift)" is the shift parameter corresponding to this physical bit width in the underlying hardware binary circuit operation.

[0152] The first computing device, by converting data types into shift steps, can directly replace the long-cycle multiplication operations with highly efficient binary shift operations in subsequent hardware circuit calculations, thus preparing the parameters for the extremely fast calculation of the precise physical addressing location of each data element.

[0153] In step 1202 of some embodiments, the hardware logic of the first computing device performs a left shift operation on the index of each data element to be accessed, based on a displacement step size, to obtain the left shift result. The left shift result is then summed with the target offset to obtain the actual offset address of each data element. Specifically, the "index of the data element (i.e., variable i, ranging from 0 to the total number minus 1)" represents the logical sequence number of the currently processed data element within the entire data block to be accessed. The underlying hardware operator performs a left shift operation on this index value according to the previously determined displacement step size (i.e., the underlying layer executes the i << data_type_shift logic). This left shift operation physically calculates the internal offset in bytes of the current element relative to the starting address of this requested data block.

[0154] Subsequently, the internal offset byte size (i.e., the result of the left shift operation) is summed with the "target offset" carried in the instruction, which represents the macroscopic starting position of the data block in the target memory segment. The "actual offset address of the element" obtained from this summation calculation accurately represents the absolute physical addressing offset position of this specific data element in the target peer's open segment memory space.

[0155] In step 1203 of some embodiments, the hardware security verification module of the first computing device performs a strict boundary comparison. When the actual offset address of an element is greater than or equal to the open segment size, it generates an out-of-bounds determination result indicating that the target offset has exceeded the boundary, and intercepts physical memory access requests for the data element. Specifically, the underlying hardware comparator of the first computing device performs a real-time comparison between the actual offset address of each data element calculated in the previous step and the "open segment size" pre-fixed in the local open segment cache.

[0156] Since the "open segment size" defines the upper limit of the physical memory capacity that the second computing device (the peer device) allows the current thread of the first computing device to access, once the calculated actual offset address of an element touches or exceeds this legal physical boundary (i.e., meets the condition of being greater than or equal to the open segment size), an out-of-bounds (OOB) exception signal will be immediately triggered at the hardware layer. This is the judgment result indicating that an out-of-bounds event has occurred. At this time, the underlying security protection mechanism will be directly triggered to forcibly cancel or block the current physical memory read / write request for the data element at the illegal address, thereby ensuring that the physical memory of the peer device will not be illegally accessed or maliciously damaged.

[0157] In step 1204 of some embodiments, conversely, when the actual offset address of the element is less than the open segment size, an out-of-bounds determination result is generated indicating that the target offset has not exceeded the bounds. At this time, the determination is verified by a rigorous numerical comparison of the underlying hardware to confirm that the actual physical addressing location of the specific data element falls entirely within the legal memory region authorized, opened, and shared by the second computing device. In this legal state, the hardware security verification module will directly output a security determination result indicating that the out-of-bounds determination has not exceeded the bounds (i.e., verification passed), thereby allowing the subsequent hardware routing mechanism to continue sending physical memory access requests, ensuring that legal cross-device data interaction can be successfully completed.

[0158] Reference Figure 13 This is a schematic diagram of the logic flow of an out-of-bounds determination process based on physical addressing provided in an embodiment of this application. Figure 13 As shown, when performing an Out of Bounds (OOB) check, the underlying hardware of the first computing device first performs fine-grained address calculations for each data element to be accessed (the total number of which is count). The valid value range for the index i of each data element is greater than or equal to 0 and less than the number of data elements to be accessed (count). Figure 13 In the context of 0 <= i < count, the first computing device parses the instructions to determine the corresponding shift step size based on the data type (corresponding to the data type bit width in the diagram, data_type_shift), and performs a low-level binary left shift operation on the index i of each data element based on this shift step size (i.e., ...). Figure 13 The operation `i << data_type_shift` in the code yields the result of a left shift operation representing the addressing step size within the data block.

[0159] Subsequently, the hardware logic of the first computing device sums the result of the left shift operation with the target offset carried in the memory access instruction to obtain the actual offset address of each data element in the peer memory (i.e., the corresponding offset + (i << data_type_shift)). Next, in the out-of-bounds judgment phase, the underlying hardware comparator of the first computing device performs a real-time and strict numerical comparison of the actual offset address of the element with the corresponding open segment size determined from the open segment cache. When the actual offset address of the element is greater than or equal to the open segment size (i.e., ...), the data element is considered to have an out-of-bounds offset address. Figure 12 The OOB condition `if (offset + (i << data_type_shift)) >= size` will generate... Figure 12 The boundary violation determination result shown at the bottom clearly indicates that the target offset has exceeded the limit. The physical memory access request for the data element will be immediately intercepted at the underlying link, thereby canceling the illegal access.

[0160] Through steps 1201 to 1204 above, by utilizing the data type and number of elements natively carried in the memory access instruction, and through extremely concise and efficient concurrent operations of the underlying circuitry of "index left shift and offset summation," the actual physical addressing boundary of each data element to be accessed is accurately calculated. Then, hard-core comparison and access interception are performed at the granularity of a single element and the total legal size of the open memory segment, thereby filling the security vulnerabilities that may occur under the page table-less addressing architecture. Furthermore, by relying on the underlying hardware-level parallel arithmetic logic circuitry, the time overhead of security verification is compressed to a minimum. Thus, while ensuring security protection through cross-chip physical memory penetration between heterogeneous devices, the high throughput and extremely low latency of massive fine-grained data communication in the extended cluster network are maximized.

[0161] Step 1103: When the boundary judgment result indicates that the target offset has not exceeded the boundary, initiate a physical memory access request to the second computing device.

[0162] Step 1103 will be described in detail below.

[0163] In step 1103 of some embodiments, when the boundary violation determination result indicates that the target offset is not out of bounds, a physical memory access request is initiated to the second computing device. Specifically, when the hardware logic of the first computing device confirms that the target offset is less than the open segment size, that is, when it determines that the current access is within the legal memory boundary, the security interception mechanism of the first computing device allows the access. At this time, the first computing device will finally drive the underlying network interface to encapsulate the data packet containing the previously calculated actual physical access address and the corresponding read / write opcode into a standard physical memory access request, and use the target physical device identifier to send it to the second computing device through the scale-up network to perform the actual access operation. Conversely, if an out-of-bounds violation is determined, the physical memory access request will be directly canceled or intercepted locally on the first computing device to prevent damage to the peer's memory.

[0164] Through steps 1101 to 1103 above, since the scheme of this application removes the traditional page table translation, it loses the memory isolation and out-of-bounds protection functions inherent in page tables. Therefore, by binding the open segment size in the open segment data structure and having the underlying hardware perform an out-of-bounds determination of the "offset and open segment size" before initiating a physical access request locally on the first computing device, a crucial security defense is successfully embedded in the high-speed data path of physical pass-through addressing. This mechanism not only effectively prevents illegal read / write operations and data unauthorized tampering of peer memory caused by malicious software or program errors, ensuring the security of the shared memory environment of multiple heterogeneous processors in a distributed computing cluster, but also achieves efficient and secure penetration of physical memory across devices without sacrificing the ultra-low latency and extremely high bandwidth brought by page table-free addressing, since this determination and address translation are completed in parallel and at extremely high speed in the underlying hardware.

[0165] In addition, in some optional embodiments, for cross-device read and write scenarios of irregular tensor or vector data commonly found in large-scale distributed computing clusters, this application, based on the above-mentioned out-of-bounds determination mechanism, further provides a hardware-level automatic splitting mechanism for cross-boundary unaligned data, as described below.

[0166] In real-world AI computing tasks, thread units typically use Single Instruction Multiple Data (SID) or vectorized instructions to initiate memory access to a single block of contiguous data at once. In such scenarios, it's highly likely that the first half of the data block will fall within the valid open segment space, while the latter half will exceed the upper limit of the open segment size, creating a cross-boundary critical state. A blanket interception strategy would cause the entire high-throughput computing task to crash abnormally, severely impacting the overall execution efficiency of the cluster.

[0167] Therefore, in this embodiment, during the process of the underlying hardware of the first computing device calculating the actual offset address of each data element to be accessed and performing out-of-bounds judgment, when the hardware's security verification module detects that the set of data elements requested by the current memory access instruction is in a state of "partially valid, partially out of bounds", the system hardware of the first computing device will no longer directly intercept or cancel the entire physical memory access request. Instead, the underlying control logic will automatically trigger a hardware-level transaction splitting operation. The underlying hardware will accurately locate the starting data element index where the out-of-bounds error occurred (i.e., the internal number of the first element whose actual offset address is greater than or equal to the open segment size) based on the real-time calculation result of the out-of-bounds comparison.

[0168] After identifying the critical boundary where the out-of-bounds access occurred, the underlying hardware of the first computing device automatically segments and repackages all valid data elements preceding that starting index at the electrical signal level. This generates a degraded physical memory access request containing only a subset of valid data, and then initiates this partial request to the second processor based on the target physical processor identifier. This partial release ensures that valid data interactions within the second processor's valid authorized memory range can be completed seamlessly and uninterruptedly, maximizing the recovery of effective communication bandwidth.

[0169] Meanwhile, for all out-of-bounds data elements from the starting index onwards, the underlying hardware of the first computing device provides a smooth fault tolerance and degradation processing strategy. At this point, the underlying hardware of the first computing device automatically generates a local exception mask accurate to the specific index bit width and returns this local exception mask to the meta-thread of the first processor that initiated the instruction via the underlying status register. This allows the upper-level scheduling algorithm to clearly identify which tail data failed to be successfully accessed across devices, and the software layer can then decide whether to perform remedial calculations. Alternatively, the underlying hardware of the first computing device can automatically redirect these out-of-bounds data element read / write operations to a pre-defined safety overflow buffer on the first processor for temporary storage to prevent direct data loss.

[0170] By introducing the aforementioned fine-grained hardware-level transaction partitioning and fault tolerance mechanism for cross-boundary unaligned data, the solution in this application can overcome the technical defects of the system being prone to crashing due to the lack of page table interrupts under the pure physical addressing architecture. Furthermore, it provides extremely strong memory access robustness of heterogeneous acceleration chips without virtual addressing under the premise of extremely low clock cycle latency. Thus, it provides stable, efficient and highly flexible underlying hardware architecture support for scaling up networks to process massive and irregularly bounded AI distributed data streams.

[0171] In addition, refer to Figure 14After constructing the memory object and storing the memory object in the open segment cache, the memory access method for the computing device provided in this application further includes the following steps 1401 to 1402.

[0172] Step 1401: When the metathread executes memory access instructions, keep the memory objects in the open segment cache in an unmodifiable static locked state.

[0173] Step 1402: Before extracting the memory object, perform access permission verification on the memory access instruction based on the read and write permission feature bits in the memory object, obtain the access permission verification result, and when the access permission verification result indicates that the memory object has read and write permissions, perform the memory object extraction operation.

[0174] Steps 1401 to 1402 are described in detail below.

[0175] In step 1401 of some embodiments, when the meta-thread executes memory access instructions, the first computing device keeps the memory objects in the open segment cache in an unmodifiable static locked state. Specifically, since this application abandons the traditional page table mapping mechanism, in order to ensure data consistency and addressing determinism during ultra-fast physical addressing of the underlying hardware, the "memory objects (i.e., Aperture objects, including physical device identifiers, base addresses, and sizes)" constructed and distributed to the underlying hardware are strictly controlled in the system runtime state. When the meta-thread of the first computing device is in a highly parallel instruction execution cycle, the hardware of the first computing device will block the modification permissions of the open segment cache at the physical or firmware level, making these memory objects present a read-only "static locked state". This means that in the actual cross-device memory access process, no user-space software or malicious program can tamper with these underlying physical mapping relationships and boundary configurations in real time. This static locking design completely avoids the concurrency conflicts and addressing errors caused by dynamic modification of the cache at runtime, ensuring that the underlying hardware can complete the table lookup operation with a stable and extremely low latency clock cycle.

[0176] In step 1402 of some embodiments, before retrieving the memory object, the underlying hardware of the first computing device performs access permission verification on the memory access instruction based on the read / write permission feature bits in the memory object, obtains the access permission verification result, and performs the memory object retrieval operation when the access permission verification result indicates that the memory object has read / write permissions. In this process, the "read / write permission feature bit" is a key security attribute identifier pre-configured in the open segment cache memory object, which precisely defines the specific operation permissions granted by the second computing device (i.e., peer device in the Internet) to the current open memory segment (e.g., read-only, write-only, or both).

[0177] When the metathread of the first computing device issues a memory access instruction (such as a load, store, or atomic instruction) attempting to access the open segment, the underlying hardware verification module first intercepts and extracts the operation attributes of the instruction, and strictly compares them with the read / write permission feature bits locked in the memory object. If the actual operation of the instruction (e.g., an attempt to execute a write instruction to a read-only segment) violates the authorization, the verification fails, and the system directly blocks the extraction of the object and subsequent addressing; only when the operation attributes of the instruction completely match the read / write permission feature bits, that is, when the access permission verification result indicates that it has legitimate permissions, will the hardware allow the formal extraction operation of the memory object, and then continue the subsequent base address fusion and out-of-bounds judgment process.

[0178] Through steps 1401 and 1402 above, by forcibly placing the open segment cache into a statically locked state at runtime, this application eliminates the security risk of unauthorized modification of the mapping configuration during runtime, while also eliminating the complex overhead of cache synchronization and consistency maintenance, maximizing the hardware efficiency of underlying addressing. Furthermore, by introducing fine-grained permission verification based on read / write permission feature bits in advance, it mitigates the potential for unauthorized operations that may result from missing page tables. This combined strategy of "static locking + pre-verification of permissions" not only provides a high-speed communication path for heterogeneous processor collaboration in the extended network, but also ensures that cross-device direct physical memory access possesses financial-grade data isolation and system security.

[0179] Through steps 201 to 204 above, a cross-device direct physical memory access mechanism without virtual addressing is constructed. By directly carrying the open segment address and offset in the memory access instruction, and utilizing the meta-thread executing on the first computing device to directly obtain the physical network topology identifier and base address, this avoids the complex memory management unit support and high address translation overhead required by traditional page table mapping. This execution process not only enables heterogeneous processor devices that do not support virtual addressing at the underlying level to seamlessly access the interconnect network and achieve direct cross-chip access, but also significantly reduces the communication latency of massive fine-grained memory access operations, and significantly improves the compatibility of memory collaboration among multi-processor nodes in a distributed computing cluster and the overall data throughput efficiency.

[0180] Furthermore, embodiments of this application also provide another type of second computing device (i.e., such as...) that is connected to the first computing device in a distributed computing cluster. Figure 1 The memory access method of any processor device shown (which can be any type of heterogeneous computing unit). See reference. Figure 15 This is an optional flowchart of a memory access method for a computing device applied to a second computing device, provided in an embodiment of this application. Figure 15 The method may include, but is not limited to, steps 1501 to 1503. It is also understood that this embodiment... Figure 15 The order of steps 1501 to 1503 is not specifically limited. The order of steps can be adjusted or some steps can be reduced or added according to actual needs.

[0181] Step 1501: Receive a physical memory access request from the first computing device. The physical memory access request carries the actual physical access address. The actual physical access address is determined by the first computing device based on the target physical base address and the target offset. The target physical base address is obtained by the first computing device through parsing the target open segment address using the associated open segment cache.

[0182] Step 1502: Determine the corresponding memory access instruction type based on the physical memory access request.

[0183] Step 1503: In the local physical memory of the second computing device, execute the corresponding memory access operation according to the memory access instruction type and the actual physical access address.

[0184] Steps 1501 to 1503 are described in detail below.

[0185] In step 1501 of some embodiments, the second computing device (i.e., the peer heterogeneous computing device in the Internet) acting as the cross-device communication receiver will first receive a physical memory access request from the first computing device. This "physical memory access request" is a data packet directly addressed to the underlying hardware storage medium. It does not carry any virtual addresses that require secondary translation by the operating system or memory management unit (MMU), but instead directly carries the absolute "actual physical access address."

[0186] The actual physical access address is pre-processed locally by the initiating first computing device. Specifically, the first computing device obtains the "target open segment address" through memory access instructions issued within its executed meta-thread, thereby acquiring the "target physical base address" pointing to the second computing device. This base address is then directly summed with the "target offset" in the instruction at the low-level hardware level. This ensures that when the second computing device receives the request through the network interface of the scale-up network, the addressing information it contains is already precise, valid, and directly usable for low-level electrical signal addressing—the actual physical coordinates.

[0187] In step 1502 of some embodiments, the underlying interface control logic or memory controller of the second computing device parses and determines the corresponding memory access instruction type based on the received physical memory access request. Since the cross-chip physical memory access request not only contains addressing information but also encapsulates specific underlying opcodes or control signaling, the second computing device identifies the specific operation nature that the first computing device expects to perform on the physical address by hardware decoding these data packet headers or control bits.

[0188] These memory access instruction types typically correspond to core low-level data interaction behaviors in a distributed computing cluster, such as physical loading (corresponding to read operations) to pull data from a second computing device to the physical storage of a first computing device, physical loading (corresponding to write operations) to push data from a first computing device to the physical storage of a second computing device, and hardware-level atomic instructions (corresponding to indivisible read-modify-write-back operations) to synchronize state among multiple nodes.

[0189] In step 1503 of some embodiments, after determining the specific addressing location and operation nature, the second computing device directly executes the corresponding memory access operation in its local physical memory based on the memory access instruction type and the actual physical access address. Since the passed "actual physical access address" is already an absolute physical address, the memory controller of the second computing device directly drives the word lines and bit lines of the local physical memory (e.g., HBM or local DRAM bound to the second computing device) for addressing. Subsequently, based on the aforementioned determined "memory access instruction type," data read, data write, or atomic computation operations are natively executed on the corresponding physical storage unit, and the execution result or the read data is returned to the first computing device via the extended network according to the protocol specifications.

[0190] Through steps 1501 to 1503 above, by directly receiving and processing the actual physical access address that has been pre-completed by the initiating end with "page table-free mapping" and "boundary security verification," the second computing device is relieved of the computational burden of address translation when performing memory access locally. This extremely simple response mechanism of "direct physical coordinate input + direct local physical read / write" not only adapts to heterogeneous AI acceleration chips that lack complex virtual memory management capabilities or do not support virtual addressing, but also achieves seamless interconnection of memory pools between multi-processor nodes at the hardware level, thereby providing extremely low latency, high bandwidth, and cross-device direct memory access capabilities for large-scale distributed computing and chip-level collaboration.

[0191] This application also provides a computing device memory access system that can implement the above-described computing device memory access method, see reference. Figure 16 The device 1600 includes:

[0192] The first computing device 1610 is configured to respond to a memory access instruction initiated by a meta-thread executed on the first computing device, obtain a target open segment address and a target offset from the memory access instruction, obtain a corresponding open segment data structure from the local memory of the first computing device based on the target open segment address, wherein the open segment data structure includes at least a target physical device identifier and a target physical base address, determine the actual physical access address based on the target physical base address and the target offset, and initiate a physical memory access request carrying the actual physical access address to the second computing device based on the target physical device identifier.

[0193] The second computing device 1620 is communicatively connected to the first computing device and is used to receive physical memory access requests from the first computing device. The physical memory access request carries the actual physical access address. Based on the physical memory access request, the corresponding memory access instruction type is determined. In the local physical memory of the second computing device, the corresponding memory access operation is executed according to the memory access instruction type and the actual physical access address.

[0194] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, the specific implementation of the computing device memory access system is basically the same as the specific implementation of the computing device memory access method described above, and will not be repeated here.

[0195] This application also provides an electronic device, including:

[0196] At least one memory;

[0197] At least one processor;

[0198] At least one program;

[0199] The program is stored in memory, and the processor executes at least one program to implement the memory access method of the computing device described above in this application. The electronic device can be any smart terminal, including mobile phones, tablets, personal digital assistants (PDAs), in-vehicle computers, etc.

[0200] Please see Figure 17 , Figure 17 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes:

[0201] The processor 1701 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0202] The memory 1702 can be implemented in the form of ROM (Read Only Memory), static storage device, dynamic storage device, or RAM (Random Access Memory). The memory 1702 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1702, and the processor 1701 calls and executes the memory access method of the computing device in the embodiments of this application.

[0203] The input / output interface 1703 is used to implement information input and output;

[0204] The communication interface 1704 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0205] Bus 1705 transmits information between various components of the device (e.g., processor 1701, memory 1702, input / output interface 1703, and communication interface 1704);

[0206] The processor 1701, memory 1702, input / output interface 1703 and communication interface 1704 are connected to each other within the device via bus 1705.

[0207] This application also provides a storage medium, which is a computer-readable storage medium, storing a computer program that, when executed by a processor, implements the memory access method of the computing device described above.

[0208] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0209] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0210] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0211] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; 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.

[0212] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0213] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0214] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0215] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The coupling or direct coupling or communication connection between the shown or discussed units may be through some interfaces, or indirect coupling or communication connection between the apparatus or units, and may be electrical, mechanical, or other forms.

[0216] The units described above 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0217] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0218] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or 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 multiple 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 of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0219] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A memory access method for a computing device, characterized in that, include: In response to a memory access instruction initiated by a meta-thread executed on the first computing device, the target open segment address and the target offset are obtained from the memory access instruction; Based on the target open segment address, the corresponding open segment data structure is obtained from the local memory of the first computing device, wherein the open segment data structure includes at least the target physical device identifier and the target physical base address; Based on the target physical base address and the target offset, the actual physical access address is determined; Based on the target physical device identifier, a physical memory access request carrying the actual physical access address is initiated to the second computing device; Wherein, the target open segment address is an address pointer or identifier pointing to a specific open segment data structure pre-stored in the local memory of the first computing device; the target offset represents the specific relative position or byte offset length of the data that the current meta-thread expects to access in the target memory region of the peer; the target physical base address is the starting physical absolute address of the memory data segment shared with the first computing device in the local physical memory of the target peer processor.

2. The memory access method for a computing device according to claim 1, characterized in that, The first computing device is associated with an open segment cache; The step of obtaining the corresponding open segment data structure from the local memory of the first computing device based on the target open segment address includes: Send the target open segment address to the open segment cache for querying; If a cache entry corresponding to the target open segment address is found in the open segment cache, the target physical device identifier and the target physical base address are directly obtained from the cache entry; If not found, the local memory is accessed according to the target open segment address to obtain the open segment data structure, and the obtained open segment data structure is stored in the open segment cache.

3. The memory access method for a computing device according to claim 2, characterized in that, The first computing device includes a hardware hub and at least one computing unit, wherein the open segment cache is deployed inside the computing unit or inside the hardware hub.

4. The memory access method for a computing device according to claim 3, characterized in that, The step of sending the target open segment address to the open segment cache for querying includes: The target open segment address is sent to the open segment cache deployed inside the computing unit, and the target physical device identifier and the target physical base address are determined in the computing unit; Alternatively, the target open segment address can be sent to the open segment cache deployed inside the hardware hub, and the target physical device identifier and the target physical base address can be determined in the hardware hub.

5. The memory access method for a computing device according to claim 1, characterized in that, The memory access instruction does not carry a virtual address, and the initiation of the memory access instruction includes any one of the following steps: In response to a load instruction initiated by the metathread of the first computing device, a memory access instruction is generated for reading data from the actual physical access address of the second computing device; In response to a storage instruction initiated by the metathread of the first computing device, a memory access instruction is generated for writing data from the actual physical access address of the second computing device; In response to an atomic instruction initiated by the metathread of the first computing device, a memory access instruction is generated for performing atomic operations from the actual physical access address of the second computing device.

6. The memory access method for a computing device according to claim 1, characterized in that, The step of initiating a physical memory access request carrying the actual physical access address to the second computing device based on the target physical device identifier includes: Based on the target open segment address, determine the corresponding open segment size from the open segment data structure; Based on the target offset and the size of the open segment, an out-of-bounds determination is performed to obtain the out-of-bounds determination result; When the boundary determination result indicates that the target offset has not exceeded the boundary, a physical memory access request is initiated to the second computing device.

7. The memory access method for a computing device according to claim 6, characterized in that, The memory access instruction also includes the number of data elements to be accessed and their data types. The out-of-bounds determination based on the target offset and the open segment size, and the resulting out-of-bounds determination, includes: Determine the corresponding displacement step size based on the data type described above; For each data element to be accessed, the index of the data element is shifted left based on the displacement step size to obtain the left shift result. The left shift result is then summed with the target offset to obtain the actual offset address of each data element. When the actual offset address of the element is greater than or equal to the size of the open segment, an out-of-bounds determination result is generated to indicate that the target offset has exceeded the bounds, and physical memory access requests for the data element are intercepted. When the actual offset address of the element is less than the size of the open segment, an out-of-bounds determination result is generated, indicating that the target offset has not exceeded the bounds.

8. The memory access method for a computing device according to claim 1, characterized in that, Prior to responding to a memory access instruction initiated by a metathread executed on the first computing device, the method further includes: Obtain predefined memory segment information of the second computing device, which includes logical device identifier, logical base address, and logical size; The logical device identifier is mapped and converted into the target physical device identifier corresponding to the second computing device in the extended network; Based on the target physical device identifier, the logical base address, and the logical size, a memory object is constructed and stored in the open segment cache.

9. The memory access method for a computing device according to claim 8, characterized in that, After constructing the memory object and storing the memory object in the open segment cache, the method further includes: When the memory access instruction is executed by the meta-thread, the memory object in the open segment cache is kept in an unmodifiable static locked state; Before extracting the memory object, the access permission of the memory access instruction is checked based on the read and write permission feature bits in the memory object to obtain the access permission check result. When the access permission check result indicates that the memory object has read and write permissions, the extraction operation of the memory object is performed.

10. A memory access method for a computing device, characterized in that, The method includes: The system receives a physical memory access request from a first computing device. The physical memory access request carries an actual physical access address. The actual physical access address is determined by the first computing device based on a target physical base address and a target offset. The target physical base address is obtained by the first computing device based on a target open segment address and by obtaining the corresponding open segment data structure from the local memory of the first computing device. The target open segment address and the target offset are obtained by the first computing device from the memory access instructions initiated by the executing meta-thread. Based on the physical memory access request, determine the corresponding memory access instruction type; In the local physical memory of the second computing device, the corresponding memory access operation is executed according to the memory access instruction type and the actual physical access address; Wherein, the target open segment address is an address pointer or identifier pointing to a specific open segment data structure pre-stored in the local memory of the first computing device; the target offset represents the specific relative position or byte offset length of the data that the current meta-thread expects to access in the target memory region of the peer; the target physical base address is the starting physical absolute address of the memory data segment shared with the first computing device in the local physical memory of the target peer processor.

11. A memory access system for a computing device, characterized in that, Includes a first computing device and a second computing device that are interconnected and communicate with each other; The first computing device is configured to respond to a memory access instruction initiated by a meta-thread executed on the first computing device, obtain a target open segment address and a target offset from the memory access instruction, obtain a corresponding open segment data structure from the local memory of the first computing device based on the target open segment address, wherein the open segment data structure includes at least a target physical device identifier and a target physical base address, determine an actual physical access address based on the target physical base address and the target offset, and initiate a physical memory access request carrying the actual physical access address to the second computing device based on the target physical device identifier. The second computing device is configured to receive a physical memory access request from the first computing device, the physical memory access request carrying an actual physical access address, and based on the physical memory access request, determine the corresponding memory access instruction type, and execute the corresponding memory access operation in the local physical memory of the second computing device according to the memory access instruction type and the actual physical access address; Wherein, the target open segment address is an address pointer or identifier pointing to a specific open segment data structure pre-stored in the local memory of the first computing device; the target offset represents the specific relative position or byte offset length of the data that the current meta-thread expects to access in the target memory region of the peer; the target physical base address is the starting physical absolute address of the memory data segment shared with the first computing device in the local physical memory of the target peer processor.

12. An electronic device, characterized in that, The device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the memory access method of the computing device as described in any one of claims 1 to 9 or the memory access method of the computing device as described in claim 10.

13. A 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 memory access method of the computing device as described in any one of claims 1 to 9 or the memory access method of the computing device as described in claim 10.

Images