Widing vector load instructions

Abstract

A broadening vector load instruction specifies at least one address operand and two or more vector destination registers each to specify a vector operand having a given vector length. In response to decoding the broadened vector load instruction, at least one microoperation is issued to control the processing circuitry 16, 56: load at least one vector of data elements from a location in the memory system 30, 32, 34 corresponding to a target memory address determined based on the at least one address operand; broadening data elements of the loaded at least one vector from a first data element size to a second data element size greater than the first data element size; and writing the broadened data element having the second data element size to two or more vector destination registers as a respective vector operand having a given vector length.

Description

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

[0002] The processing circuitry can support a vector processing architecture, where vector instructions can trigger vector operations to be performed on vector operands comprising multiple data elements. Compared to using separate scalar instructions to process each data element independently as a scalar implementation, using vector instructions to perform vector operations reduces the instruction fetching and decoding overhead for a given operation to be performed on each data element in a set of data elements.

[0003] At least some examples provide an apparatus comprising: an instruction decoding circuit for decoding an instruction; and a release circuit for releasing at least one micro-operation in response to the decoding of a given instruction by the instruction decoding circuit to control a processing circuit to perform a processing operation corresponding to the given instruction; wherein: in response to decoding a widened vector load instruction specifying at least one address operand and a plurality of vector destination registers, each specifying a vector operand having a given vector length, the instruction decoding circuit is configured to control the release circuit to release at least one micro-operation to control the processing circuit to: load at least one vector of data elements from a location in a memory system corresponding to a target memory address determined based on at least one address operand; widen the data elements of the loaded at least one vector from a first data element size to a second data element size greater than the first data element size; and write the widened data elements having the second data element size to the plurality of vector destination registers as a plurality of corresponding vector operands.

[0004] At least some examples provide computer-readable code for manufacturing an apparatus comprising: an instruction decoding circuit for decoding an instruction; and a release circuit for releasing at least one micro-operation in response to the decoding of a given instruction by the instruction decoding circuit to control a processing circuit to perform a processing operation corresponding to the given instruction; wherein: in response to decoding a widened vector load instruction specifying at least one address operand and a plurality of vector destination registers, each specifying a vector operand having a given vector length, the instruction decoding circuit is configured to control the release circuit to release at least one micro-operation to control the processing circuit to: load at least one vector of data elements from a memory system at a location corresponding to a target memory address determined based on at least one address operand, the at least one vector of data elements having a total size greater than or equal to a given vector length; widen the data elements of the loaded at least one vector from a first data element size to a second data element size greater than the first data element size; and write the widened data elements having the second data element size to the plurality of vector destination registers as a plurality of corresponding vector operands, each having a given vector length.

[0005] At least some examples provide a method comprising: decoding an instruction; and, in response to decoding a given instruction, issuing at least one micro-operation to control processing circuitry to perform a processing operation corresponding to the given instruction; wherein: in response to decoding a widened vector load instruction specifying at least one address operand and a plurality of vector destination registers, each specifying a vector operand having a given vector length, the at least one micro-operation is issued to control the processing circuitry to: load at least one vector of data elements from a location in a memory system corresponding to a target memory address determined based on at least one address operand, the at least one vector of data elements having a total size greater than or equal to a given vector length; widen the data elements of the loaded at least one vector from a first data element size to a second data element size greater than the first data element size; and write the widened data elements having the second data element size to the plurality of vector destination registers as a plurality of corresponding vector operands, each having a given vector length.

[0006] At least some examples provide a computer program for controlling a host data processing device to provide an instruction execution environment for executing target program code. The computer program includes: instruction decoding program logic for decoding instructions of the target program code; and processing program logic for performing a processing operation corresponding to a given instruction decoded by the instruction decoding program logic; wherein: in response to decoding a widened vector load instruction specifying at least one address operand and a plurality of vector destination registers, each specifying a vector operand having a given vector length, the instruction decoding program logic is configured to control the processing program logic to: load at least one vector of data elements from a location in a simulated address space corresponding to a target memory address determined based on at least one address operand, the at least one vector of data elements having a total size greater than or equal to a given vector length; widen the data elements of the loaded at least one vector from a first data element size to a second data element size greater than the first data element size; and write the widened data elements having the second data element size to host memory circuitry corresponding to the plurality of vector destination registers as a plurality of corresponding vector operands, each having a given vector length.

[0007] At least some examples provide a storage medium that stores the computer-readable code or computer program mentioned above. The storage medium can be a non-transitory storage medium.

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

[0009] Figure 1 An example of a processing system for support vector processing is shown;

[0010] Figure 2 An example of a vector register with a vector length indicated by a vector length parameter is shown;

[0011] Figure 3 A first example of an instruction decoding circuit and a issuing circuit is illustrated, in which the instruction decoding circuit and the issuing circuit are located within a processor such as a central processing unit (CPU);

[0012] Figure 4 An example is shown of using a coprocessor to handle an offloaded subset of operations from an operation flow to be executed by the main processor;

[0013] Figure 5 The functionality of the deinterleaved variant of the widened vector loading instruction is illustrated;

[0014] Figure 6 The functionality of the non-deinterleaved variant of the widened vector load instruction is illustrated;

[0015] Figure 7 The data processing methods are illustrated;

[0016] Figure 8 This illustrates a method for handling widened vector loading instructions;

[0017] Figure 9 An example is given of a method for handling deinterleaving variants of the widened vector loading instruction;

[0018] Figure 10 An example is given of a method for handling non-deinterleaved variants of the widened vector load instruction; and

[0019] Figure 11 A simulation example is shown.

[0020] An apparatus includes: an instruction decoding circuit for decoding instructions; and a issuing circuit for issuing at least one micro-operation in response to the decoding of a given instruction by the instruction decoding circuit to control processing circuitry to perform a processing operation corresponding to the given instruction. Designing an instruction set supported by the instruction decoding circuitry can be a relatively complex task because there may be a limited encoding space available compared to the theoretically wide range of operations that can be supported, and therefore a justification must be provided for supporting a particular instruction. Design choices and trade-offs made regarding which operations to support and how to encode those instructions can affect the performance and power consumption of the processing circuitry. Other factors to consider include the practicality of implementing the circuitry that executes the instructions and the flexibility offered by the architectural instructions to support different microarchitectural design choices for the specific implementation of the circuitry. Therefore, just because a given operation is theoretically possible does not automatically mean that its inclusion as a particular instruction will be desirable. Instruction set architects are generally extremely cautious about adding new instructions to the instruction set because once an instruction is included, it is extremely difficult to remove it, as continued support will be required to allow legacy software using the instruction to continue operating. If the introduction of instructions proves problematic in hardware implementation or results in insufficient coding space to represent a more preferable operation, the negative consequences of adding to the instruction set will be felt over time. Therefore, caution is advised when considering adding to the instruction set.

[0021] In the example below, the instruction decoding circuitry supports a widened vector load instruction that specifies at least one address operand and multiple vector destination registers, each specifying a vector operand with a given vector length. In response to decoding the widened vector load instruction, the instruction decoding circuitry controls the issuing circuitry to issue at least one micro-operation to control the processing circuitry: • Load at least one vector of data elements from the memory system at a location corresponding to a target memory address determined based on at least one address operand; • Widen the data elements of at least one loaded vector from a first data element size to a second data element size larger than the first data element size; and • Write widened data elements with a second data element size to multiple vector destination registers as multiple corresponding vector operands.

[0022] Therefore, the widened vector load instruction enables the loading of a vector of data elements and the widening to the size of a second data element to be performed in response to a single instruction, and can also fill more than one destination register of a given vector length with widened data elements from at least one loaded vector.

[0023] This instruction can be helpful for workloads that process data elements stored in memory in a format that is compressed compared to the format in which the data elements undergo processing operations at the processing circuitry. For example, expanding to a second data element size can be used to maintain higher accuracy during intermediate steps of subsequent vector processing operations performed on the loaded, widened data elements, while a denser storage format can sacrifice accuracy to reduce the memory overhead for a given number of data elements. An example of a workload type where this is useful is image processing workloads, where it is very common for pixel data to be stored in memory in smaller data element sizes so that expanding to a wider data element size is required when loading data to apply image processing kernels such as filtering, resizing, or rotation.

[0024] Vector processing architectures can be attractive for this type of workload because they can apply repetitive operations to multiple data elements in response to a single instruction. However, the inventors have recognized that existing vector instruction sets may be inefficient for handling this type of workload.

[0025] The widened vector load instruction described in this application is more efficient than its alternatives because, since both the load and widening operations are performed in response to a single architecture instruction and the destination register of the load instruction is written with the widened data element, there is no need to consume additional architecture registers (represented by one of a finite set of architecture register identifiers that can be encoded in the instruction code) to hold one or more temporary non-widened load vectors between the load and widening operations. (In contrast, such architecture registers would be consumed if the load and widening instructions were executed as separate architecture instructions, where the widening instruction is a register-to-register instruction rather than a memory-to-register instruction.) Therefore, the widened vector load instruction can help reduce register pressure, which tends to improve performance because the code is less likely to exhaust spare architecture registers, thus reducing the need to overflow register data into memory when register data might already be held in the register file corresponding to the architecture vector register.

[0026] Furthermore, providing a single instruction to represent the architectural intent for both the load and widen operations allows for more flexible microarchitectural designs in the processing circuitry. For example, this instruction allows for the flexibility of a load-permutation-write-back pipeline that directly passes the load result to the permutation unit to rearrange the loaded data elements for widening, without requiring intermediate register file writes / reads between the load and permutation operations. In contrast, if the load and widen operations were implemented as separate instructions that did not express the architectural intent for the widen operation to follow the load, intermediate register writes / reads would typically be required.

