Data structure processing

By providing data structure processing instructions and metadata register support within the CPU, the performance bottleneck and context switching latency issues between the hardware accelerator and the CPU are resolved, resulting in more efficient data structure processing and improved security.

CN113498507BActive Publication Date: 2026-04-03ARM LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2020-03-23
Publication Date
2026-04-03

AI Technical Summary

Technical Problem

Existing technologies suffer from performance degradation due to frequent data transfers between hardware accelerators and the CPU when processing data structures that span multiple memory addresses, as well as extended context switching times, especially in mixed processing operations and multitasking environments.

Method used

The CPU architecture provides an instruction decoder to support data structure processing instructions, and uses a data structure metadata register to store metadata of memory addresses so that only necessary state information is saved during context switching, reducing the amount of data to be saved and improving switching efficiency.

Benefits of technology

By reducing context switching latency and data transfer frequency, the performance and scalability of data structure processing are improved, avoiding the execution bottleneck of hardware accelerators and potential security threats.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113498507B_ABST
    Figure CN113498507B_ABST
Patent Text Reader

Abstract

An apparatus includes an instruction decoder and a processing circuitry system. In response to a data structure processing instruction specifying at least one input data structure identifier and an output data structure identifier, the instruction decoder controls the processing circuitry system to perform processing operations on at least one input data structure to produce an output data structure. Each input / output data structure includes a data arrangement corresponding to multiple memory addresses. The apparatus includes two or more sets of one or more data structure metadata buffers, each set associated with a corresponding data structure identifier and designated to store metadata indicating the memory address of the data structure identified by the corresponding data structure identifier.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This technology relates to the field of data processing.

[0002] Some data processing applications may require applying processing operations to data structures, which consist of arrangements of data in memory stored at multiple memory addresses. Processing such data structures can be used in a variety of applications, such as machine learning, signal processing, or compression algorithms.

[0003] At least some examples provide an apparatus including: an instruction decoder for decoding instructions; and a processing circuit system for performing data processing in response to instructions decoded by the instruction decoder; wherein: in response to a data structure processing instruction specifying at least one input data structure identifier and an output data structure identifier, the instruction decoder is configured to control the processing circuit system to perform a processing operation on at least one input data structure identified by at least one input data structure identifier to produce an output data structure identified by the output data structure identifier; the at least one input data structure and the output data structure each include data arrangements corresponding to a plurality of memory addresses; and the apparatus includes a plurality of sets of one or more data structure metadata registers, each set of the one or more data structure metadata registers being associated with a corresponding data structure identifier and designated to store metadata indicating addresses for identifying the plurality of memory addresses of the data structure identified by the corresponding data structure identifier.

[0004] At least some examples provide a data processing method, including: in response to a decoded data structure processing instruction specifying at least one input data structure identifier and an output data structure identifier, controlling a processing circuit system to perform a processing operation on at least one input data structure identified by the at least one input data structure identifier to produce an output data structure identified by the output data structure identifier, wherein the at least one input data structure and the output data structure each include data arrangements corresponding to a plurality of memory addresses; and storing metadata indicating addresses in a plurality of sets of one or more data structure metadata registers, each set of the one or more data structure metadata registers being associated with a corresponding data structure identifier and designated to store metadata indicating addresses for identifying the plurality of memory addresses of the data structure identified by the corresponding data structure identifier.

[0005] At least some examples provide a non-transitory storage medium for storing a computer program used to control a master data processing device to emulate the execution of a target program by a target data processing device; the computer program includes: instruction decoding program logic for decoding instructions of the target program, wherein in response to data structure processing instructions specifying at least one input data structure identifier and an output data structure identifier, the instruction decoding program logic is configured to control the master data processing device to perform processing operations on at least one input data structure identified by at least one input data structure identifier to produce an output data structure identified by the output data structure identifier, the at least one input data structure and the output data structure each including data arrangements corresponding to a plurality of memory addresses; and register emulation program logic for controlling access to storage structures to emulate registers of the target data processing device, the registers including a plurality of sets of one or more data structure metadata registers, wherein each set of one or more data structure metadata registers is associated with a corresponding data structure identifier and is designated to store metadata at an indicator address for identifying a plurality of memory addresses of the data structure identified by the corresponding data structure identifier.

[0006] Further aspects, features, and advantages of this technology will become apparent from the following description, which is taken in conjunction with the accompanying drawings.

[0007] Figure 1 An example of a data processing device is illustrated schematically, which includes a processing circuitry system having instruction decoder support for data structure processing instructions;

[0008] Figure 2 An example of a data structure matrix is ​​shown;

[0009] Figure 3 An example of a data structure storage area used to store several input and output data structures is shown;

[0010] Figure 4 An example is shown where metadata indicating the address is used to identify the address where a data structure is stored in memory;

[0011] Figure 5 Examples of registers and data structure memory in the processing circuit system are shown in more detail;

[0012] Figure 6 An example is shown in which the input and output data structures have separate identifier spaces;

[0013] Figure 7 An example is shown of a fixed subset of the general-purpose registers of the data structure metadata register system used for a given data structure.

[0014] Figure 8An alternative approach is shown in which dedicated data structure metadata registers are separated from general-purpose registers.

[0015] Figure 9 This is a flowchart illustrating a method for controlling state saving in response to a context save trigger event;

[0016] Figure 10 This illustrates another example where data structure processing instructions cause the processing circuitry to load a given input data structure when it is not yet available.

[0017] Figure 11 This is a flowchart illustrating the method for restoring the control context state; and

[0018] Figure 12 Examples of available simulators are shown.

[0019] Data processing equipment may have an instruction decoder for decoding program instructions and a processing circuitry for performing data processing in response to the instructions decoded by the instruction decoder. For example, the instruction decoder may map the decoded program instructions into micro-operations or other control signals, which are sent to the processing circuitry to control which operations are performed by the processing circuitry. Some software workloads may require processing certain data structures, including arrangements of data stored in memory corresponding to multiple memory addresses. For example, some signal processing or machine learning algorithms may include operations applied to matrices, such as two-dimensional data arrangements. Furthermore, some compression algorithms may operate on blocks of a given size, and therefore data structures may correspond, for example, to one of those blocks.

[0020] When programmers write high-level code to implement such processing applications, they typically use a programming language that defines certain basic operations applied at the granularity of this data structure, such as matrix multiplication or instructions for implementing iterations of a compression algorithm applied to a given block. However, in practice, when this high-level code is compiled into a native instruction set supported by the processing circuitry, this high-level functionality often decomposes into several independent load / store instructions and arithmetic instructions that apply to individual data values ​​within the data structure, each corresponding to a single memory address. For example, a matrix multiplication operation might be compiled into several independent payloads to load individual components of the matrix, and into multiplication instructions to multiply each pair of components, followed by store instructions to store the result back to the corresponding memory address. The compiler may need to calculate how to group payloads and stores from or into memory addresses and use scalar instructions to perform the multiplication.