[0027] Furthermore, by providing instructions that can fill two or more destination vector registers with widened data elements based on narrower data elements loaded from memory, this preserves the memory throughput (the number of memory-based data elements processed per load instruction) achieved by the equivalent non-widened vector load instruction for data operating in memory. In contrast, an alternative widened load instruction that writes widened data elements to a single vector destination register of a given vector length would have reduced memory throughput compared to the equivalent non-widened vector load instruction. By maintaining memory throughput, this avoids the need to increase the number of vector load instructions per vectorized loop iteration to maintain a given level of memory throughput per loop iteration. Performing a large number of load instructions per amount of memory data processed incurs significant costs in terms of memory control bandwidth (e.g., increased number of memory translation lookups, consumed load / memory slots, etc., which could limit bandwidth available for other operations and thus performance). By using the widened vector load instruction described above, this cost can be reduced for a given amount of memory throughput.

[0028] Therefore, widened vector load instructions that write to multiple destination vector registers can provide several advantages for supporting workloads that require data elements to be processed in a larger size than their storage format in memory, and thus the additional coding space consumed by providing this type of instruction in the instruction set is justifiable.

[0029] Widening vector load instructions can be mapped by instruction decoding circuitry to one or more micro-operations, where the specific number of micro-operations depends on the actual implementation implemented by the particular microarchitecture. For example, some examples can support a single combined micro-operation capable of controlling the processing circuitry to perform both load and widening operations. This can be helpful for microarchitectures that support combined load / permutation pipelines as a single functional unit. Other examples can map widening vector load instructions to separate micro-operations: one or more load micro-operations (e.g., which themselves can be broken down into address calculation micro-operations and memory access micro-operations) and one or more permutation micro-operations to perform the widening operation. This splitting micro-operation approach works better for implementations with load / memory units and permutation units as separate functional units. Using the splitting micro-operation approach, temporary physical registers can be used to hold the vector of the loaded data element as an intermediate result before the permutation unit applies the widening to the vector of the loaded data element; however, this does not increase the register pressure as discussed above because the temporary physical registers are not mapped to any architecture registers and therefore do not affect the speed at which the software runs out of architecture registers for different variables.

[0030] Therefore, it will be understood that there are a wide range of ways to support widened vector loading instructions at the microarchitecture level. These instructions provide flexibility for a wide variety of design choices in this regard.

[0031] A widened vector load instruction specifies two or more vector destination registers. In the encoding of a widened vector load instruction, the vector destination registers can be explicitly identified by two or more destination register fields. Alternatively, the instruction can explicitly identify a first destination register among the two or more destination registers in the register field of the instruction encoding, and one or more other destination registers among the two or more vector destination registers can be implicitly identified as vector destination registers whose schema register identifier is at a predetermined offset relative to the schema register identifier of the first destination register. For example, the two or more vector destination registers can be registers associated with a set of consecutive schema register identifiers starting from the schema register identifier of the first destination register explicitly encoded in the instruction encoding. Using this method, software developers or compilers are constrained to select registers with consecutive schema register identifiers as destinations for widened vector load instructions; however, this constraint has the advantage of reducing the amount of encoding space required to encode multiple destination registers, which can be useful since instruction encoding space may be scarce.

[0032] Regardless of the specific method used to encode the vector source registers in the instruction, each vector source register, explicitly or implicitly identified by the instruction, is associated with a different schema register identifier and can therefore be individually designated as a source register or destination register by another instruction in the instruction set supported by the instruction decoding circuitry. That is, where a given vector instruction specifies a source / destination vector register field for identifying the corresponding vector register used as a source / destination operand, each vector source register of a narrow vector store instruction can have a different encoded schema register identifier associated with the source / destination register field of the given vector instruction. Therefore, each source register of a narrow vector store instruction can be independently designated as an operand for vector operations or a destination to be updated based on the result of the vector operations. Subsequent instructions following a wide vector load instruction do not necessarily process each destination of the vector load instruction collectively—each destination register of the wide vector load instruction can process independently.

[0033] Widened vector load instructions allow at least one vector of data elements to be loaded to have a total size greater than or equal to the given vector length. Each instance of a widened vector load instruction does not necessarily load an amount of data larger than or equal to the given vector length, because for some assertion cases, the assertion operand of the widened vector load instruction may have already selected a valid portion of data smaller than the given vector length. However, the maximum amount of data that can be loaded via a widened vector load instruction can be greater than or equal to the given vector length. This helps conserve memory throughput compared to the equivalent non-widened vector load instruction.

[0034] Some examples can support deinterleaving variants of the widened vector loading instruction. In response to the deinterleaving variant, the instruction decoding circuitry controls the issuing circuitry to issue at least one micro-operation to control the processing circuitry to deinterleave two or more interleaved channels of data elements obtained from at least one vector, such that each vector destination register specifies one or more widened data elements corresponding to different channels in the interleaved channels. The deinterleaving variant can be used to support workloads that operate on storage structures comprising multiple interleaved channels of data elements, such as pixel data of an image represented in RGB (red, green, blue) or RGBA (red, green, blue, alpha) format, but require the processing kernel to be applied to a separate channel of data extracted from the stored multi-channel structure. By combining the widening and deinterleaving operations into a single instruction, this provides circuit designers with the flexibility to implement more efficient use of a permutation unit that can perform both operations in a single action. Alternatively, other implementations can implement the widening and deinterleaving steps as separate steps that can occur in any order (widening first then deinterleaving, or deinterleaving first then widening).

[0035] The deinterleaving mode used to write widened data elements to multiple vector destination registers can be implicitly defined by encoding a deinterleaving variant of the widened vector load instruction. Therefore, it is not necessary for the deinterleaving variant of the widened vector load instruction to specify an index operand that explicitly identifies the index value at each corresponding element location in the destination register. For example, an implicitly defined deinterleaving mode could be one in which consecutively loaded data elements from at least one loaded vector are alternately assigned to the corresponding vector destination registers in a cyclic manner (e.g., if data stored in RGB or RGBA format as stored data RGB(A)RGB(A)RGB(A)... is deinterleaved, then "R" elements are assigned to one vector destination register, "G" elements are assigned to another, and so on). Therefore, the deinterleaving variant of the widened vector load instruction can be architecturally constrained to control the processing circuitry to execute a specific implicitly defined deinterleaving mode and cannot support any arbitrary general permutation where any single data element from the loaded vector can be arbitrarily permuted to any location within the vector destination register. Using implicitly defined deinterlacing modes can be advantageous because the index vectors used to control general permutations can make it difficult to write vector-length-agnostic software according to a scalable vector architecture (discussed further below). This is because the index values ​​used for the index vectors would need to be pre-computed in the software for a specific vector length, and the limited range of each index value available for the index vectors could constrain the maximum vector length that the general permutation operations controlled by the index vectors can support. These problems can be avoided by providing interlaced variants of widened vector loading instructions that use implicitly defined interlacing modes, and scalable vectorized software becomes available for handling workloads that operate on narrower data elements stored in memory as packed interlaced data structures that require expansion when loaded for processing.

[0036] A deinterleaved variant of the widened vector load instruction can specify at least one assertion value that specifies element assertion information indicating which data elements of at least one vector are masked data elements, with corresponding portions of multiple vector destination registers used to specify values ​​unrelated to the masked data element. For example, for a portion of the vector destination register that will otherwise be written with a widened data element corresponding to a given masked data element without an assertion being applied, the value unrelated to the masked data element could be zero or a previous value associated with that portion of the vector destination register. Assertion information can be represented in different ways. Some examples specify an assertion mask comprising multiple bit fields as at least one assertion value, each bit field indicating whether the corresponding set of one or more elements is masked or unmasked. Alternatively, an assertion counter can be used to indicate the total number of unmasked data elements (which can be implicitly considered to start from the first data element of the at least one vector loaded and stored at the target memory address itself). In other words, the assertion counter can indicate the boundary between the initial set of unmasked data elements and the subsequent set of masked data elements. Regardless of the specific way assertion values ​​represent masking data elements, by supporting assertions, this enables software to prevent load operations used for widened vector load instructions from overflowing into subsequent regions of memory beyond the end of the data structure being processed, even if the data structure being processed has a total number of data elements that does not correspond to an exact multiple of the number of elements that can be processed using a single instance of the widened vector load instruction.

[0037] For the deinterleaved variant of the widened vector load instruction, element assertion information can be specified at the granularity of element groups by at least one assertion value, where each element group includes one data element from each of the multiple interleaved channels. For example, all elements within the same element group can have their assertions controlled by the same mask bit of the assertion mask, which is specified as at least one assertion value. Alternatively, in the case of an assertion counter, a monotonically increasing value of the assertion counter causes consecutive element groups to be selected as active (e.g., a count value of 3 causes another element group (containing multiple data elements) to be selected as active, while a count value of 2 would mask the other element group). Therefore, for the deinterleaved variant, the encoding of the instruction constrains the assertions to either mask all data elements in the same element group or not mask any data elements in the same element group, making it impossible to partially mask some elements in an element group without masking other elements in the same element group. Applying assertions at the granularity of element groups can be particularly useful for interleaved variants, because often, if multiple channels of interleaved data need to be deinterleaved, each channel of a given element group will either need to be processed or not, and therefore the benefit of supporting partial assertions is minimal. Restricting assertions to the granularity of element groups also simplifies microarchitectural implementation, because when deinterleaving the elements of a single element group to multiple vector destination registers, common assertion control can be applied to the corresponding element location in each vector destination register.

[0038] Some examples can support non-deinterleaved variants of widened vector load instructions (which can be supported as an alternative to or supplement to deinterleaved variants). In response to a non-deinterleaved variant of a widened vector load instruction, the instruction decoding circuitry can control the issuing circuitry to issue at least one micro-operation to control the processing circuitry to write a set of widened data elements corresponding to locations loaded from contiguous memory address blocks in a given vector destination register across multiple vector destination registers. Non-deinterleaved variants can be used to support workloads where either the memory structure in memory does not pack multiple channels in an interleaved manner, or when the memory structure includes interleaved channels of data, the processing kernel applied to that memory structure requires the common processing of elements from a single multi-channel group of elements to make it possible to locate these elements at adjacent locations within the vector destination registers. However, both deinterleaved and non-deinterleaved variants can provide the instruction set design advantages discussed above.

[0039] The non-deinterleaved variant of the widened vector load instruction can specify at least one assertion value that specifies element assertion information indicating which data elements of at least one vector are masked data elements. For each masked data element, a corresponding portion of a plurality of vector destination registers is used to specify a value independent of that masked data element. Therefore, similar to the deinterleaved variant, assertion options are supported to allow software-based adjustment of the amount of data to be processed by a given instance of the instruction. For example, this can be used to ensure that load operations do not overflow beyond memory page boundaries into subsequent regions that are not currently allowed to be accessed by the software (avoiding performance penalty by handling associated page faults).

[0040] However, unlike the deinterlaced variant, for the non-deinterlaced variant, it can be useful to specify element assertion information at the granularity of individual data elements of at least one vector, rather than at the granularity of groups of elements. Therefore, the non-deinterlaced variant offers greater architectural flexibility in specifying which elements are masked, which can be useful for supporting the application of the non-deinterlaced variant of widened vector load instructions to data structures that do not include packed interlaced channels (although the non-deinterlaced variant can also be applied to such packed structures, the architectural flexibility given by individual element-level assertions can support a wider range of use cases for the non-deinterlaced variant).

[0041] A non-deinterleaved variant of the widened vector load instruction can specify at least one assertion register, each specifying an assertion value that specifies element assertion information used to control assertions in two or more vector destination registers among a plurality of vector destination registers. This takes advantage of the fact that when the loaded data elements are widened to a larger data element size, the number of widened elements per vector destination register is reduced compared to the equivalent non-widened load instruction, and therefore some spare assertion codes that would not be used if an assertion register were provided for each vector destination could exist in a single assertion register. For example, in assertion values ​​of multiple bit fields or ranges of a counter designed to support a counter sufficient to dispose of the maximum possible number of data elements within a vector register, some bit fields of the assertion mask or some count values ​​used for the assertion counter can be spared. Thus, when using the widened instruction, a single assertion register can control assertions in multiple vector registers. For example, for an assertion mask, a first part of the assertion mask can control assertions in a first assertion register, and a second part of the assertion mask can control assertions in a second assertion register. If the assertion value is implemented as a counter value that specifies the location of the boundary between masked and unmasked data elements, the maximum range used for the counter can span across two or more widened data elements in the vector destination registers. In either case, using a single assertion register to control assertions in multiple vector destination registers allows the number of assertion registers encoded in the instruction code to be less than the number of vector destination registers, thus saving encoding space in the instruction code.

[0042] The number of vector destination registers specified by the widened vector load instruction can vary. Some examples may support a two-register variant of the widened vector load instruction. Other examples may support three-register and / or four-register versions of the instruction, or may support additional vector destination registers. A deinterleaved variant with two vector destination registers can be used to handle the deinterleaving of the real and imaginary parts of complex numbers stored in memory in an interleaved manner. A deinterleaved variant with three vector destination registers can be used to support operations on packed image data in RGB format. A deinterleaved variant with four vector destination registers can be used to support operations on packed image data in RGBA format. On the other hand, regardless of whether the variant is deinterleaved or non-deinterleaved, supporting more than two vector destination registers can help increase memory throughput, thereby allowing fewer vectorized loop iterations to be processed for a given amount of data. In cases where more than one variant of the instruction supports different numbers of vector destination registers, the corresponding variant of the instruction can be distinguished by its instruction opcode or by another field in the instruction that identifies the number of vector destination registers.

[0043] In some examples, widening vector load instructions can allow at least one vector of data elements to have a total size greater than or equal to twice the length of a given vector. For instance, this can be useful for implementations that utilize a 2x widening operation to load and deinterleave packed RGBA data into four vector destination registers, such that the result is that the data values ​​of two vectors (i.e., data of twice the length of a given vector) are loaded and widened into four vector operands. Memory throughput can be increased by enabling data of more than one vector length to be loaded in a single instruction.

[0044] Some specific implementations may support a fixed definition of the size of the first data element and the size of the second data element (e.g., a fixed ratio between the size of the first data element and the size of the second data element, such as the second data element being two or four times the size of the first data element).

[0045] However, in some examples, at least one of the first and second data element sizes is variable, depending on at least one control parameter associated with the widened vector load instruction. For example, this control parameter may include one or more of the following: the instruction's opcode, a field encoded by the instruction to specify element size information, and / or a parameter stored in a control register to specify element size information. For example, variations of the instruction corresponding to different settings of the control parameter can be provided to support two-fold and / or four-fold widening operations and to operate on elements of different sizes in memory. For example, variations can be provided for first and second data element sizes of 8 bits and 16 bits, 8 bits and 32 bits, and / or 16 bits and 32 bits, respectively.

[0046] In some implementations, the length of a given vector can be implicitly defined as a fixed value in the instruction set architecture. In other examples, the length of a given vector can be variable, depending on the parameters associated with the widened vector loading instruction.

[0047] However, it can be useful for a device to include a vector length storage circuit to store a vector length parameter indicating a given vector length. This can help support vector length-agnostic software written according to a scalable vector instruction set architecture, where the given vector length used to execute widened vector loading instructions is unknown at compile time, allowing the same software to execute on different processing platforms (implementing vector lengths different from the given vector length), but instructions such as loop control instructions can be adapted to the implemented vector length based on the given vector length read from the vector length storage circuit.

[0048] In some examples, the apparatus including instruction decoding circuitry and issuing circuitry may also include processing circuitry controlled by the issuing circuitry to perform operations corresponding to the widened vector loading instruction.

[0049] However, in other examples, for at least a subset of instruction types, the issuing circuitry can issue at least one micro-operation corresponding to a widened vector load instruction to off-chip processing circuitry on a separate integrated circuit. Therefore, the processing circuitry that performs the operation in response to the widened vector load instruction does not necessarily have to be part of the same apparatus as the instruction decoding circuitry and issuing circuitry that decodes the widened vector load instruction and issues one or more corresponding micro-operations. For example, the off-chip processing circuitry can include a coprocessor to which the main processor, including the instruction decoding circuitry and issuing circuitry, can offload the operation, wherein the coprocessor can be implemented on a chiplet separate from the instruction decoding / issuing circuitry logic of the main processor.

[0050] In some examples, the device may include a coprocessor configured to perform processing operations on a subset of instruction types offloaded from the main processor, and the coprocessor may include instruction decoding circuitry and dispatch circuitry for decoding instructions of said subset of instruction types. The coprocessor may reside on the same chip as the main processor or on a different chip. For each subset of instruction types offloaded to the coprocessor, the coprocessor may have its own internal instruction decoding and dispatch circuitry, and therefore the techniques discussed above can also be implemented within the coprocessor.

[0051] Therefore, there are various use cases where instruction decoding circuits and release circuits that can support widened vector loading instructions exist.

[0052] The techniques discussed above can be implemented within a device with hardware circuitry provided for implementing instruction decoding circuitry, issuing circuitry (and, if provided in the same device, processing circuitry), as discussed above. However, the same techniques can also be implemented within a computer program that executes on a host data processing device to provide an instruction execution environment for executing object code. Such a computer program can control the host data processing device to simulate the architectural environment provided on the hardware device, which actually supports object code according to a given instruction set architecture, even if the host data processing device itself does not support that architecture.

[0053] A computer program may have instruction decoding logic and processing logic. The instruction decoding logic emulates the function of the instruction decoding circuitry discussed above, and the processing logic executes a processing operation corresponding to a given instruction decoded by the instruction decoding logic. For example, the instruction decoding logic may include if / if statements for controlling the selection of a corresponding code sequence (part of the processing logic) written in the native instruction set of the host data processing device in response to a given instruction of the target code, wherein execution of the code sequence will control the host data processing device to perform an operation corresponding to the decoded instruction. The instruction decoding logic and processing logic support widened vector load instructions as discussed above, which cause the corresponding load / widening operation (with optional deinterleaving) to be executed by the processing logic. However, the register and memory address spaces expected to be provided in the instruction set architecture of the target program code may not actually be provided in the host device. Therefore, such register and memory address spaces can be simulated by mapping them to the host's storage device circuitry (e.g., the registers and memory of the host device). Therefore, in the simulation implementation, the load target address represents an address in the simulation address space (which may be different from the address space of the host memory used to access the host data processing device), and the vector destination register can be simulated using the corresponding area of ​​the host storage device circuitry, rather than being mapped to any specific hardware register file.