[0021] One approach to accelerating the processing of data structures (including data arrangements spanning multiple addresses) is to provide a hardware accelerator with dedicated hardware designed to speed up such data structure processing. Typically, such a hardware accelerator is implemented on a system-on-a-chip as a device accessible via load / store operations performed with respect to the memory system. From the CPU's (Central Processing Unit's) perspective, the CPU can simply write data to memory, which controls the hardware accelerator to perform data structure processing, and then, once the hardware accelerator has completed its operation, the CPU can read the result back from memory and subsequently continue processing it. However, this hardware accelerator approach (where the instructions supported by the CPU's instruction decoder do not support dedicated data structure processing instructions) can have several problems for certain workloads. First, while hardware accelerators are suitable for workloads where data structure processing represents most of the operations to be performed, they can be inefficient for mixed workloads that intersperse data structure processing with other types of processing operations. This is because there will be frequent situations where data must be transferred back and forth between the CPU and the hardware accelerator. For example, if instructions at the CPU must wait for the results of data structure processing to be read back from the hardware accelerator, this can significantly degrade the overall performance of the application. Another problem is that in systems where a single hardware accelerator is shared among multiple CPUs or among multiple software tasks executing on the same CPU, a given task may struggle to obtain sufficient processing time on the hardware accelerator, which can again degrade performance. Therefore, while the hardware accelerator approach may be acceptable for situations where there are relatively few tasks that require parallel use of the hardware accelerator, this approach may become unsustainable due to the increased amount of contention for its use.

[0022] Therefore, providing instruction decoder support within the CPU architecture itself for instructions processing dedicated data structures can be useful. This instruction decoder support allows processing operations to be performed at the granularity of the overall data structure, unlike independent components within the data structure. Of course, the instruction decoder can also support other instructions that also allow operations on independent components. However, by defining instructions that control the processing circuitry to perform processing operations on at least one input data structure identified by at least one input data structure identifier specified by the instructions to produce an output data structure identified by an output data structure identifier specified by the instructions, where each of the input and output data structures is a data arrangement spanning multiple memory addresses, this can significantly accelerate the execution of software applications that rely heavily on processing such data structures but do not have the execution and scalability issues associated with hardware accelerators as discussed above.

[0023] However, when instruction decoder support for data structure processing instructions is brought into the CPU or other processing components, this can raise issues regarding context switching latency. For CPUs or other processing components with instruction decoders for decoding program instructions, the following is common: when a context switch occurs between a first software workload and a second software workload, any architectural state associated with the first workload that was executing prior to the context switch may need to be saved to memory so that the second software workload can overwrite the state in the processing component's registers or other storage components. By saving the state of the first workload to memory, it means that when the first software workload needs to continue later, its state can be subsequently loaded back, and then processing of the input workload can continue from the point of interruption.

[0024] However, when support for data structure processing instructions is provided, this could mean that some implementations can provide storage components for storing processor-local data structures, and this state can be expected to be saved to memory when a context switch occurs. However, since data structures can be significantly large (e.g., 64 bytes, 256 bytes, or even 1 kilobyte or larger), and there can be several such data structures stored by the processing circuitry's storage circuitry, saving all such states to memory can have a significant impact on context switching latency or interrupt handling latency.

[0025] In the techniques discussed below, a device having a processing circuit system and an instruction decoder supporting data structure processing instructions has two or more sets of data structure metadata registers, each set having one or more registers. Each set of data structure metadata registers is associated with a corresponding data structure identifier (which may be an input data structure identifier or an output data structure identifier). Each set of one or more data structure metadata registers is designated to store metadata for an indicator address used to identify the memory address corresponding to the data structure identified by the corresponding data structure identifier. Therefore, the data structure metadata registers provide information about the location in memory where the corresponding data structure can be found. The data structure metadata registers are designated to store metadata for this indicator address at architectural levels, so it will be understood that while processing the data structure, the metadata for the corresponding indicator address will be able to be found within the corresponding set of one or more data structure metadata registers. For example, there may be fixed assignments of which registers are used as data structure metadata registers for a specific data structure identifier.

[0026] Because programmers or compilers are typically free to choose any of the processor's several general-purpose registers as the register defining the address from which data is loaded when the processor loads values ​​from memory, this approach is rare. Furthermore, in common load / store architectures, once data has been loaded from a given memory address, that address information is usually not retained, and the registers used to calculate the load target address can be frequently overwritten with other information. Therefore, most processor architectures do not designate certain registers as those assigned to persistently store metadata indicating the address of the corresponding data structure.

[0027] However, the inventors argue that by providing a designated data structure metadata register, which can be understood by software as storing metadata indicating the location of the relevant memory address of the data structure in the memory address space, context switching latency can be significantly improved. This is because it means that the operating system or other software responsible for controlling state saving, or the context saving hardware provided in some microarchitectural implementations for state saving, can choose to save only the metadata register for certain data structures that have not changed since being loaded from memory, rather than needing to store the metadata register for the entire data structure itself. In contrast, if information about the corresponding address from which the data structure was loaded has been lost, the context saving routine would need to save the entire data structure to ensure that the data can be recovered when processing of the current context is resumed. This is because such a context saving routine would be needed to recover even clean, unupdated data structures, since it is unknown which addresses will store the corresponding data structures in memory. Thus, providing a designated register at the architectural level that specifies the metadata indicating the address of the corresponding data structure provides an architectural feature that can be used to improve context switching latency.

[0028] The processing circuitry can operate according to an instruction set architecture that enables software to identify, for at least a subset of data structure identifiers, whether a data structure corresponding to one of the subsets of data structure identifiers is clean or dirty. Although not strictly necessary, it is often possible to choose a microarchitectural implementation to provide local memory for storing data structures, which can be accessed faster than directly from memory. For example, local data structure memory can be a register provided within the processor or can be a cache or temporary memory. If any such local data structure memory is provided, then if the processing circuitry updates a given data structure stored in the memory, that data structure may be dirty because it may differ from the corresponding data structure stored at an associated memory address in the memory system. By providing architectural support features that allow software programs to execute on the processing circuitry to determine whether at least a subset of data structure identifiers correspond to clean or dirty data structures, this can help speed up state saving during context switches. This is because it means that the software or circuitry responsible for state saving can identify any clean data structures that do not need to be saved to memory as part of that state saving. Instead, such clean data structures can be later loaded back into the processing circuitry from their associated memory addresses, indicated by metadata stored in the data structure metadata register set for clean data structures. In contrast, dirty data structures can be saved as part of a state saving performed during a context switch, since they may differ from the underlying data at their associated memory addresses. Note that for dirty data structures, these dirty data structures may not be stored at the actual memory address identified by the metadata of the indicated address during the state saving. Alternatively, a state saving performed during a context switch can save any processor state to a data structure at a different set of memory addresses associated with the operating system or other software responsible for controlling state saving.

[0029] Therefore, it is generally useful for processing circuit systems to operate according to an instruction set architecture that has the characteristic of enabling software to recognize that at least a subset of data structure identifiers are clean. It is unnecessary for all data structure identifiers to be recognizable as clean or dirty, and in that case, any data structure identifier whose cleanness or dirtyness is unknown can undergo state preservation during context switching.

[0030] There may be several ways an instruction set architecture allows software to identify whether certain data structure identifiers are clean or dirty. In one example, an output data structure identifier (used to identify the output data structure produced in response to a data structure processing instruction) can be defined in an identifier space completely separate from at least one input data structure identifier (which identifies at least one input data structure to be used as an operand of a data structure processing instruction). Therefore, at least one set of one or more data structure metadata registers can be associated with a data structure identifier that can only be used to represent input data structures and not output data structures. By defining identifiers for input and output data structures in separate identifier spaces, it means that the data structures associated with input data structure identifiers can always be guaranteed to be clean because these identifiers are never used to update output data structures in response to data structure processing instructions. Using this approach, input data structure identifiers effectively identify read-only inputs to data structure processing instructions, which, once loaded from memory, are only used as copies of the corresponding data structures stored in the memory system and cannot be updated relative to memory. Therefore, by using this approach, the operating system or other software controlling state saving can implicitly determine that any data structure corresponding to an input data structure identifier in the input data structure identifier space will be clean, and thus such data structures do not need to be saved to memory during state saving. Alternatively, it may be sufficient to save only the corresponding metadata from the relevant set of one or more data structure metadata registers, rather than saving the data structure itself. This can significantly reduce the amount of data saved to memory during context switching, thereby improving context switching latency.

[0031] Alternatively, another architectural approach to identifying whether a data structure is clean or dirty could be to provide at least one architecture register to store at least one dirty indicator, where each dirty indicator indicates whether the data structure corresponding to a given data structure identifier is clean or dirty. In some examples, a dirty indicator could be provided for every single data structure identifier. Alternatively, only a subset of dirty indicators could be provided for data structure identifiers. This approach implies that it is not necessary to define separate data structure identifiers for input and output data structures in separate identifier spaces. This allows a common set of data identifiers to be used for either input or output data structures, which can be advantageous if the output data structure obtained from a data structure processing instruction needs to be used as an input operand to a later operation. Alternatively, even in an architecture that does not separate input and output data structure identifiers into separate identifier spaces, providing some dirty indicators associated with output data structure identifiers can subsequently allow the operating system to determine whether the output data structure associated with a given output data structure identifier has actually been updated since it was loaded, which can provide another opportunity to avoid the need to save clean data structures to memory. The architecture register used to store the dirty indicator can be separate from the data structure metadata registers described above, or alternatively, a common set of registers can store the metadata of the indicator address and at least one dirty indicator. For example, the dirty indicator for a given data structure identifier can be stored in the same set of data structure metadata registers as the metadata of the indicator address used for the given data structure identifier.

[0032] As mentioned above, the architecture of the data structure metadata register helps improve the efficiency of context saving because, if the data structure is known to be clean, this architecture allows certain data structure identifiers to have only the corresponding metadata saved as a part of the state saving process, and not the underlying data structure. In many cases, the state saving process can be controlled by software executing on the processor, so there may not be any hardware for actually performing the state saving operation. For example, when the context switches between applications, state saving can be performed by the operating system, or when the context switches between virtual machines or operating systems, state saving can be performed by the super manager. Nevertheless, the architectural features discussed above support this kind of context saving performed by software to speed up context saving operations.

[0033] Alternatively, although not required by the instruction set architecture, some microarchitectural implementations may be chosen to provide context-saving circuitry in response to a context-saving trigger event to save a predetermined subset of the processor state to memory. The predetermined subset of the processor state may include a set of one or more data structure metadata registers corresponding to at least one data structure identifier (corresponding to a clean data structure), but may not include the data structure itself corresponding to that at least one data structure identifier. By providing context-saving circuitry in hardware to save some processor state to memory, this can further accelerate context switching compared to purely software-controlled examples, and allows hardware-controlled context saving to continue in parallel with the execution of other instructions, rather than delaying the process until the context save is complete. For example, some context-saving circuitry provided in hardware may be provided to automatically save metadata indicating the address associated with an input data structure identifier or a clean output data structure identifier to a location in memory.

[0034] Data structure metadata registers can be implemented in different ways. In one example, a dedicated set of metadata registers, separate from any general-purpose registers in the processor architecture, can be provided. General-purpose registers can be used as operands and the results of arithmetic instructions, including integer arithmetic or logical instructions. General-purpose registers can also be used as operands to calculate the address of a load or store instruction. By providing a dedicated set of data structure metadata registers, it means that even if the software needs to use general-purpose registers for other purposes, the metadata indicating the address of the data structure can be retained in the architecture. Alternatively, another approach is not to provide dedicated data structure metadata registers, but rather to provide a fixed subset of general-purpose registers accessible by non-data structure processing instructions supported by the instruction decoder on the processing circuitry system. For example, for a given data structure identifier, it may be implicit that metadata indicating the address of the corresponding data structure is stored in a hardwired subset of general-purpose registers. This approach reduces the total number of registers that need to be provided in the hardware. However, by using this approach, the software may need to ensure that from the time the metadata indicating the address of a given data structure is created until the corresponding data structure is no longer needed, other instructions are not written to a fixed subset of the general-purpose registers that serve as identifiers for one or more data structure metadata registers, in order to ensure that address information can be preserved in situations where location information control context saving and restoration are required.

[0035] In some examples, in response to data structure processing instructions, the processing circuitry may generate a load request to load a given input data structure from memory when it is not available to the processing circuitry. It is common for microprocessors to operate according to a load / store architecture, where load / store instructions for loading data from memory and storing data back to memory are separated from data processing instructions that perform arithmetic, logical, or other processing operations on operands previously loaded from memory. Therefore, we might expect that the instructions separated from data structure processing instructions should be defined for loading data structures from memory into logical storage, and that subsequent data structure processing instructions do not need to perform the load itself. This load / store approach may be one way to implement an architecture that includes data structure processing instructions as discussed above.

[0036] However, in another example, data structure processing instructions themselves may also cause the processing circuitry to generate a load request to load a given input data structure from memory when the given input data structure is not available to the processing circuitry. In some cases, data structure processing instructions may also trigger a load request to load the previous value of an output data structure from memory when the data structure processing operation to be performed depends on the previous value of the output data structure and the value of the input data structure. For example, the processing operation could be an accumulation operation, where the value obtained from processing the input data structure is added to the previous value of the output data structure to determine the new value of the output data structure. Therefore, in some cases, data structure processing instructions can trigger a load request for one or more input and output data structures involved in the processing operation.

[0037] This approach might seem counterintuitive, as loading a data structure in response to a data structure processing instruction could delay the start of processing operations on that data structure compared to a scenario where the data structure has already been loaded from memory by earlier instructions. However, the inventors argue that defining data structure processing instructions within the architecture, requiring the loading of a given input data structure from memory when it becomes unavailable, offers advantages when performing context switches between software workloads. Much of the above discussion of context switching focuses on state preservation, but another aspect of context switching is restoring the state for use with the input context to be executed after the context switch. While providing a data structure metadata register as discussed above can help avoid needing to save some data structures as part of the state preservation operation when those data structures are clean, it is still possible to reload any data structures required by the given software workload when returning from a context switch to processing that workload, and this state restoration can take some time because the data structures can be relatively large.

[0038] In an architecture where the data structure required by a given data structure processing instruction is loaded by a pre-separated load instruction, and the data structure processing instruction itself does not have the ability to load data structures when needed, then because an interrupt that may trigger a context switch can occur between the load instruction and subsequent data structure processing instructions, the operating system or the hardware circuitry for execution state restoration must assume that a given data structure saved in local memory for a given software workload before a context switch away from that workload still exists after the system switches back to that workload. Therefore, in an architecture where the data structure processing instruction itself does not have the ability to load data structures, this may mean that for a restored software workload executed after a context switch, the operating system must restore the data structure state.

[0039] While this is a perfectly feasible way to perform state recovery, it has several drawbacks if monitoring software (e.g., the operating system or super manager) must be responsible for recovering data structures. First, the monitoring software responsible for state recovery may lack any visibility into which data structures will actually be used after processing continues in the input workload, and thus the operating system or monitoring software may waste time recovering data structures that are subsequently not actually used by any subsequent instructions of the input workload. In contrast, by requesting the loading of data structure processing instructions into the input (or output) data structure when it is not yet available, the operating system does not need to worry about recovering any data structures. If any subsequent data structure processing instructions that require a specific data structure are executed, that structure will be loaded and processing can continue, but any data structures never used again by the software are not recovered, and thus this avoids unnecessarily incurring additional latency during state recovery.

[0040] Another advantage of using data structure processing instructions to load unavailable data structures is the improved security this provides. Typically, when monitoring software performs state restoration, it may be restoring a state from some region of memory—not part of the monitoring software's memory allocation, but rather part of the memory allocation associated with the thread whose state is being restored. Therefore, there is a risk that a malicious application could load a set of monitoring addresses into the metadata indicating those addresses, which could then be accessed via state restoration, exposing the monitoring software's memory allocation to side-channel attacks. In contrast, by providing data structure processing instructions to load (or reload) a given input data structure if it is not yet available, this means that the metadata indicating the data structure's address is not needed for the monitoring software, thus preventing potential opportunities for malicious attacks.

[0041] In some implementations, the microarchitecture may always defer loading a given input (or output) data structure until the relevant data structure processing instruction has been received, and therefore may not provide any ability to load the data structure requested by that data structure processing instruction before decoding / processing it. Furthermore, in some implementations, the architectural functionality of the data structure processing instructions may be implemented via circuitry operating directly on data structures in memory, which are loaded onto the processing circuitry as needed and subsequently written back to memory, and therefore may not require any additional local storage at all.

[0042] However, since memory access can be relatively slow, alternative implementations can be chosen to provide some local storage for use as a separate data structure storage circuit system from memory. This local storage can be accessed faster than memory itself and can provide temporary storage for recently used data structures or data structures requested by upcoming data structure processing instructions. Therefore, such an implementation can provide a processing circuit system with a checking circuit system for checking whether a given input data structure (or output data structure) required by a given data structure processing instruction is already available in the data structure storage circuit system. For example, at least one availability register can be provided to store data structure availability information indicating whether the data structure associated with the corresponding data structure identifier is available or unavailable, and the processing circuit system can determine the availability of a given input data structure based on that data structure availability information. The availability register can be part of the address metadata register itself or a separate set of registers. Using this approach, if a preload operation is performed to load the data structure before executing a given data structure processing instruction, the availability information can be set to indicate that the corresponding data structure is already available, and this instructs the checking circuit system not to reload the corresponding data structure from memory in response to the data structure processing instruction. Therefore, in some examples, the processing circuitry may determine that a given input or output data structure is unavailable when it is not yet saved in the data structure storage circuitry or when a data structure processing instruction has not yet requested to be loaded from memory. Preloading data structures can be performed in response to an explicit load or preload instruction decoded by the instruction decoder, or via a preload circuitry that can predict which data structures will be required by future instructions (e.g., based on tracing historical behavior regarding past instances of executing the same code).

[0043] In a system that provides a data structure storage circuitry separate from memory, an instruction decoder can control the processing circuitry to read at least one input data structure from the data structure storage circuitry in response to data structure processing instructions, and to write or update an output data structure to the data structure storage circuitry. The data structure storage circuitry can be implemented in different ways. In some cases, the data structure storage circuitry can be architecture-addressable registers, which can be explicitly referenced by software instructions to read the corresponding data structure. Alternatively, the data structure storage circuitry can include non-architecture-addressable registers, which may be unnecessary for compilation with an instruction set architecture, but can be provided as appropriate by the designer of the specific microarchitecture implementation of the processing system. Alternatively, the data structure storage circuitry can include high-speed temporary memory or a cache.

[0044] In some cases, when a given data structure is stored in a data structure storage circuit system, the processing circuit system can read data from the given data structure in a sequence different from the sequence in which the data was written to the data structure storage circuit system. This provides flexibility in handling different data structure formats (which can be stored in memory). For example, in the case of data structures that are matrices or other two-dimensional data arrangements, the data can be stored in memory in a row-by-row or column-by-column manner, and it is useful to provide a data structure storage circuit system with read / write ports that support reading data in a row-by-row or column-by-column manner or writing data back.

[0045] Regarding the data structure processing instructions themselves, several other instructions can be defined for interacting with the data structure. An example could be a data structure load instruction that specifies a target input data structure identifier or a target output data structure identifier. In response to this data structure load instruction, the instruction decoder controls the processing circuitry to write the data structure loaded from memory into the data structure storage circuitry. Such data structure load instructions can be particularly useful in architectures where the data structure processing instructions themselves do not have a given loading capability. In this case, it may be desirable that the software first contains one or more data structure load instructions for loading the relevant input or output data structures before executing the data structure processing instructions.

[0046] Depending on how the data structure metadata registers are implemented, data structure load instructions can be implemented in different ways. In one example, a data structure load instruction can load a data structure from a memory address that is derived from metadata indicating the address stored in a set of one or more data structure metadata registers, corresponding to the target input or output data structure identifier of the data structure to be loaded. For example, a data structure load instruction can specify one or more general-purpose registers that provide target address identification information to identify the address from which the data structure will be loaded, and in addition to triggering the processing circuitry to write the loaded data structure to the data structure storage circuitry, the data structure load instruction can also control the processing circuitry to update the relevant set of one or more data structure metadata registers for the data structure being loaded based on the target address identification information specified in the general-purpose registers referenced by the instruction or another property of the data structure load instruction. This approach provides the flexibility to represent address-identified metadata in the metadata registers using a format other than the explicit address identification information specified by the data structure load instruction. For example, instead of storing the actual address identification information itself, the nature of the data structure load instruction written to the data structure metadata register can include indications of which general-purpose registers are specified by the data structure load instruction, or alternatively, a program counter indicating the address of the data structure load instruction. This allows for recording a more compact form of metadata to reduce the size of the data structure metadata register. Recording a register specifying the target address identification information or a program counter of the data structure load instruction may be sufficient to allow the operating system or other software resuming execution state to recover enough information about the address associated with the given data structure that can be recovered. For example, since general-purpose registers will also be restored during context switching, simply recording references to which registers contain address information may be sufficient. Furthermore, if a program counter of the data structure load instruction is recorded, this allows software or instruction decoding circuitry to obtain the referenced instruction, decode it to identify the general-purpose registers it references, and subsequently use the restored state in those general-purpose registers to identify the target address identification information. Therefore, it may not be necessary for the data structure metadata register to explicitly and directly indicate the address information fragments needed to identify the address, as this can be done indirectly through other parameters.

[0047] Alternatively, instead of providing specific instructions to trigger the loading of data structures, in other architectural implementations, the architecture may define a pre-load instruction that specifies a target input data structure identifier. In response to the pre-load instruction, the instruction decoder controls the processing circuitry to update a set of one or more data structure metadata registers corresponding to the target input data structure identifier based on one of the following: target address identification information implicitly or explicitly specified by the pre-load instruction, or the nature of the pre-load instruction. Furthermore, this nature may be the program counter or a list of general-purpose registers specified by the pre-load instruction. Such pre-load instructions can be particularly useful in systems that support data structure processing instructions with loading capabilities, because if needed, the data structure processing instructions can load data structures from memory, eliminating the need for earlier instruction execution as a mandatory architectural feature. Alternatively, a pre-load instruction can be simply interpreted as an instruction that associates a set of target address identification information with a data structure identifier of a specific input or output data structure. This sets the address from which subsequent data structure processing instructions can load the associated data structure.

[0048] Although at the architecture level, it is unnecessary for the prepare-to-load instruction to actually load the data structure associated with the target input data structure identifier, at the microarchitecture level, the system designer may, in any case, choose to provide a processing circuitry in response to the prepare-to-load instruction. This processing circuitry generates a load request to request the transfer of the data structure associated with the target input data structure identifier from the memory address determined based on the target address identification information to the data structure storage circuitry. That is, although it is not necessary to force the prepare-to-load instruction to perform the load because the loading will be done by subsequent data structure processing instructions, it may be more efficient to execute the prepare-to-load instruction to generate the load request, as this allows for earlier initiation of the load. Therefore, the prepare-to-load instruction can be effectively used as a preload instruction. However, if processing is interrupted after the prepare-to-load instruction but before the execution of subsequent data structure processing instructions, the data structure processing instructions can still reload the requested input data structure. This can be used to avoid the operating system or other software performing state recovery having to be responsible for restoring the data structure.

[0049] It supports prepare-to-store instructions that specify a target output data structure identifier. In response to such prepare-to-store instructions, the instruction decoder can control the processing circuitry to update a set of one or more data structure metadata registers corresponding to the target output data structure identifier based on the target address identification information implicitly or explicitly specified by the prepare-to-store instructions, or another property of the prepare-to-store instructions. The prepare-to-store instructions have the function of attaching address identification metadata to a specific output data structure identifier.

[0050] The techniques discussed above can be applied to various types of data structures. In some examples, the data structure may include a two-dimensional data arrangement, providing several data components with some ordered arrangement in a two-dimensional structure. For example, the data structure may be a matrix or other forms of two-dimensional structure. In the case where the data structure is a matrix, the data structure processing instructions may include matrix multiplication instructions that specify two input data structure identifiers, and the processing operation includes performing matrix multiplication operations on the two input data structures identified by the two input data structure identifiers to produce an output data structure. Matrix multiplication instructions may be matrix multiplication and accumulation instructions, where the result of multiplying the two input matrices is added to the previous value of the output matrix to produce a new value for the output matrix. Furthermore, other forms of matrix multiplication instructions that apply operations to input matrices can be defined. For some domains, such as in machine learning, where neural networks may require a large number of matrix multiplications to multiply the weights defining the neural network model with the input variables for training the network or using the model to make predictions, providing native processor support for performing matrix operations within the CPU itself can be very useful. Matrix multiplication is very common in machine learning algorithms, and therefore speeding up this operation can significantly improve the performance of machine learning-based software.

[0051] In some examples, a data structure may correspond to several non-contiguous blocks of memory addresses within the memory system. Therefore, unlike a data structure stored in a single contiguous block of memory addresses in the memory address space, this data structure can span several blocks across disparate, non-adjacent regions of the memory address space. For the matrix example, where the overall size of the matrix actually representing the neural network can be, for example, actually larger than the unit size defined for a given data structure in the instruction set architecture, this can be particularly useful. For instance, a data structure might be defined as a matrix of a certain size, such as 4×4, 8×8, 16×16, etc. (or alternatively, it could support rectangular matrices with different numbers of rows and columns), but when the software algorithm needs to apply matrix computations at a larger matrix size, such a data structure can be decomposed into independent operations at the granularity supported by the instructions in the instruction set architecture. This means that when a large matrix is ​​stored in memory as a whole, with each row at an adjacent address in the memory address space, and each row following the components of the previous row in the address space, or alternatively, the matrix is ​​stored column by column, with each column occupying a contiguous block of memory addresses, and each column following the addresses of the previous column, this means that when data structure processing instructions operate on independent parts of that larger matrix (which can be considered independent tiles within the matrix), the rows or columns of that tile will correspond to the number of non-contiguous blocks of memory addresses. By providing instruction support to handle such tiles that span non-contiguous parts of the address space, it becomes possible to apply matrix operations more directly to matrices of more arbitrary sizes, which may be larger or smaller than the tile sizes supported by the instruction set architecture.

[0052] For a data structure corresponding to several non-contiguous blocks of memory addresses, the metadata indicating the addresses may include several pieces of information and may take several forms. For example, the metadata indicating the addresses may include at least one of the following: start address information, indicating the start address of at least one of the multiple non-contiguous blocks of memory addresses; offset information, indicating the separation between the start addresses of the multiple non-contiguous blocks of memory addresses; first size information, indicating the size of each non-contiguous block of memory addresses; and second size information, indicating how many non-contiguous blocks of memory addresses form the data structure. This type of information may be sufficient to identify any tile within a large matrix, where it is assumed that the large matrix is ​​stored row-by-row or column-by-column within the memory address space, and the tile corresponds to an independent stripe within a non-adjacent address space. The start address information may, for example, indicate the start address of the first row or first column of the tile, while the offset information may, for example, indicate the stride between the start addresses of the corresponding row or column. The first and second size information can be used to handle cases where the overall large matrix has several rows or columns, such that the number of rows or columns is not an exact multiple of the number of rows or columns in an individual tile. This allows the first and second size information to be used to mask addresses extending beyond the ends of the matrix when a tile reaches the edge of the larger matrix. The first size information can indicate the size of each non-contiguous block of memory address, and the second size information can indicate the number of non-contiguous blocks of memory address forming the data structure. Depending on whether the data structure is stored row-wise or column-wise, one of the first size information effectively indicates the number of columns in the data structure to be processed, and the other first size information indicates the number of rows, but either approach is acceptable. The first and second size information can be encoded in different ways. In one example, the first or second size information can be encoded as a numerical value indicating a count of the number of rows or columns; for example, the first size information can indicate the number of data components within a non-contiguous block of memory address, and the second size information can indicate the number of non-contiguous blocks across the entire data structure. Alternatively, the first and / or second size information can be encoded as a mask, for example, a bitmap, where bits 1 (or 0) represent active components within a non-contiguous block of memory addresses that form a portion of the data structure, and bits 0 (or 1) within the mask indicate components within a non-contiguous block that do not form a portion of the data structure. This can then be used to ensure that any data structure processing instructions are applied only to portions of non-contiguous blocks of memory addresses that represent portions of the larger overall data structure that should be processed by separate data structure processing instructions.

[0053] In addition to the start address, offset, and first and second size information, other information about the data structure may also be recorded, such as component size information indicating the size of individual data components within the data structure. For example, some forms of data structure processing instructions can support different data component sizes.

[0054] Alternatively, instead of directly indicating start address information, offset information, or first and second size information, other examples may provide metadata indicating the address that indirectly identifies this information, such as via one or more register identifiers that identify a general-purpose register holding at least one of these parameters and / or an instruction address indicator that identifies the instruction address specifying the register holding one or more of these parameters. As mentioned above, for software or circuitry that needs to restore data structures to the storage circuitry of the processing circuitry to identify the location in memory where the data structures can be found, register identifiers or instruction address indicators (e.g., program counters) may be sufficient.

[0055] In some cases, data structures can be three-dimensional or multi-dimensional data structures of order greater than 3, so the data structure does not have to be a two-dimensional data structure. Generally speaking, a data structure can be an arrangement of data components of a certain order.

[0056] Alternatively, another example of a data structure could be a simple stream of one-dimensional data components without a two-dimensional or multi-dimensional arrangement, such as a table or matrix. The techniques discussed above can also be used to provide data structures for streams of considerable size. Since the data structures can be relatively large, this can introduce difficulties regarding context switching latency, and therefore the techniques discussed above can be used to address this issue. A 64-byte data structure could, for example, correspond to a 4×4 matrix of 32-bit components. In other examples, the output data structure could be at least 256 bytes (an 8×8 matrix of 32-bit components) or 1 kilobyte (a 16×16 matrix of 32-bit components). It will be understood that other examples can use data component sizes of different numbers of bits (such as 16-bit or 64-bit), and in this case, the data structure size can again vary. However, generally, when the output data structure is at least 64 bytes in size, this begins to introduce considerable difficulties regarding context switching latency, and therefore using metadata indicating the address is useful as a way to reduce the amount of data that needs to be saved and restored during context switching.

[0057] Note that the input data structure does not necessarily need to have the same size as the output data structure. For example, when performing matrix multiplication, since the multiplication of 2N bits produces a 2N-bit result, it may produce an output data structure that is larger than the input data structure. Alternatively, some implementations may produce an output data structure of the same size as the input, for example, by truncating or rounding the multiplication result to fit the same number of bits as the input.

[0058] In some examples, unlike the use of metadata from the data structure metadata register, which is used as appropriate, to control the loading of input or output data structures from memory as discussed in the optional extensions above, the data structure processing operations performed by the processing circuitry in response to data structure processing instructions can be independent of the metadata at the indicated address. That is, the functionality for mapping the previous values ​​of at least one input data structure and the output data structure to a new value in the output data structure can be independent of the metadata at the indicated address.

[0059] However, in other examples, the processing circuitry may, in response to data structure processing instructions, rewrite the processing operations performed on at least one input data structure based on metadata indicating the address stored in a relevant set of one or more data structure metadata registers, which correspond to at least one input data structure identifier or output structure identifier. For example, if the metadata indicating the address includes first or second size information that limits the size of the data structure to a specific dimension, this can be used to reduce the number of multiplications performed on the data components of the input data structure, for example, to save power or increase performance. For instance, when processing a data structure with some inactive components masked based on the first and second size information, the circuitry logic (which would be active if processing the largest supported data structure) can be made inactive through power gating. Furthermore, if the processing operation is performed in multiple steps, some of those steps may be unnecessary based on the first and second size information.

[0060] Figure 1 An example of a data processing system 2 is illustrated, comprising several master devices 4, 6 sharing access to a memory system 8. Memory transactions issued by the master devices 4, 6 are passed to an interconnect 10, which routes transactions to the memory system and also manages the coherence between data cached at the respective hosts. The hosts may include, for example, one or more central processing units (CPUs) 4, other master devices capable of executing instructions (such as graphics processing units), or other devices 6. Such other devices may not have instruction execution capabilities but may perform certain special functions, such as controlling access to the network or serving as hardware accelerators to accelerate certain processing functions (such as signal processing or matrix multiplication).

[0061] Each CPU 4 may have an instruction decoder 12 for decoding program instructions fetched from cache or memory, and a processing circuitry 14 for performing data processing operations in response to control signals generated by the instruction decoder 12 in response to the decoded instructions. Registers 16 may be provided for storing operands of instructions to be executed and for storing results produced by the processing circuitry 14. The CPU may have one or more caches 18 for caching data, instructions, or control information (such as page table data) from the memory system. Depending on the situation, the CPU may have a context saving circuitry 20 for handling state saving during context switching, although this function can also be implemented by software executing on the CPU 4. Figure 1 The two CPUs shown in Figure 4 represent equivalent components. In reality, not all CPUs need to be identical, and some systems may have asymmetric CPUs. These asymmetric CPUs have different characteristics, such as combining higher-performance CPUs with lower-performance CPUs to compromise processing performance and power consumption. Furthermore, some systems may have more than one CPU.

[0062] Some data processing applications may involve processing individual data values, where the data values ​​are loaded from a specific address and processed by some instructions executed by the processing circuitry 14 to produce a result written to register 16, and then such a result is written back to cache 18 or memory 8 once it is no longer stored in register 16.

[0063] However, other processing algorithms can operate on larger data structures, which consist of several separate data values ​​forming the components of the data structure. For example, the data structure could be a stream of data spanning a considerable one-dimensional range, such as a data block to be compressed. Alternatively, the data structure could be a two-dimensional or multi-dimensional matrix or table, to which the processing operations would be applied as a whole.

[0064] like Figure 2As shown, an example of this data structure is a matrix (a two-dimensional matrix in this example). Matrix processing can be used in certain processing algorithms, such as some signal processing applications or machine learning applications. For example, machine learning models (such as neural networks) can be defined using matrices, which indicate weights that define the characteristics of the model and can be applied to the input set by multiplying the weights by the inputs. Therefore, neural network-based processing and other machine learning applications may include a large number of matrix multiplication operations. Although a hardware accelerator 6 can be provided to perform such matrix multiplications, interaction with the hardware accelerator may require the CPU 4 to write data to certain memory locations to configure the hardware accelerator and then read the results back from the hardware accelerator using readings from memory. This can degrade performance if there are applications where matrix multiplication operations need to be interspersed with other operations performed on the CPU itself. Furthermore, using a hardware accelerator for matrix operations can cause difficulties in the system where multiple CPUs 4 or software threads need to share access to the hardware accelerator 6. Therefore, it may be desirable to provide support for instructions within CPU 4 that can perform the processing of matrices or other data structures (as part of the native instruction set supported by instruction decoder 12) instead of requiring the use of hardware accelerator 6.

[0065] Figure 2An example of a local storage structure 30 for storing such a matrix is ​​shown. For example, local storage structure 30 may be some register 16 within the CPU or may be provided as a microarchitecture storage component, such as a non-architecture-authorized register or cache within CPU 4. Furthermore, local storage structure 30 may be within interconnect 10. Local storage structure 30 may have sufficient capacity to store a matrix of a given size. In this example, the matrix is ​​an N×N square matrix, where N is 16, but it will be understood that other sizes of matrices may also be supported. Local storage structure 30 may have sufficient read and write ports, making it possible to read the matrix from the storage structure with a sequence of data components different from the sequence in which data components are written to local storage structure 30. For example, the matrix may be read as columns or rows. This explains the fact that matrices can be stored in memory in different formats, where columns occupy contiguous blocks of memory addresses and a column follows the address of the previous column, with components within the same row at non-contiguous addresses in the address space (this approach can be called column-dominated addressing), or components within the same row can be stored in contiguous blocks of memory addresses, with a row following the address of the previous row, and in this case, components within a column can be at non-contiguous addresses within the portion allocated to each row (this approach is called row-dominated addressing). Since different software algorithms can use different approaches within row-dominated and column-dominated approaches, providing hardware support for either approach can be useful. By providing additional read ports, allowing matrix components to be read row by row or column by column at a time, dynamic matrix transformations are permitted, enabling matrices stored in column-dominated memory to be read in row-dominated or inverse form. This significantly improves compatibility with different types of software and avoids the need to execute additional instructions to reorganize vector components to convert column-dominated matrices to row-dominated or inverse form.

[0066] like Figure 3 As shown in the example, the data structure storage circuit system 31 may have sufficient storage space to hold a dry matrix or portions (tiles) of a matrix. In the following description, the term "tile" is used to refer to an N×N portion of a matrix stored in memory. Of course, if the matrix in memory to be processed has a dimension of N×N, then a tile may actually correspond to the entire matrix.

[0067] Data structure storage circuit system 31 may include Figure 2 Several instances of the local storage structure 30 are shown. For example, such as... Figure 3 As shown, the data structure storage circuit system 31 can have sufficient capacity to store 8 N×N tiles at a time. The provided 8 sets of storage areas can be divided into 4 areas A0, A1, B0, B1 for storing input tiles for matrix multiplication or other arithmetic operations, and 4 areas C0 to C3 for storing output tiles for matrix multiplication operations.

[0068] While another approach could provide only three tile storage areas (local storage structure 30) (e.g., for storing input tiles A0, B0, and output tile C0), allowing a single matrix multiplication to be performed at once, this approach would require at least two loads of tiles from memory for each matrix multiplication operation because the inputs to each matrix multiplication must share the same two input tile registers. In contrast, by providing at least eight tile storage areas in the local data structure storage circuitry system 31 (local storage structure 30), this means that the four loads from memory for loading input tiles A0, A1, B0, and B1 can be amortized across four matrix multiplication operations, as sharing input tiles across multiple multiplication operations is common (e.g., C0 = A0 * B0, C1 = A0 * B1, C2 = A1 * B0, C3 = A1 * B1), and this approach can increase performance by reducing the load ratio to the desired factor. Because it can load relatively large amounts of data, loading tiles can be relatively time-consuming, making this significant for performance. For example, if each data component of a tile is a 32-bit value and N=16, then each tile can correspond to 1 kilobyte of data.

[0069] Although the same approach of providing local storage structure 30 for handling more than one multiplication operation can be extended to a larger number of multiplications, by providing additional storage capacity in the data structure storage circuit system 31 for input and output tiles, a balance can be struck between the increased performance and the additional burden on the storage circuit system for the increased number of matrices within the CPU 4, and therefore... Figure 3 The approach shown, with eight input and output matrices, represents a better balance between performance and area cost. Nevertheless, different numbers of tiles can be stored in the data structure storage circuit system 31 if needed.

[0070] Figure 3 Each of the tile storage areas shown (this end storage structure 30) can store a representation as shown in the image. Figure 4The data of tile 40 within the larger matrix 50 is shown. The overall larger matrix 50 to be processed can be larger than the size of N x N tiles 40 supported by instructions in CPU 4. Therefore, matrix multiplication performed on the larger matrix 50 may need to be broken down into independent instructions executed on the individual tiles 40 of the matrix. Therefore, several address identification parameters can be defined to identify the location in memory where a given tile 40 of the larger matrix 50 resides. The data components of the larger matrix 50 can be stored in contiguous blocks of memory address space, and in this example, the matrix is ​​row-dominated, such that the first row of the matrix is ​​stored at memory addresses in a contiguous block, where the top-left component of the matrix is ​​at the lowest memory address and subsequent components of the next row are stored at progressively increasing memory addresses. When the end of the first row is reached, the next address thereafter corresponds to the data component of the leftmost component of the second row of the matrix, and so on, such that as the sequence of memory addresses of the matrix increases, this corresponds to the component read in a contiguous row. Of course, the matrix can also be column-dominated, in which case the sequence continues column by column rather than row by row.

[0071] Therefore, to identify individual tiles 40 of the matrix, several parameters can be defined, including a base address 42 pointing to the start address of the tile, and a stride parameter 44 that effectively indicates the size of a row or column of the larger matrix 50 and represents the difference between the start address of a row (or column) of tile 40 and the next row (or column) in the matrix. Furthermore, horizontal and vertical size information 46, 48 can be defined to indicate the horizontal and vertical extent of tile 40. Typically, tiles can generally occupy the maximum allowed size (e.g., N x N) to utilize full processor capacity. However, in… Figure 4 In the example shown in the lower right corner, once a tile approaches the boundary of the larger matrix 50, the tile may partially overlap the edge of the larger matrix 50, and it may not be desirable to process the portion 49 located outside the larger matrix 50. Therefore, the horizontal and vertical size parameters 46 and 48 can be used to limit the portion of data loaded into the tile storage area (local storage structure 30) of the CPU 4 (or limit the portion processed in the matrix processing instructions). For example, the horizontal and vertical sizes can be encoded as row or column counts, or encoded as a mask, which is a bit map where bit 1 indicates a valid component of the matrix and bit 0 indicates an invalid component, or vice versa.

[0072] Figure 5An example of a subset of register 16 within CPU 4 is shown. It will be understood that this does not show all registers available. Register 16 comprises a set of general-purpose registers (GPRs) 60, which are used for general storage of operands and for the results of instructions processed by the processing circuitry system 14. A number of general-purpose registers may be available, for example, 32 or 64. For example, integer arithmetic instructions may reference the general-purpose registers of their operands and write their results back to the general-purpose registers.

[0073] The CPU may also have a data structure storage circuit system 31 that provides a storage area (local storage structure 30), such a storage area being used to store data such as... Figure 3 Several input and output data structures A0 to C3 are included. For example, this data structure can be a set of architecture-recognized registers, a set of non-architecture-recognized registers, or a portion of cache 18 stored in the circuit system 31.

[0074] CPU register 16 also includes several registers that provide information about data structures in data structure storage circuitry 31. Each data structure can be associated with a data structure identifier; for example, indicators A0, A1, B0, B1, and C0 through C3 can correspond to the respective data structure identifiers (it will be understood that the A, B, and C annotations are provided here for comprehension, to distinguish the first / second input and output identifiers respectively, and these annotations may be implicit in the identifiers rather than explicitly encoded). Therefore, registers may include a set of data structure metadata registers 62, which are designated to store metadata indicating an address that can be used to identify the address where the corresponding data structure is stored in memory. The data structure metadata registers 62 may be a dedicated set of registers separate from GPR 60, or they may be... Figure 5 The dashed diagram in the figure represents a specified subset of the GPR. These alternative options will be discussed below regarding... Figure 8 and Figure 9 A more detailed discussion follows.

[0075] The data structure metadata register 62 can be divided into multiple register sets, each corresponding to a data structure (tile). For a given set of registers, this can include a single register or two or more registers. In one example, the metadata set for a given data structure record may include the data structure metadata set described above. Figure 4The parameters discussed are 42, 44, 46, and 48. Alternatively, the data structure metadata can be recorded in another way, such as by identifying the set of GPR 60 that stores these parameters (in the specific implementation where the data structure metadata register 62 is separate from the GPR 60) or by identifying the program counter address of the instruction that specifies the register that stores these parameters. It will be understood that different sets of address parameters can be provided as metadata for data structure types other than matrices.

[0076] Depending on the circumstances, register 16 may also include additional registers that provide information about the data structure, such as a data structure availability register 64. This data structure availability register indicates whether, for a given data structure identifier, the corresponding data structure is available in the data structure storage circuitry system 31 or needs to be loaded from memory. Additionally, the register may include a data structure dirty indicator register 66, which indicates whether, for a given data structure identifier, the corresponding data structure stored in the data structure storage circuitry system 31 is clean (consistent with the corresponding data structure stored in memory) or dirty (different from the underlying data structure stored in memory). These additional registers 64 and 66 are optional, and in some cases, they are not provided separately from the data structure metadata register 62; the information in registers 64 and 66 may instead be encoded within the relevant set of the metadata register itself.

[0077] To help speed up context saving operations, providing features at the architecture level that enable software to determine whether a given data structure identifier corresponds to a clean or dirty data structure can be useful. For example... Figure 6 As shown, one way to make the dirty indicator register 66 of data structures unnecessary in some cases is to define the input data structures A0, A1, B0, B1 with identifiers from a separate input data structure identifier space 70, compared to the output data structure identifier space 72 used for output data structures C0 to C3. For example, one set of identifiers 70 can be used for the input data structures, and another set of identifiers 72 can be used for the output data structures. Figure 6 In the example, the "A" and "B" inputs to the matrix multiplication operation can be defined in separate input data structure identifier spaces 70-A and 70-B, which can help reduce the number of tile read / write ports required in the hardware. However, another approach is to assign all input data structures using identifiers within a common input data structure identifier space.

[0078] Therefore, when defining identifiers from separate identifier spaces, it means that corresponding data structures in the corresponding identifier spaces cannot share the same identifier (or be implied from other aspects of instruction encoding, such as for fields containing identifiers that are referencing the identifier in the corresponding identifier spaces 70-A, 70-B). By separating the identifier spaces for input and output data structures, it means that it can be assumed that any input data structure identifier is associated with a clean data structure, since it is impossible to write an output data structure with updated values ​​from the input data structure identifier space 70 to the area associated with the input data structure identifier. This can be used for software or circuit components that perform context saving, because it can then be guaranteed that all data structures associated with the input data structure identifiers in the input data structure identifier space 70 will always be clean, and therefore it means that the corresponding data structures in the data structure storage circuit system 31 will simply be copies of the same data in memory, and therefore do not need to be saved back to memory during context switching. Alternatively, storing only the data structure metadata register 62, which provides information about the location of the relevant data in memory, may be sufficient, as this may be adequate for the software to reload the relevant data structure from memory when context recovery is required to continue processing.

[0079] Depending on the situation, such as Figure 6 The dashed diagram in the image shows a dirty register 66, one or more data structures that store dirty indicators. These dirty indicators show whether the data structure associated with the corresponding output data structure identifier is clean or dirty. This allows the context saver to decide whether to save any clean output data structures to memory, further accelerating context saving.

[0080] Figure 7 A first example of a processing instruction sequence is shown, which includes data structure processing instructions 80 for performing processing operations at the granularity of the overall data structure. In this example, the data structure is a matrix tile as discussed above, and the data processing instructions 80 are matrix multiplication and accumulation instructions. These instructions specify an output data structure identifier Ci and two input data structures Aj and Bk, and control the processing circuitry system 14 to produce the result Ci' = Ci + Aj * Bk. In this example, i can be any value between 0 and 3, and j and k can be 0 or 1 (given the amount of storage area provided for the data structure storage circuitry system 31 as discussed above), but in other examples, the identifier can have a larger value (if necessary) if additional storage is available. In this example, the A, B, and C indicators are implicit, as such indicators can be assumed by the position of the operand identifiers within the instruction encoding.

[0081] exist Figure 7In the example, the data structure metadata register 62 is a fixed subset of the general-purpose register 60. For each input data structure identifier, a corresponding subset of GPR 60 is assigned as the metadata register 62 representing that data structure identifier. For example, registers X0 through X3 may represent the set of metadata registers for input data structure A0, and similarly, registers X4 through X7, X8 through X11, and X12 through X15 may provide metadata for input data structures A1, B0, and B1 (it will be understood that using four registers to provide metadata is one example—other examples may compress the metadata into fewer registers). Each set of metadata registers 62 may include one or more registers and may provide information that allows the software to determine the set of addresses corresponding to the corresponding data structure, such as the base address 42, stride 44, and horizontal and vertical size parameters 46 and 48 as discussed above. Providing metadata registers corresponding to the output data structure is not necessary, although it is permissible.

[0082] like Figure 7 As shown, the instruction decoder 12 can support a data structure load instruction 82, which specifies an input data structure identifier and controls the processing circuitry 14 to load the data structure from an address set associated with the specified input data structure identifier into the region of the data structure storage circuitry 31, derived from a corresponding fixed subset of the GPR associated with the specified input data structure register. For example, for Figure 7 For the first load instruction shown, the input data structure identifier is A0, and therefore may implicitly imply that the address information used to identify the address of the corresponding data structure in memory should be obtained from a fixed subset of GPRs X0 to X3, which are designated to store the address information for the input data structure A0. The instruction sequence may include if load instructions load the corresponding input data structures A0, A1, B0, B1 with information based on the corresponding subset of GPRs. Depending on the situation, if the previous value of the output data structure used for accumulation operations has not yet been stored in the data structure storage circuit system 31, further loads may be available for loading the output data structure. If there is no metadata register for a permanent assignment of the output data structure, these output data structure load instructions may need to explicitly reference a general-purpose register that defines the address information for the corresponding data structure. Alternatively, such load instructions for the output data structure may not be necessary, as it can be simply assumed that the contents of one of the output data structures C0 to C3 in the data structure storage circuit system 31 always contain the relevant value, and subsequently, by initializing the output data structure to 0, subsequent instructions can simply accumulate into the output data structure. Therefore, loads C0 to C3 are selectable.

[0083] Once any of the requested inputs has been loaded, a series of matrix multiply and accumulate (MMLA) operations are then loaded to compute the corresponding outputs C0 through C3. Note that since the four inputs A0 through B1 are shared across the four multiply-accumulate operations, there is one load for each multiply-accumulate operation in this example. The corresponding load and multiply-accumulate instructions 82, 80 can be repeated multiple times, interspersed with general-purpose register moves or arithmetic or load instructions that update the relevant set of metadata registers x0 through x15 to change the address parameters for pointing to other tiles of the overall larger matrix 50. Alternatively, matrix load instruction 82 can be defined such that, in addition to loading the data structure from memory at the current address pointed to by metadata register 62, the processing circuitry implicitly updates the metadata register to point to the next tile, for example, by incrementing the base address. In some examples, matrix multiplication can be modified based on the corresponding set of address metadata, for example, by masking invalid components indicated by the horizontal / vertical size information 46, 48. Finally, once there are no more matrix multiplications and accumulation operations to be performed, the result of the last set of matrix multiplication instructions 80 can be stored back into memory using data structure storage instructions 84. Such data structure storage instructions can use general-purpose registers to identify the addresses of the data structures that should be stored in a format similar to the metadata indicated in the metadata register.

[0084] Although processing of a given data structure continues, using a subset of general-purpose register 60 as metadata register 62, which defines the address metadata for that data structure, means that software is required to avoid writing other values ​​to that subset of general-purpose register 60 while still needing the data structure. This ensures that if an interrupt occurs and processing switches to a different execution context, the address used to indicate the metadata of the given data structure stored in data structure storage circuitry 31 will still exist and can be saved to memory as part of the context save of general-purpose register 60, and this means that saving the corresponding data structure itself, which reduces context switching latency, is unnecessary.

[0085] Figure 8 It shows the relationship with Figure 7 Examples of code sequences similar to those in [the previous example], but here the data structure metadata register 62, which provides the corresponding set of metadata indicating the address of the data structure, is separated from the general-purpose register 60. Data structure processing instructions 80 and storage instructions 84 may have [the following characteristics]... Figure 7 It has the same function as in the middle.

[0086] However, for load instruction 82, since there are no implicitly identified general-purpose registers providing address information at this time, the load instruction may include a set of explicit references 86 to general-purpose registers that provide corresponding segments 42, 44, 46, 48 of address information. These load instructions 82 can then trigger instruction decoder 12 to control processing circuitry 14 to load data structures from memory from the address set identified via information in the specified general-purpose registers, and store the loaded data structures in the relevant area of ​​data structure storage circuitry 31 associated with the input data structure identifiers A0-B1 specified by load instruction 82. In addition to loading data structures, the load instruction may also trigger processing circuitry to write metadata indicating the address to a relevant set of one or more data structure metadata registers 62 for the specified input data structure identifiers. The metadata indicating the address can take several forms. It can simply be a value from an accessed set of general-purpose registers that explicitly encode the base address 42, stride 44, and horizontal and vertical sizes 46, 48 as discussed above. Alternatively, the metadata can be used for… Figure 8 In the example, the register delimiters for the first load, such as Xa to Xd, identify registers containing address information. If this approach is used, the software will need to ensure that these registers continue to hold address information and are not updated between the execution of load instructions and final instructions that depend on data structures within the data structure memory. However, compared to... Figure 7 Compared to the previous example, this approach offers additional flexibility by allowing changes to the address information specified by certain general-purpose registers. Alternatively, again assuming that the contents of registers Xa through Xd, etc., remain unchanged while the data structure is still needed, the metadata indicating the address could be an indication of the program counter address 88, which indicates the address of the relevant load instruction itself. In the example where address information 42, 44, 46, and 48 are written into the data structure metadata register 62, there is no need to restrict any subsequent updates at the source register 86 used to specify that information, and in this case, software can change the contents of GPR 60 used to define address information 42-48 because the corresponding information is retained in the data structure metadata register 62.

[0087] in addition, Figure 8 Examples are similar to Figure 7 Furthermore, by recording and tracing again, the location of the metadata indicating the address or the information directly indicating the metadata of the address can be found, so that the software during context restoration can determine the location of the corresponding data structure in memory. This means that it is not necessary to save a clean data structure as part of the context saving algorithm.

[0088] therefore, Figure 9This is a flowchart illustrating a method for controlling context saving. This can be performed by a context saving circuitry 20 provided in the hardware within CPU 4, or by software via an operating system, supermanager, or other monitoring process. The state saving method is performed in response to a state saving triggering event (e.g., a hardware or software-triggered exception or interrupt). At step 100, context state saving includes saving the general context of the ongoing thread to a data structure in memory. For example, the general context may include a program counter indicating an instruction address (which represents the current execution point), the contents of general-purpose register 60, and any other processor state that needs to be preserved, which may not be directly related to processing the data structures described above. Saving this state can be performed within the address space of a monitoring process, for example, within the address space of an operating system or supermanager, on data structures maintained by that monitoring process. For example, a stack data structure can be used to store a block of state saved for a given thread.

[0089] In step 102, for any clean data structure in the data structure storage circuit system 31, the state save stores the corresponding set of metadata registers 62, but not the data structure itself stored in the data structure storage circuit system 31. These clean data structures can include any input data structure, and, where appropriate, any output data structure, to which the dirty indicator 66 indicates that the output data structure is clean. Note that in the case where the data structure metadata register 60 is a subset of GPR 60, step 102 may already be implicitly performed as part of step 100 when GPR 60 is saved to memory. However, in the example where the data structure metadata register 62 is separate from GPR 60, step 102 can be performed.

[0090] In step 104, for any dirty data structure or data structure whose cleanness or dirtiness is unknown, the data structure itself and the corresponding set of metadata register 62 can be saved.

[0091] Therefore, by ensuring the existence of some metadata register 62 that continues to store address information (the address information about the location of the data structure obtained from memory), this allows step 104 to save the entire data structure only to the dirty structure, and does not need to save the clean data structure, since such a clean data structure is only a copy of the data in memory.

[0092] Figure 10Another example that can be used is shown. In this example, if the input or output value is not yet available in the data structure storage circuitry 31, the data structure processing instruction 800 can also trigger the loading of any input or output data structures required by that instruction, in addition to performing the data structure processing operation itself. This means that the load instruction 82 described above can be replaced by the prepare-to-load instruction 120 and the prepare-to-store instruction 122, which do not need to load the corresponding data structure from memory, but can instead be used to assign a set of address information to the specified data structure identifiers A0-C3. These instructions 120, 122 can specify a set of general-purpose registers 124, which define address information 42 to 48 of the type discussed above, and these instructions can cause the instruction decoder 12 to control the processing circuitry 14 to write the address information into the set of metadata registers 62 associated with the specified data structure identifiers A0-C3. The prepare-to-load instruction 120 can be used to assign address information to input data structure identifiers A0, A1, B0, and B1, and the prepare-to-store instruction 122 can assign address information to output data structure identifiers C0-C3. Depending on the situation, if the data structure is not yet available, the prepare-to-load instruction can also preload the data structure into the data structure storage circuit system 31, but this may not be a feature required by the architecture.

[0093] Therefore, when data structure processing instruction 80 is reached, the processing circuitry can check the availability of any input, for example, based on the availability information in the data structure availability register 64, and load any input required by the instruction that is not yet available in the data structure storage circuitry 31. Furthermore, the processing circuitry performs relevant data processing operations on the input data structure to produce the output data structure.

[0094] By defining the MMLA instruction 80 in the instruction set architecture to also require loading input, it is impractical to use context recovery functionality to recover certain data structures, because the data processing operation 80 itself would load any unavailable data structures if needed. Therefore, if, for example, in generating... Figure 10In the example where an interrupt occurs after the first data structure processing instruction 80 output by C0, and a context switch to leave the current thread is performed, at this point, any dirty data structure C0 can be saved to memory, along with the metadata previously copied to the address indicating the metadata register 62 as part of the state save. However, saving any clean data structures A0 to A1, B0 to B1, or C1 to C3 is unnecessary. When returning to the thread subsequently, a context restore is performed, and once the metadata register 62 has been restored, it is unnecessary to restore any other data structures to the register because each subsequent data structure processing instruction 80 will be loaded into its input (if not already performed) as processing continues. This improves safety because it means that the data structures remain within the thread's address space, which the thread uses, rather than necessarily needing to use them within the overridden process's address space. Furthermore, it means that a context restore is not required for any data structures, which are subsequently not needed for any instructions executed after the thread (which, after the context restore) continues.

[0095] Although not architecturally required, the prepare-to-load instruction 120 may, as needed, preload its corresponding data structure into the data structure storage circuitry 31 (if not yet in progress). This can help improve performance by initiating the loading of these structures earlier than if the hardware waits for the corresponding data structure processing instruction 80 before initiating the loading. Therefore, the availability register 64 can be used to track whether an interrupt exists between the prepare-to-load instruction 120 and the corresponding data processing instruction, allowing the hardware to determine whether it is necessary to reload any data structure when the data structure processing instruction 80 arrives.

[0096] Figure 11 This is a flowchart illustrating the context state restoration process, which can be performed, for example, by an operating system or supermanager in software responsible for managing the context restoration of the underlying threads used for processing. In step 150, the software restores the general context of the input thread, such as the program counter and general-purpose registers. If this has not already been done as part of the general-purpose register restoration, then in step 152, the context restoration process restores the data structure metadata register 62 so that subsequent instructions can subsequently identify the memory location from which to load the data structure. In step 154, the software does not need to restore any data structures themselves, because these data structures can be loaded as needed by subsequent data structure processing instructions 80.

[0097] Although the examples discussed above relate to matrices and the data structure processing operations described are matrix multiplication, it will become clear that similar techniques for reducing the additional burden of context saving and restoration can be applied to other data structure types.

[0098] Figure 12Specific implementations of emulators that can be used are indicated. While the previously described embodiments pertain to devices and methods for operating specific processing hardware supporting the relevant technologies, the embodiments described herein may also provide an instruction execution environment implemented using a computer program. Because such a computer program provides a software-based implementation of a hardware architecture, it is often referred to as an emulator. Variations of emulator computer programs include imitators, virtual machines, models, and binary converters, including dynamic binary converters. Typically, an emulator implementation may run on a main data processing device 730, and, where appropriate, on a main operating system 720, thereby supporting the emulator program 710. In some arrangements, there may be multiple layers of emulation between the hardware and the provided instruction execution environment and / or between multiple different instruction execution environments provided on the same main processor. Historically, there has been a need for efficient processors to provide emulator implementations that execute at a reasonable speed, but this approach may be reasonable in certain circumstances, such as when it is desired to run code native to another processor for compatibility, or for reuse reasons. For example, an emulator implementation may provide an instruction execution environment with additional functionality not supported by the main processor hardware, or provide an instruction execution environment typically associated with a different hardware architecture. An overview of the simulation is given in “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0099] If a particular hardware construct or feature has been previously described in a simulated implementation, the equivalent functionality can be provided by an appropriate software construct or feature. For example, a particular circuit system may be implemented as computer program logic in a simulated implementation. Similarly, memory hardware (such as registers or caches) may be implemented as software data structures in a simulated implementation. One or more hardware components referenced in the previously described implementations are present in an arrangement on the main hardware (e.g., main data processing device 730), and some simulated implementations may utilize the main hardware where appropriate.