[0054] For example, such computer simulation programs can be useful when executing legacy code written for one instruction set architecture on a host processor that supports different instruction set architectures. Additionally, simulation can allow software development for a newer version of the instruction set architecture to begin before the processing hardware supporting the new architecture is ready, because executing the software on a simulated execution environment allows software testing to be performed in parallel with ongoing development of the hardware device supporting the new architecture. The simulation program can be stored on a storage medium, which can be a non-transitory storage medium.

[0055] Figure 1An example of a data processing apparatus 2 is illustrated schematically. The data processing apparatus has a processing pipeline 4 comprising multiple pipeline stages. In this example, the pipeline stages include: a fetch stage 6 for fetching instructions from an instruction cache 8; a decode stage 10 (an example of an instruction decoding circuit) for decoding the fetched program instructions to generate micro-operations (decoded instructions) to be processed by the remaining stages of the pipeline; a release stage 12 (an example of a release circuit) for checking whether the operands required for the micro-operation are available in register 14, and for releasing the micro-operation for execution once the operands required for a given micro-operation are available; an execution stage 16 (an example of a processing circuit) for performing a data processing operation corresponding to the micro-operation by processing the operands read from register 14 to generate a result value; and a write-back stage 18 for writing the result of the processing back to register 14. It will be understood that this is merely one example of a possible pipeline arrangement, and other systems may have additional stages or different stage configurations. For example, in an out-of-order processor, a register renaming stage may be included to map the architecture registers specified by program instructions or micro-operations to physical register specifiers in the identifier register 14. In some examples, a one-to-one relationship may exist between program instructions decoded by the decoding stage 10 and corresponding micro-operations processed by the execution stage. It is also possible that a one-to-many or many-to-one relationship exists between program instructions and micro-operations, such that, for example, a single program instruction can be split into two or more micro-operations, or two or more program instructions can be merged to be processed as a single micro-operation.

[0056] Execution phase 16 includes multiple processing units for performing different types of processing operations. For example, the execution units may include a scalar processing unit 20 (e.g., a scalar arithmetic / logic unit (ALU) 20 for performing arithmetic or logical operations on scalar operands read from register 14); a vector processing unit 22 for performing vector operations on vectors comprising multiple vector elements; and a load / store unit 28 for performing load / store operations to access data in memory systems 8, 30, 32, and 34. Other examples of processing units that may be provided at the execution phase may include a floating-point unit for performing operations involving values ​​represented in floating-point format, or a branch unit for processing branch instructions.

[0057] Register 14 includes a scalar register 25 for storing scalar values, a vector register 26 for storing vector values, and an assertion register 27 for storing assertion values. Assertion value 27 can be used by vector processing unit 22 when processing vector instructions, wherein a given assertion value in the assertion register indicates which vector elements of the corresponding vector operand stored in vector register 26 are active (unmasked) vector elements or inactive (masked) vector elements (wherein the operation corresponding to inactive data elements can be suppressed or may not affect the resulting value generated by vector processing unit 22 in response to a vector instruction).

[0058] The Memory Management Unit (MMU) 36 controls the address translation between virtual addresses (specified by instruction fetching from fetch circuit 6 or load / store requests from load / store unit 28) and physical addresses identifying locations in the memory system, based on address mappings defined in a page table structure stored in the memory system. The page table structure can also define memory attributes that specify access permissions for corresponding pages in the address space, such as whether a region of the address space is read-only or read / write, which permission levels are allowed to access the region, and / or other properties that control how the corresponding region of the address space can be accessed. Entries from the page table structure can be cached in a Translation Lookahead (TLB) 38, a cache maintained by the MMU 36, to cache page table entries or other information to accelerate access to page table entries from the page table structure shown in the memory.

[0059] In this example, the memory system includes a tier-one data cache 30, a tier-one instruction cache 8, a shared tier-two cache 32, and main system memory 34. It will be understood that this is merely one example of a possible memory hierarchy, and other cache arrangements may be provided. The specific type of processing units 20 to 28 shown in execution phase 16 is only one example, and other specific implementations may have different sets of processing units or may include multiple instances of the same type of processing units, allowing multiple micro-operations of the same type to be processed in parallel. It will be understood that... Figure 1 This is merely a simplified representation of some components of a possible processor pipeline layout, and the processor may include many other elements not shown for the sake of simplicity.

[0060] Figure 2 An example is shown of the architecture register set that can be referenced by instructions encoded according to the instruction set architecture (ISA) supported by the processing system 2. Figure 2The physical register file provided in the hardware used to implement these architecture registers is not shown; only which registers are logically available for reference by instructions are shown. The specific mapping from the architecture registers logically referenced by instructions to the physical storage device within the physical register file 14 can be implemented in many different ways (e.g., using a one-to-one mapping between architecture registers and physical registers in an ordered processor or a variable mapping between architecture registers and physical registers controlled by register renaming in an out-of-order processor).

[0061] In this example, ISA supports: • General-purpose register group 25, which includes general-purpose scalar registers for specifying scalar operands for scalar processing operations; • Vector register group 26, which includes vector registers for specifying vector operands for vector processing operations, matrix operations, or other SIMD operations; • Assertion register set 27, which includes assertion registers for specifying assertion values ​​used for assertion vectors, matrices, or other SIMD operations; and • A set of control registers 40 is used to store control values ​​for controlling the operation of the processing device 2. The information stored in the control registers can be automatically set in response to certain events, or can be programmable based on the execution of system register update instructions.

[0062] In this example, the ISA supported by processing device 2 is a scalable vector ISA (also known as a "vector length-agnostic" vector ISA) that supports operations on vectors of scalable vector lengths so that the same instruction sequence can be executed on devices with hardware that supports different maximum vector lengths. This allows different hardware designers implementing the processor to choose different maximum vector lengths based on their design priorities, such as high performance or reduced circuit area and power consumption, without requiring software developers to tailor their software to a specific hardware platform. Software written according to a scalable vector ISA can execute across any hardware platform that supports a scalable vector ISA, regardless of the specific maximum vector length supported by a particular hardware platform. Therefore, the vector length (and thus the assertion length of the corresponding assertion register 27) used for access by a specific vector instruction of the scalable vector ISA is unknown at compile time (neither defined as fixed in the ISA itself nor specified by parameters in the software itself). The operations performed in response to a given vector instruction of a scalable vector ISA can vary depending on the vector length chosen for a particular hardware implementation (e.g., hardware supporting a larger maximum vector length can process more vector elements for a given vector instruction compared to hardware supporting a smaller maximum vector length). Therefore, an implementation with a shorter vector length may require a larger number of loop iterations to implement a particular function compared to an implementation with a longer vector length.

[0063] The vector length agnostic property of scalable vector ISAs is useful because, within a fixed coding space of instructions available for encoding the ISA, it is impractical to create different instructions for every different vector length that processor designers might need, when considering a wide range of requirements scaling from relatively small, energy-efficient microcontrollers to servers and other high-performance computing systems. Since there is no known fixed vector length at compile time, the same ISA can be used to address multiple markets without the effort required by software developers to customize code for each performance / power / area point.

[0064] To achieve the scalable nature of a scalable vector ISA, the functionality of the vector instructions in the scalable vector ISA is referenced in the architecture to parameters indicating the vector length in use (when considering the maximum vector length supported in the hardware and any software-defined limitations using control register 40) (e.g., ...). Figure 2The VL 43 or SVL 42 shown below (described in more detail below) are used to define the vectors, where the parameter VL or SVL is unknown at compile time. Therefore, executing the same vector instruction on different systems can produce different results (typically varying depending on the number of vector elements generated; a subset of these vector elements may have the same result value on different platforms, but generally, platforms implementing larger vector lengths generate additional vector elements compared to platforms implementing smaller vector lengths). The assertion values ​​defined in assertion register 27 can be used to control which elements are generated in a given instance of an instruction and can be set based on the principle of unknown vector length, such as by automatically generating assertion values ​​for a specific loop iteration using comparison instructions or by applying a generally defined assertion pattern that can scale to different vector lengths. Some instructions can update loop control parameters (such as element count values) to track how many vector elements have been processed so far, such that implementations with wider and narrower vector lengths can ultimately achieve the same result but with different performance levels over all iterations of the loop as a whole, because implementations with wider vector lengths require fewer loop iterations than implementations with narrower vector lengths.

[0065] This particular example of the ISA also supports two different modes for performing vector operations: non-streaming operation mode and streaming operation mode. Mode indication status information 41, stored in control register 40, indicates whether the current mode is non-streaming or streaming, and can be set in response to the execution of a mode change instruction. Scalar operations using general-purpose register 25 can be processed in the same way regardless of whether the current mode is non-streaming or streaming, but operations using vector register 26 and assertion register 27 can be processed differently depending on whether the current mode is streaming or non-streaming.

[0066] In non-streaming mode, vector register 26 is architecturally specified to have a vector register length VL identified by the non-streaming vector length specification value 43 specified in control register 40, and assertion register 27 is architecturally specified to have a register length VL / X, where X is a constant corresponding to the minimum supported vector element size (e.g., for a specific implementation where the minimum vector element size is 8 bits, X may be equal to 8). In streaming mode, vector register 26 is architecturally specified to have a streaming mode vector length SVL identified by the streaming vector length specification value 42 specified in control register 40 (streaming vector length specification value 42 is separate from non-streaming vector length specification value 43), and assertion register 27 is architecturally specified to have a register length SVL / X. Therefore, when there is a mode change between streaming and non-streaming modes, both vector register 26 and assertion register 27 can be logically considered as changing their register lengths.