[0100] The emulator program 710 can be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (instruction execution environment) to the target code 700 (which may include applications, operating systems, and super managers). This program interface is identical to the application programming interface of the hardware architecture modeled by the emulator program 710. Therefore, the program instructions of the target code 700 (including data structure processing instructions as described above) can be executed from within the instruction execution environment using the emulator program 710, enabling the main data processing device 730, which does not actually possess the hardware features of device 2 discussed above, to emulate these features.

[0101] The emulator program 710 may include instruction decoder logic 712 that decodes the instructions of the target code 700 and maps such instructions to equivalent functionality defined using native instructions supported by the main data processing device 730. For example, the instruction decoder logic 712 may include if / then / else statements that examine the encoded bits of the target instructions in the target code 700 and, depending on the bits found in a particular instruction, select a sequence of instructions defined in the native instruction set to emulate the architectural functionality of the target instructions.

[0102] Furthermore, the emulator program 710 may include register emulation program logic 714, which manages storage structures defined in the memory of the main data processing device 730 that emulate the architecture registers required by the instruction set architecture associated with the target code 700. For example, register read / write operations identified using register references in target instructions of the target code 700 may be mapped to memory access instructions for reading / writing data in the memory of the main data processing device 730. Registers emulated using the register emulation program logic 714 may include the data structure metadata register 62 discussed above.

[0103] In this patent application, the phrase "configured as..." is used to mean that the components of the device are configured to perform the defined operations. In this context, "configuration" means the arrangement or manner of interconnection of hardware or software. For example, the device may have dedicated hardware that provides the defined operations, or a processor or other processing device may be programmed to perform that function. "Configured as" does not imply that the device components need to be changed in any way to provide the defined operations.

[0104] Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it should be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be made therein by those skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. A data processing device, comprising: An instruction decoder, used to decode instructions; as well as A processing circuit system is configured to perform data processing in response to an instruction decoded by the instruction decoder; wherein: In response to a data structure processing instruction specifying at least one input data structure identifier and an output data structure identifier, the instruction decoder is configured to control the processing circuit system to perform a processing operation on at least one input data structure identified by the at least one input data structure identifier to produce an output data structure identified by the output data structure identifier. The at least one input data structure and the output data structure each include a data arrangement corresponding to multiple memory addresses; The device includes multiple sets of one or more data structure metadata registers, each set of the one or more data structure metadata registers being associated with a corresponding data structure identifier and designated to store metadata indicating an address, the metadata identifying the multiple memory addresses of the data structure identified by the corresponding data structure identifier, and The processing circuitry is configured to operate according to an instruction set architecture that enables the software to identify, for at least a subset of data structure identifiers, whether a data structure corresponding to one of the data structure identifiers in the subset is clean or dirty.