[0067] The non-streaming vector length specification 43 and the streaming mode vector length specification 42 can be implemented in different ways. In some examples, these vector length specifications 43, 42 may simply be fragments of hardwired state information that are not programmable by software, and may only indicate the maximum register length supported by the hardware for each mode. This can then be read by software to identify a specific vector length implemented on the hardware executing the program, allowing the same software to execute on different hardware with different vector lengths.

[0068] In other examples, the ISA may support higher-privileged software capable of limiting the maximum vector length that can be used by software executing in a lower-privileged state. For example, to save power, a given software segment may be limited so that it cannot utilize the full vector length supported in the hardware. Therefore, vector length specifications 43, 42 may include information that can be set by the software to specify the vector length to be used in each mode. However, even if the higher-privileged software imposes a limit on the vector length, the vector length used by the application software remains unknown at compile time because it will not be known whether the actual vector length implemented in a particular processor will be greater than or less than the limit defined in length specifications 43, 42. For a specific implementation with hardware that supports a maximum vector length smaller than the limit defined in length specifications 43, 42, a smaller vector length than indicated by the limit will actually be used. For example, the effective vector length seen by the software may correspond to the minimum of the maximum vector length supported in the hardware for the current mode and the vector length limit set by the software. The vector length specifications 43 and 42 can be grouped by exception level, allowing different limits to the maximum supported vector length to be specified for software executing at different exception levels (e.g., allowing software at one exception level to use a longer vector length than software at another exception level).

[0069] Therefore, the control status information stored in control register 40 can affect the vector length used for vector operations in various ways, but generally, some status information that enables the software to determine the effective vector length for each mode is available. Thus, a given vector length is defined for the vector associated with a given vector instruction to be executed.