2. The device according to claim 1, wherein the output data structure identifier is defined in an identifier space separate from the at least one input data structure identifier.

3. The device according to any one of claims 1 and 2, comprising at least one architecture register for storing at least one dirty indicator, each dirty indicator indicating whether a data structure corresponding to a given data structure identifier is clean or dirty.

4. The device according to any one of claims 1 and 2, comprising a context saving circuitry system that saves a predetermined subset of processor states to memory in response to a context saving trigger event, wherein the predetermined subset of processor states includes the set of one or more data structure metadata registers corresponding to at least one data structure identifier, the at least one data structure identifier corresponding to a clean data structure but excluding the data structure corresponding to the at least one data structure identifier.

5. The device according to any one of claims 1 and 2, wherein the data structure metadata register associated with a given data structure identifier comprises one of the following: A fixed subset of multiple general-purpose registers, which are also accessible in response to non-data structure processing instructions supported by the instruction decoder and the processing circuitry system; and A dedicated set of data structure metadata registers, separate from the plurality of general-purpose registers.

6. The device according to any one of claims 1 and 2, wherein, in response to the data structure processing instruction, the processing circuitry is configured to generate a load request for loading the previous value of a given input data structure or a given output data structure from memory when a previous value of a given input data structure or a given output data structure is not available to the processing circuitry.

7. The apparatus of claim 6, wherein the processing circuitry includes a checking circuitry for checking whether the given input data structure is available in a data structure storage circuitry separate from the memory.

8. The device of claim 1, comprising a data structure storage circuitry system separate from memory; and In response to the data structure processing instruction, the instruction decoder is configured to control the processing circuit system to read the at least one input data structure from the data structure storage circuit system and to write or update the output data structure to the data structure storage circuit system.

9. The apparatus of claim 8, wherein when a given data structure is stored in the data structure storage circuit system, the processing circuit system is capable of reading data from the given data structure in a sequence different from the sequence in which the data is written into the data structure storage circuit system.

10. The device according to any one of claims 8 and 9, wherein the data structure storage circuit system comprises at least one of the following: Architecture addressable registers; Non-architectural addressable registers; A high-speed temporary storage memory; and A high-speed cache.

11. The apparatus according to any one of claims 8 and 9, wherein in response to a data structure load instruction specifying a target input data structure identifier or a target output data structure identifier, the instruction decoder is configured to control the processing circuitry to write a data structure loaded from a memory address derived from the metadata of the indicated address stored in the set of one or more data structure metadata registers into the data structure storage circuitry, the one or more data structure metadata registers corresponding to the target input data structure identifier or the target output data structure identifier.