[0070] Supporting both non-streaming and streaming modes can be useful because it provides hardware microarchitecture designers with greater flexibility to support, for example, Figure 3 and Figure 4 The different hardware implementations shown are illustrated. Figure 3 In the example, vector instructions are executed by the processing circuitry 16 of the main processor 2, without any operations being offloaded to the coprocessor. On the other hand, in Figure 4In the example, a coprocessor 50 is provided for performing a specific subset of vector operations using vector register 26 and assertion register 27. Coprocessor 50 may include coprocessor decoding circuitry 52 and coprocessor publishing circuitry 54. The coprocessor decoding circuitry decodes instructions published to coprocessor 50 by publishing circuitry 12 of main processor 2. The coprocessor publishing circuitry receives decoded micro-operations from coprocessor decoding circuitry 52 and determines when operands for those instructions will be available, and publishes the micro-operations to coprocessor processing circuitry 56 when operands are available. Coprocessor 50 may have its own register storage 58 separate from register storage 14 and main processor 2. Coprocessor 50 may have access to a shared memory system shared with main processor 2 and therefore may execute vector load / store instructions to load data from memory / store data to memory (e.g., coprocessor 50 may have access to one or more of the main processor's data caches 30, 32 and may also have access to main memory 34). The coprocessor processing circuit 56 refers to operands stored in the coprocessor register storage device 58 and data accessed from the memory system to perform load / store and computation operations represented by instructions unloaded from the main processor 2 to the coprocessor 50.

[0071] The architecturally defined streaming processing modes and the separate vector lengths for the corresponding mode indicator values ​​42, 43 simplify the hardware's determination of when instructions requiring vector registers should be offloaded to the coprocessor 50 or executed within the local execution unit 16 of the main processor 2. It also allows software to explicitly specify whether a particular workload is better suited to be executed on the general-purpose execution unit 16 of the processor 2 or on the more customized hardware of the coprocessor 50. This can be useful because for vector processing routines that require smaller vectors and / or workloads where vector operations are scattered with scalar operations, processing vector operations on the general-purpose execution unit 16 local to the processor 2 itself may be more appropriate, while the coprocessor 50 may be better suited to handle "streaming" workloads that require high throughput of vector operations on large datasets with relatively less need for intermediate scalar operations (e.g., workloads associated with machine learning applications such as neural network processing).

[0072] For such streaming workloads, longer vector lengths can be used to reduce the instruction fetch / decode overhead associated with processing a given number of vector elements. Therefore, although the ISA does not require it (the vector length for non-streaming mode can be chosen from a specific set of supported vector lengths, and the streaming mode vector length can be chosen from a second set of supported vector lengths, where there is no fixed relationship between the lengths chosen for non-streaming and streaming modes), in specific implementations of the coprocessor 50 chosen to support streaming vector modes, it is relatively likely that the streaming mode vector length can be greater than the non-streaming mode vector length, in some cases many times larger. As an example only (other lengths may also be used), an implementation may choose a maximum vector length of 128 bits in non-streaming mode and 512 bits in streaming mode, where the assertion register thus has an architectural vector length of 16 bits in non-streaming mode and 64 bits in streaming mode.

[0073] In use Figure 4 In the example of coprocessor 50 shown, coprocessor 50 may be on the same chip (integrated circuit) as main processor 2, or on a separate chip. For example, main processor 2 and coprocessor 50 may be implemented as separate chiplets on an interposer layer, each chiplet being manufactured as a separate component and then assembled on the interposer layer.

[0074] Therefore, when considering the instruction decoding circuit, the issuing circuit, and the processing circuit for implementing the widened vector loading instructions mentioned in this application, several different specific implementations are possible, including: • First example, in which the instruction decoding circuit 10, the issuing circuit 12, and the processing circuit 16 are all as follows: Figure 3 The setup shown is located within processor 2.

[0075] • In the second example, the instruction decoding circuit 10 and the release circuit 12 are located in the main processor 2, but the processing circuitry executing the widened vector load instruction is (at least in some operating modes such as the streaming mode described above) the coprocessor processing circuitry 56 in the coprocessor 50, which may be either on the same integrated circuit as the main processor 2 or an off-chip processing circuitry 56 on a separate integrated circuit from the main processor 2. In other operating modes (e.g., non-streaming modes), the processing circuitry executing the widened vector load instruction may be the main processor 2's processing circuitry 16 as in the first example.

[0076] •like Figure 4In the third example shown, the responsibility for decoding the widened vector load instruction into one or more micro-operations rests with the coprocessor decoding circuit 52, and therefore the means for handling the widened vector load instruction can be considered the coprocessor 50, which may or may not be on the same chip as the main processor 2. In this case, the instruction decoding circuit, the issuing circuit, and the processing circuit can be the coprocessor decoding circuit 52, the coprocessor issuing circuit 54, and the coprocessor processing circuit 56, respectively.

[0077] Since it is possible that the processing circuitry that actually performs the operation for the widening vector loading instruction can be on a different chip than the instruction decoding circuitry 10, 52 and the issuing circuitry 12, 54 that decode and issue the widening vector loading instruction, the processing circuitry 16, 56 itself does not need to be in the same device as the instruction decoding circuitry 10, 52 and the issuing circuitry 12, 54.

[0078] Although Figure 2 The examples discussed scalable vector ISAs, but the widened vector loading instructions described in this patent application can also be applied to non-scalable vector ISAs for which the vector length is known at compile time (either fixed in the architecture or variable based on software-specified parameters). Furthermore, while scalable vector ISAs supporting separate non-streaming and streaming modes have been described above, widened vector loading instructions can also be provided in scalable vector ISAs that do not support streaming modes, such that mode indication 41 and streaming vector length parameter 42 are not provided, and the given vector length to be used for the vector instructions is defined by VL parameter 43.

[0079] Figure 5 An example of a deinterleaved variant of the widened load instruction is shown. For example... Figure 5 As shown, it is relatively common in image processing workloads to store pixel data as interleaved channels of data elements (e.g., as RGB data (red, green, blue) or RGBA data (red, green, blue, α) per pixel location, where the α channel indicates opacity) in memory. Figure 5 An example with four interleaved channels for RGBA data is shown. Image data including RGB or RGBA data is just one example of a packed interleaved structure, and it will be understood that the widening load instruction can also be used to process other kinds of data structures.

[0080] When processing kernels are to be applied to such packed data structures, it is common practice to load a bundle of data elements (e.g., pixels), deinterleave the channels to form separate operands for each individual channel containing data elements, and pad the data to process it as a wider data type. For example, 8 bits of pixel data stored in memory can be widened to 16 bits per data element to allow for processing with higher precision. However, existing vector architectures can be inefficient when handling this type of operation.

[0081] One approach could be to use non-widened vector load instructions to load packed multichannel data into a first set of vector registers instead of applying any widening at load time, and then execute a separate register-to-register substitution instruction specifying an index vector operand. This instruction controls the substitution unit to rearrange the loaded data elements from the first set of vector registers into another set of vector registers, where each element of the index vector operand corresponds to a portion of the other set of vector registers and specifies which portion of the first set of vector registers should provide the data value to be stored in that other set of vector registers (the index vector operand can specify that zeros should be inserted in some portions of the other set of vector registers to fill the narrower load elements into the wider data element size). However, the problem with this approach is that such generic substitution instructions capable of performing any arbitrary substitution can be expensive to implement in terms of hardware logic and performance costs in manipulating arbitrary register-to-register rearrangements. Furthermore, it is difficult to use generic substitution instructions to write to vector-length-agnostic software because the index values ​​in the index vector operands would need to be pre-computed in software for a specific vector length, so they cannot be gracefully scaled in hardware to vector lengths selected based on VL 43 or SVL 42 as described above. This complicates software development. Another problem is that non-widened vector loading uses the first set of architecture vector registers as destination registers and subsequent permutation instructions use another set of architecture vector registers as destination registers. This increases register pressure because it means that the software will soon run out of spare architecture vector register identifiers available to identify new variables. This can degrade performance due to increased memory operations that may cause variables to overflow into memory that cannot fit within the architecture register space.

[0082] Another problem with some existing methods is that load instructions that support widening data elements from a first data element size to a second (larger) data element size are typically written to a single destination register. This widening results in fewer elements fitting into a single destination register, thus reducing memory throughput (the number of memory-based data elements processed per load instruction) compared to the equivalent non-widened load instruction. To compensate for and maintain equivalent memory throughput, software can execute multiple load instructions per loop iteration. However, this introduces complexity in terms of assertion loading, as multiple distinct loads per loop iteration make writing assertions for a single loop iteration cumbersome. This can lead to pausing once a certain number of elements have been processed, marking the portion of the vector as inactive based on a count of how many elements have been processed so far. Therefore, many software implementations can alternatively choose to implement a main loop that processes a certain number of fully active vector elements, followed by a separate tail loop for cleaning up the remaining tail of elements that cannot occupy the entire vector. Such tail loops degrade performance because they require additional instructions to be executed in addition to the main loop. Additionally, executing multiple load instructions per loop iteration consumes additional memory control bandwidth (e.g., for an implementation supporting coprocessor 50, an increased number of memory translation requests required at MMU 36, increased consumption of load / memory slots within load / memory unit 28, and / or increased turbulence during access to the coprocessor 50's external memory).

[0083] These problems can be addressed by providing a deinterleaved widened vector load instruction as a supported instruction in the instruction set architecture. This deinterleaved widened vector load instruction specifies at least one address operand for defining the target memory address of the load operation and specifies multiple vector destination registers 26. The instruction can also specify assertion information, for example, using an assertion register 27. The function of this instruction is to cause processing circuits 16, 56 to load at least one vector of data elements of a first data element size from the memory location corresponding to the target memory address (subject to assertion that the loaded elements are obtained from a contiguous region of memory starting from the target memory address), widen the data elements to a wider second data element size, and deinterleave multiple channels of the loaded data into separate destination registers, each providing a widened data element for one of the channels.

[0084] Therefore, in Figure 5In the example, the instructions specify four destination vector registers Z1-Z4 and are used to deinterleave four interleaved channels of data elements of a first data element size (e.g., 8 bits) (such as interleaved RGBA data for an image) to provide four corresponding vectors in the four destination registers. Each destination register represents a single channel of data with an extended second data element size (e.g., 16 bits) (e.g., R, G, B, or A respectively). Each destination register has a given vector length VL, SVL currently used for the vector processing operation. Therefore, for the deinterleaving variant, consecutively located elements obtained from memory are striped across the corresponding destination vector registers to deinterleave them into separate channels.

[0085] If assertions are applied, the assertion values ​​control the assertions at the granularity of an array of elements. For example... Figure 5 As shown, each element group comprises a contiguous block of data elements in a memory-based structure, and each element group includes a single data element from each channel in the channel. If a given element group is indicated to be masked by an assertion, the corresponding location in the vector destination register is set to a value independent of the masked data element. For example, in Figure 5 The group of elements starting at element R2 is marked as inactive (in this example, "0" is used in the assertion mask), and therefore the portion of the vector destination register Z1-Z4 corresponding to this group of elements (in... Figure 5 The masking region (marked with a "-") is set independently of the values ​​of those masking elements. For example, the masked region of the destination register can be set to 0 (zero-assertion), or it can retain the previous value of the corresponding part of the destination register (merge assertion). Although Figure 5 An example using a bitmask as the assertion value is shown, but other examples can use an assertion counter that indicates the boundary between the active element and the masked element. For the deinterleaved variant of the instruction, the counter counts at the granularity of group of elements, making it possible to... Figure 5 In the specific example shown, the counter can be specified with a value of 2 to indicate that the first two elements from the target memory address are active and subsequent elements are masked.

[0086] For example, the widened vector load instruction can specify various operands, such as:

[0087] ld4b {z1.h – z4.h}, p0 / z, [x17, x16]

[0088] Of course, the instruction encoding seen by the instruction decoding circuits 10 and 52 will include binary values ​​encoded to represent the corresponding information. Here, ld4b indicates the type of instruction (4-register deinterleaved widened vector load instruction) and may correspond to the opcode encoded in binary encoding. Register identifiers z1-z4 identify four destination vector registers. In some examples, these may all be explicitly identified in the instruction encoding, or alternatively, the instruction may be constrained to select a set of vector registers with adjacent register identifiers as destination registers, and only one of these register identifiers may be explicitly encoded in the instruction encoding, while the others are implicitly located at some offset relative to the encoded register identifiers. The notation .h indicates that the second data element size to be used for widening the data element is a "half-word" size (16 bits) (the opposite of byte size .b (8 bits) or full-word size .w (32 bits)). In this example, implicitly, the first data element size for the data in memory is 8 bits, but other examples may include operands used to identify the size of the first data element. The assertion register identifier p0 identifies the assertion register that provides the assertion value. The suffix / z indicates that the instruction will use a zero-triggered assertion (instead of a merged assertion), but other examples may not support these two options, and therefore the type of assertion can be implicit. Register identifiers x17 and x16 represent address operands used to identify the target memory address (e.g., x17 could identify the base register and x16 could identify the register used to specify the offset to be added to the value stored in the base register to generate the target address). It will be understood that this is just one example of addressing modes and any other addressing mode can be used (e.g., other examples could use an immediate value, a program counter value, and / or a stack pointer value as one of the address operands).

[0089] Therefore, when an instruction is decoded by instruction decoding circuits 10 and 52, the instruction decoding circuits 10 and 52 generate at least one micro-operation, which, when issued by issuing circuits 12 and 54, causes processing circuits 16 and 56 to load data elements from memory, widening them from a first data element size to a second data element size (e.g., by means of...). Figure 5(As shown in the example for element A0, it is padded with 0s), the element is deinterleaved, and the deinterleaved widened element is written to the destination register. The specific micro-operations generated for this instruction can vary depending on the specific implementation, and can therefore include combined micro-operations, for which loading and widening / deinterleaving are handled by a single functional unit comprising both a loading phase and a replacement phase, or can be split into separate micro-operations for the loading / store unit and the replacement unit, respectively. The widening and deinterleaving operations can be performed separately in any order, or can be combined into a single replacement operation (because the replacement used to control deinterleaving can also support injecting 0s at the top of each element of the first data element size to expand the elements to the second data element size). Although Figure 5 An example of widening elements by padding with 0s is shown, but it will be understood that if signed data values ​​are used to process instructions, widening can include sign-expanding the data to increase the width of each data element.

[0090] Although Figure 5 An example of a four-destination register instruction is shown, but it will be understood that other variants can write to a different number of vector source registers (e.g., a three-register variant could be provided to handle RGB interleaved data, or a two-register variant could be provided to handle two interleaved channels).

[0091] Additionally, variants can be provided to support different element sizes for the first and second data element sizes, possibly with different ratios between the second and first data element sizes (e.g., 4x widening instead of 2x widening). The 8-bit to 16-bit widening example shown above is just one example, and other examples can vary the data element size of one or both of the first and second data element sizes based on programmable parameters referenced by the instructions (either in the instruction code itself, in the control register, or a combination of both).

[0092] Using this type of instruction offers several advantages. It supports a more flexible microarchitectural implementation than would be possible in an ISA where loading, widening, and deinterleaving must be broken down into at least two separate architectural instructions. This is because providing a single instruction for loading, widening, and deinterleaving expresses the intention that these operations will be performed as a single operation, enabling the use of a dedicated pipeline that can directly pass the result of the load to the permutation unit without using intermediate temporary registers. By allowing a single load operation to write to multiple vector registers while simultaneously widening, memory throughput is maintained without consuming multiple MMU lookups per loop iteration, and assertions are simplified, reducing the need for tail-loop processing of the remaining elements, and thus improving the performance of the code using the instruction. Furthermore, while this instruction can be used in both non-scalable and scalable vector ISAs, it can be particularly helpful in scalable vector ISAs because the implicitly defined deinterleaving permutation operation avoids the need to specify any index vectors for controlling the permutation, and therefore avoids the need for pre-computation of index values ​​(which would require writing code of a specific non-vector length unknown). Therefore, this type of instruction allows operations to scale to any vector length without requiring platform-specific code.

[0093] Figure 6 A non-deinterleaved variant of the widened vector loading instruction is shown. In this example, it is similar to... Figure 5 The instruction loads the set of data elements from memory and widens it to a second data element size larger than the first data element size used to represent the data elements in the memory-based data structure, but unlike in... Figure 5 Unlike in the memory-based architecture, there is no deinterleaving, so the order of the widened data elements in the destination vector remains the same as in the memory-based architecture. Therefore, the first vector destination register Z1 includes widened data elements corresponding to the first contiguous block of data elements R0 to A1 loaded from memory, the next vector destination register Z2 includes widened data elements corresponding to the second contiguous block of data elements R2 to A3, and so on (subject to assertions, such as...). Figure 6 As shown in the example, this assertion can mask some of these elements as inactive, thereby... Figure 6 The corresponding part marked with "-" is either set to 0 or retained as the previous value of the corresponding part in the destination register. Figure 6 In the example, at the granularity of individual data elements rather than as in Figure 5 Assertions are applied at the same granularity as element groups. Figure 6The example can be useful for processing workloads where, instead of processing individual channels from an interleaved structure, multiple channels of data are processed together, making it useful to keep each group of elements together in the destination register. Additionally, this allows non-deinterleaved variants of instructions to be applied to single-channel data structures that do not include interleaved channels of data.

[0094] Similar to Figure 5 Example, Figure 6 The widened vector load instruction writes to multiple destination registers, thus enabling the retrieval of at least one vector's data value (each vector having a size corresponding to a given vector length VL / SVL) from memory in a single instruction, although widening causes each destination register to accept fewer destination registers. For example, if the given vector length in use is 128 bits, then for the 2-register version of the instruction and a 2x widening ratio, this would mean that the size of the data block loaded from memory when all elements are active is also 128 bits, so that the widened load instruction does not sacrifice any memory throughput compared to a standard non-widened load that writes to a single vector register. Other examples can support more than two destination registers and can have other ratios between the first data element size and the second data element size. Thus, in some examples, multiple vectors of data (each with a given vector length VL, SVL) can be loaded from memory, such that the amount of data loaded can correspond to 2 times or more of the given vector lengths VL, SVL.

[0095] Figure 7 A method for performing data processing is illustrated. At step 100, instruction decoding circuits 10 and 52 decode instructions encoded according to a given instruction set architecture. At step 102, in response to the decoding of the instructions by instruction decoding circuits 10 and 52, issuing circuits 12 and 54 issue at least one micro-operation corresponding to the instruction. At step 104, processing circuits 16 and 56 perform a corresponding processing operation in response to at least one micro-operation.

[0096] Figure 8 The steps performed in step 104 are illustrated for a processing operation executed when the instruction decoded in step 100 is a widened vector load instruction. In step 110, processing circuits 16 and 56 load at least one vector of data elements from a memory location corresponding to a target memory address calculated based on at least one address operand of the widened load instruction. In step 112, processing circuits 16 and 56 widen the loaded data elements from a first data element size to a second data element size larger than the first data element size. In step 114, processing circuits 16 and 56 write the widened data elements to two or more vector destination registers as corresponding vector operands having a given vector length VL, SVL currently in use.

[0097] Figure 9 An example is illustrated of the steps performed for the processing operation executed at step 104 when the instruction decoded at step 100 is a deinterleaved variant of a widened vector load instruction. At step 120, the processing circuitry applies assertions at the element-group granularity based on at least one assertion value of the operand designated as a widened load instruction. For example... Figure 5 The data elements shown are arranged in an interleaved multichannel structure, with each channel of the element group comprising one data element. Based on an assertion, one or more element groups, including masked data elements, are identified. At step 122, the processing circuitry loads at least one vector of data elements having a first data element size from a memory location corresponding to a target memory address calculated from at least one address operand of the instruction. Load requests can be suppressed for portions of the memory range referenced by the instruction corresponding to the masked data elements identified at step 120 to prevent memory faults triggered by accesses across page boundaries to regions not corresponding to the data structure being accessed. Alternatively, regardless of how the assertion generates load requests specifying accesses corresponding to the full vector width, if a page fault is detected for a data element marked as masked by the assertion, fault handling responses for such masked data elements can be suppressed, and any loaded data associated with the masked data can be discarded without writing it to the destination vector register. At step 124, processing circuits 16, 56 deinterleave and widen multiple channels of the data elements within the loaded vector to generate separate, individual channels of widened data elements having a second data element size. The deinterleaving and widening operations can be performed as a single permutation operation that performs both functions, or they can be implemented sequentially, either deinterleaving before widening or widening before deinterleaving, depending on the specific circuit implementation. At step 126, widened data elements are written to two or more vector destination registers as corresponding vector operands with given vector lengths VL, SVL. The portions of the destination registers corresponding to the masked data elements are set to values ​​independent of those masked data elements, which would otherwise have their widened versions written to those portions. For example, the masked portions of the destination registers can be set to zero or can retain the values ​​previously specified in those portions of the destination registers.

[0098] Figure 10The steps performed at step 104 are illustrated for a processing operation executed when the instruction decoded at step 100 is a non-deinterleaved variant of a widened vector load instruction. At step 130, the processing circuitry applies an assertion at the granularity of individual data elements based on at least one assertion value of the operand designated as the widened load instruction. Based on the assertion, one or more individual data elements are identified as masked data elements. At step 132, the processing circuitry loads at least one vector of data elements having a first data element size from a memory location corresponding to a target memory address calculated from at least one address operand of the instruction. Load requests can be suppressed for portions of the memory range referenced by the instruction corresponding to the masked data elements identified at step 130. Alternatively, regardless of how the assertion generates a load request specifying an access corresponding to the full vector width, if a page fault is found to occur for a data element marked as masked by the assertion, a fault handling response for such masked data elements can be suppressed, and any loaded data associated with the masked data can be discarded without writing it to the destination vector register. At step 134, processing circuits 16 and 56 widen the loaded data elements (without deinterleaving) to generate widened data elements with a second data element size. At step 126, the widened data elements are written to two or more vector destination registers as corresponding vector operands with given vector lengths VL and SVL. Again, zero-return assertions or merge assertions can be used such that the masked portions of the destination registers can be set to zero or can retain the values ​​previously specified in those portions of the destination registers (in either case, the values ​​in the masked portions are independent of the corresponding masked data elements of the data stored in memory). For the non-deinterleaved variant of the instruction, when all elements are active (and no elements are asserted to mask), the elements written to a given destination register correspond to data elements stored at contiguous memory address blocks in a memory-based data structure.

[0099] The concepts described herein may be embodied in computer-readable code used to manufacture devices embodying the described concepts. For example, the computer-readable code may be used in one or more stages of the semiconductor design and manufacturing process, including the electronic design automation (EDA) stage, to manufacture integrated circuits including devices embodying these concepts. The aforementioned computer-readable code may additionally or alternatively enable the definition, modeling, simulation, verification, and / or testing of devices embodying the concepts described herein.

[0100] For example, computer-readable code for manufacturing a device embodying the concepts described herein may be embodied in code that defines the hardware description language (HDL) representation of these concepts. For instance, the code may define a register-transfer level (RTL) abstraction of one or more logic circuits for defining a device embodying these concepts. The code may define an HDL representation of one or more logic circuits embodying the device using Verilog, SystemVerilog, Chisel, or VHDL (Very High Speed ​​Integrated Circuit Hardware Description Language) and intermediate representations such as FIRRTL. Computer-readable code may provide definitions of the concepts or other behavioral representations of the concepts embodying the concepts using system-level modeling languages ​​such as SystemC and SystemVerilog, which can be interpreted by a computer to enable simulation, functional and / or formal verification and testing of the concepts.

[0101] Additionally or alternatively, computer-readable code may define a low-level description of an integrated circuit component embodying the concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. One or more netlists or other computer-readable representations of the integrated circuit component may be generated by applying one or more logic synthesis processes to the RTL representation to generate a definition for manufacturing a device embodying the invention. Alternatively or additionally, one or more logic synthesis processes may generate a bitstream from the computer-readable code to be loaded into a field-programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purpose of verifying and testing the concepts prior to manufacturing integrated circuits, or the FPGA may be deployed directly in a product.

[0102] Computer-readable code may include a mixture of code representations for manufacturing apparatus, such as one or more of RTL representations, netlist representations, or other computer-readable definitions used in the semiconductor design and manufacturing process for manufacturing apparatus embodying the present invention. Alternatively or additionally, the concept may be defined in a combination of computer-readable definitions used in the semiconductor design and manufacturing process for manufacturing apparatus and computer-readable code defining instructions that will be executed by the defined apparatus once manufactured.

[0103] Such computer-readable code can be contained in any known transient computer-readable medium (such as wired or wireless transmission of code over a network) or non-transient computer-readable medium such as semiconductors, disks, or optical discs. Integrated circuits made using computer-readable code may include components such as one or more of the following: a central processing unit, a graphics processing unit, a neural processing unit, a digital signal processor, or other components that embody the concept independently or collectively.

[0104] Figure 11Examples of emulator implementations that can be used are illustrated. While the previously described embodiments implement the invention in terms of means and methods for operating specific processing hardware supporting the technologies involved, it is also possible to provide an instruction execution environment according to the embodiments described herein, which is implemented using a computer program. Such computer programs are generally referred to as emulators, in part because they provide a software-based implementation of a hardware architecture. Types of emulator computer programs include simulators, virtual machines, models, and binary converters, including dynamic binary converters. Typically, the emulator implementation can run on a host processor 330 having host storage circuitry 332 (e.g., registers and / or memory), optionally running a host operating system 320, thereby supporting the emulator program 310. In some arrangements, multiple emulation layers may exist between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors were required to provide emulator implementations that executed at a reasonable speed, but this approach may be reasonable in certain situations, such as when it is desirable to run code native to another processor for compatibility or reuse reasons. For example, a simulator implementation can provide additional functionality to the instruction execution environment that is not supported by the host processor hardware, or provide an instruction execution environment that is typically associated with different hardware architectures. An overview of simulation is given in the following literature: "Some Efficient Architecture Simulation Techniques", Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0105] With respect to embodiments previously described with reference to specific hardware constructions or features, equivalent functionality may be provided in simulated embodiments by suitable software constructions or features. For example, specific circuitry may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware (such as registers or caches) may be implemented as software data structures stored in host storage devices (e.g., memory or registers) of host processor 330 in simulated embodiments. Where one or more of the hardware elements referenced in the previously described embodiments are present in the arrangement on the host hardware (e.g., host processor 330), some simulated embodiments may utilize the host hardware where appropriate.

[0106] The simulator program 310 may 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 300 (which may include an application program, an operating system, and a management program), the same as the interface of the hardware architecture modeled by the simulator program 310. Therefore, the simulator program 310 can be used to execute the program instructions of the target code 300 from within the instruction execution environment, enabling a host computer 330, which does not actually possess the hardware features of the device 2 discussed above (e.g., the instruction decoder 10 and processing circuitry 16 supporting widened vector loading instructions as discussed above), to emulate these features.

[0107] Therefore, the simulator program 310 may have instruction decoding program logic 312 for decoding the instructions of the target code 300 and mapping them to corresponding instruction sets in the native instruction set of the host device 330, which are provided as part of the simulator program's processing program logic 313. The instruction decoding program logic 312 includes decoding program logic 313 for decoding widened vector load instructions as described above. Register emulation program logic 314 maps register accesses requested by the instructions of the target code to accesses to corresponding data structures maintained in the host storage circuitry 332 of the host device 330, such as by accessing data in the registers or memory of the host device 330. Memory management program logic 316 implements address translation, page table traversal, and access permission checks in a manner corresponding to the MMU 36 described in the hardware implementation above, to simulate accesses to the simulated address space by the target code 300. Memory address space emulation program logic 318 is provided to map simulated physical addresses, obtained by memory management program logic 316 based on address translation using page table information maintained by the software of target program code 300, to host virtual addresses for accessing host memory of host processor 330. These host virtual addresses themselves can be translated into host physical addresses using standard address translation mechanisms supported by the host (the translation from host virtual address to host physical address is outside the scope controlled by emulator program 310).

[0108] In this application, the phrase "configured as..." is used to mean that the elements of the device have a configuration capable of performing the defined operations. In this context, "configuration" refers to 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 the function. "Configured as" does not mean that the elements of the device need to be changed in any way to provide the defined operations.

[0109] In this application, a list of features beginning with the phrase “at least one of” means that any one or more of those features may be provided independently or in combination. For example, “at least one of [A], [B], and [C]” covers any of the following options: A only (without B or C), B only (without A or C), C only (without A or B), a combination of A and B (without C), a combination of A and C (without B), a combination of B and C (without A), or a combination of A, B, and C.

[0110] While exemplary 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 various changes and modifications can be made therein by those skilled in the art without departing from the scope of the invention as defined in the appended claims.

Claims

1. An apparatus, the apparatus comprising: An instruction decoding circuit, wherein the instruction decoding circuit is used to decode instructions; and A publishing circuit, configured to, in response to the decoding of a given instruction by the instruction decoding circuit, publish at least one micro-operation to control the processing circuit to perform a processing operation corresponding to the given instruction; wherein: In response to the decoding of a widened vector load instruction specifying at least one address operand and a plurality of vector destination registers, each specifying a vector operand with a given vector length, the instruction decoding circuit is configured to control the issuing circuit to issue at least one micro-operation to control the processing circuit: Load at least one vector of data elements from the memory system at a location corresponding to a target memory address determined based on the at least one address operand; The data elements of at least one loaded vector are widened from a first data element size to a second data element size larger than the first data element size; and Widened data elements with the size of the second data element are written to the plurality of vector destination registers as a plurality of corresponding vector operands.

2. The apparatus of claim 1, wherein the widened vector loading instruction allows at least one loaded vector of the data element to have a total size greater than or equal to the given vector length.

3. The apparatus according to any one of claims 1 and 2, wherein, In response to a deinterleaving variant of the widened vector loading instruction, the instruction decoding circuit is configured to control the publishing circuit to publish the at least one micro-operation to control the processing circuit to deinterleave multiple interleaved channels of data elements obtained from the at least one vector, such that each vector destination register specifies one or more widened data elements corresponding to different channels among the multiple interleaved channels.

4. The apparatus of claim 3, wherein the deinterleaving mode for writing the widened data elements into the plurality of vector destination registers is implicitly defined by encoding the deinterleaving variant of the widened vector load instruction.

5. The apparatus of any one of claims 3 and 4, wherein the deinterleaving variant of the widened vector load instruction specifies at least one assertion value, the at least one assertion value specifies element assertion information, the element assertion information indicating which data elements of the at least one vector are masked data elements, and a corresponding portion of the plurality of vector destination registers for the masked data elements is used to specify a value unrelated to the masked data elements.

6. The apparatus of claim 5, wherein the element assertion information is specified by the at least one assertion value at the granularity of element groups, each element group comprising a data element from each of the plurality of interleaved channels.

7. The apparatus according to any of the preceding claims, wherein, In response to the non-deinterleaved variant of the widened vector load instruction, the instruction decoding circuit is configured to control the publishing circuit to publish the at least one micro-operation to control the processing circuit to write a set of widened data elements corresponding to the locations of data elements loaded from contiguous memory address blocks in the memory system to a given vector destination register among the plurality of vector destination registers.

8. The apparatus of claim 7, wherein the non-deinterleaved variant of the widened vector load instruction specifies at least one assertion value, the at least one assertion value specifies element assertion information, the element assertion information indicating which data elements of the at least one vector are masked data elements, and a corresponding portion of the plurality of vector destination registers for the masked data elements is used to specify a value unrelated to the masked data elements.

9. The apparatus of claim 8, wherein the element assertion information is specified by the at least one assertion value at the granularity of individual data elements of the at least one vector.

10. The apparatus of any one of claims 8 and 9, wherein the non-deinterleaved variant of the widened vector load instruction specifies at least one assertion register, each assertion register specifying an assertion value specifying element assertion information for controlling assertions of two or more of the plurality of vector destination registers.

11. The apparatus according to any of the preceding claims, wherein the plurality of vector destination registers comprises at least three vector destination registers.

12. The apparatus according to any of the preceding claims, wherein the plurality of vector destination registers comprises at least four vector destination registers.

13. The apparatus according to any of the preceding claims, wherein the widened vector loading instruction allows at least one loaded vector of the data element to have a total size greater than or equal to twice the length of the given vector.

14. The apparatus according to any of the preceding claims, wherein at least one of the first data element size and the second data element size is variable and depends on at least one control parameter associated with the widening vector loading instruction.

15. The apparatus according to any preceding claim, the apparatus comprising a vector length storage device circuit for storing a vector length parameter indicating the given vector length.

16. The apparatus according to any of the preceding claims, wherein the apparatus includes the processing circuit.

17. The apparatus according to any of the preceding claims, wherein, For at least a subset of instruction types, the publishing circuit is configured to publish the at least one micro-operation to off-chip processing circuitry on an integrated circuit separate from the publishing circuit.

18. The apparatus according to any one of claims 1 to 16, the apparatus comprising a coprocessor configured to perform processing operations on a subset of instruction types unloaded by a main processor, the coprocessor including the instruction decoding circuitry for decoding instructions of the subset of instruction types and the dispatch circuitry.

19. A computer-readable code for manufacturing an apparatus, the apparatus comprising: An instruction decoding circuit, wherein the instruction decoding circuit is used to decode instructions; and A publishing circuit, configured to, in response to the decoding of a given instruction by the instruction decoding circuit, publish at least one micro-operation to control the processing circuit to perform a processing operation corresponding to the given instruction; wherein: In response to the decoding of a widened vector load instruction specifying at least one address operand and a plurality of vector destination registers, each specifying a vector operand with a given vector length, the instruction decoding circuit is configured to control the issuing circuit to issue at least one micro-operation to control the processing circuit: At least one vector of a data element is loaded from a location in the memory system corresponding to a target memory address determined based on the at least one address operand, wherein the at least one vector of the data element has a total size greater than or equal to the given vector length; The data elements of at least one loaded vector are widened from a first data element size to a second data element size larger than the first data element size; and Widened data elements having the size of the second data element are written to the plurality of vector destination registers as a plurality of corresponding vector operands, each having the given vector length.

20. A method, the method comprising: Decode the instructions; as well as In response to the decoding of a given instruction, at least one micro-operation is issued to control the processing circuitry to perform a processing operation corresponding to the given instruction; wherein: In response to the decoding of a widened vector load instruction specifying at least one address operand and a plurality of vector destination registers, each specifying a vector operand with a given vector length, at least one micro-operation is issued to control the processing circuitry: At least one vector of a data element is loaded from a location in the memory system corresponding to a target memory address determined based on the at least one address operand, wherein the at least one vector of the data element has a total size greater than or equal to the given vector length; The data elements of at least one loaded vector are widened from a first data element size to a second data element size larger than the first data element size; and Widened data elements having the size of the second data element are written to the plurality of vector destination registers as a plurality of corresponding vector operands, each having the given vector length.

21. A computer program for controlling a host data processing device to provide an instruction execution environment for executing target program code, the computer program comprising: Instruction decoding program logic, which is used to decode the instructions of the target program code; and Processing logic, the processing logic being used to perform processing operations corresponding to a given instruction decoded by the instruction decoding logic; wherein: In response to the decoding of a widened vector load instruction specifying at least one address operand and a plurality of vector destination registers, each specifying a vector operand with a given vector length, the instruction decoding program logic is configured to control the process logic: At least one vector of a data element is loaded from a location in the simulated address space corresponding to a target memory address determined based on the at least one address operand, wherein the at least one vector of the data element has a total size greater than or equal to the given vector length; The data elements of at least one loaded vector are widened from a first data element size to a second data element size larger than the first data element size; and Widened data elements having the second data element size are written to host storage circuitry corresponding to the plurality of vector destination registers as a plurality of corresponding vector operands each having the given vector length.

22. A storage medium storing computer-readable code according to claim 18 or a computer program according to claim 21.

Images