12. The device according to any one of claims 8 and 9, wherein, in response to a data structure load instruction specifying a target input data structure identifier or a target output data structure identifier and one or more general-purpose registers, the instruction decoder is configured to control the processing circuitry system: A data structure loaded from the memory address derived from the target address identification information stored in the one or more general-purpose registers is written into the data structure storage circuit system, and The set of one or more data structure metadata registers corresponding to the target input data structure identifier or the target output data structure identifier is updated based on the target address identification information or a property of the data structure loading instruction.

13. The apparatus according to any one of claims 1 and 2, wherein in response to a prepare-load instruction specifying a target input data structure identifier, the instruction decoder is configured to control the processing circuitry system to update the set of one or more data structure metadata registers corresponding to the target input data structure identifier based on one of the following: The target address identification information implicitly or explicitly specified by the preparation loading instruction; and One property of the preparation loading instruction.

14. The device of claim 13, wherein in response to the prepare-to-load instruction, the processing circuitry is configured to generate a load request for requesting that a data structure associated with the target input data structure identifier be transferred from a memory address determined based on the target address identification information to the data structure storage circuitry.

15. The apparatus according to any one of claims 1 and 2, wherein in response to a prepare-to-store instruction specifying a target output data structure identifier, the instruction decoder is configured to control the processing circuitry system to update the set of one or more data structure metadata registers corresponding to the target output data structure identifier based on one of the following: The target address identification information implicitly or explicitly specified by the preparation storage instruction; and One property of the preparation to store instructions.

16. The device according to any one of claims 1 and 2, wherein the plurality of memory addresses comprises a plurality of non-contiguous blocks of memory addresses.

17. The device of claim 16, wherein the metadata indicating the address includes at least one of the following: Start address information, indicating the starting address of at least one of the plurality of non-contiguous blocks of memory address; Offset information, indicating a separation between the start addresses of the plurality of non-contiguous blocks of memory address; The first size information indicates the size of each non-contiguous block of memory address; The second size information indicates the number of non-contiguous blocks of memory addresses that form the data structure; Component size information, indicating the size of a data component in the data structure; One or more register identifiers identify one or more general-purpose registers storing at least one of the start address information, the offset information, the first size information, and the second size information; and An instruction address indicates an address of an instruction specification register that stores at least one of the start address information, the offset information, the first size information, and the second size information.

18. The apparatus according to any one of claims 1 and 2, wherein the data structure processing instructions include a matrix multiplication instruction specifying two input data structure identifiers, and the processing operation includes a matrix multiplication operation performed on two input data structures identified by the two input data structure identifiers to produce the output data structure.

19. The device according to any one of claims 1 and 2, wherein the output data structure has a size of at least 64 bytes.

20. The apparatus of any one of claims 1 and 2, wherein, in response to the data structure processing instruction, the processing circuitry is configured to rewrite the processing operation performed on the at least one input data structure based on metadata of the indicated address stored in at least one set of one or more data structure metadata registers corresponding to the at least one input data structure identifier or the output data structure identifier.

21. A data processing method, comprising: In response to a data structure processing instruction that defines at least one input data structure identifier and an output data structure identifier, a control processing circuit system performs a processing operation on at least one input data structure identified by the at least one input data structure identifier to produce an output data structure identified by the output data structure identifier, wherein each of the at least one input data structure and the output data structure includes a data arrangement corresponding to a plurality of memory addresses; as well as The metadata indicating the address is stored in multiple sets of one or more data structure metadata registers, each set of the one or more data structure metadata registers being associated with a corresponding data structure identifier, wherein... Each set of one or more data structure metadata registers is designated to store metadata indicating addresses, the metadata identifying the plurality of memory addresses of the data structure identified by the corresponding data structure identifier, and The processing circuitry is configured to operate according to an instruction set architecture that enables the software to identify, for at least a subset of data structure identifiers, whether a data structure corresponding to one of the data structure identifiers in the subset is clean or dirty.

22. A non-transitory storage medium for storing a computer program, said computer program being used to control a master data processing device to simulate the execution of a target program by a target data processing device; The computer program includes: Instruction decoding program logic for decoding instructions of the target program, wherein in response to a data structure processing instruction specifying at least one input data structure identifier and an output data structure identifier, the instruction decoding program logic is configured to control the main data processing device to perform a processing operation on at least one input data structure identified by the at least one input data structure identifier to produce an output data structure identified by the output data structure identifier, wherein the at least one input data structure and the output data structure each include a data arrangement corresponding to a plurality of memory addresses; as well as Register emulation program logic is used to control access to a storage structure to emulate the registers of the target data processing device, wherein the registers include multiple sets of one or more data structure metadata registers, and each set of the one or more data structure metadata registers is associated with a corresponding data structure identifier. Each set of one or more data structure metadata registers is designated to store metadata indicating addresses, the metadata identifying the plurality of memory addresses of the data structure identified by the corresponding data structure identifier, and The instruction decoding program logic is configured to operate according to an instruction set architecture that enables the software to identify, for at least a subset of data structure identifiers, whether a data structure corresponding to one of the data structure identifiers in the subset is clean or dirty.

Citation Information

Patent Citations

  • Managing and implementing metadata in central processing unit using register extensions

    US20110078389A1

  • Systems, methods, and apparatuses utilizing CPU storage with a memory reference

    US20190042448A1