Subvector Support Instructions for the Scalable Vector Instruction Set Architecture

Abstract

The apparatus includes a processing circuit (16) for performing data operations, and an instruction decode circuit (10) for controlling the processing circuit to perform the data operations in response to decoding program instructions defined according to a scalable vector instruction set architecture that supports vector instructions operating on vectors of scalable vector lengths to allow the same instruction sequence to be executed on devices having hardware supporting different maximum vector lengths. The instruction decode circuit and the processing circuit support subvector support instructions that treat a given vector as including multiple subvectors, each subvector including multiple vector elements. In response to the subvector support instructions, the instruction decode circuit controls the processing circuit to perform operations for the given vector at subvector granularity. Each subvector has an equal subvector length.

Description

[Technical field]

[0001] The present technique relates to the field of data processing.

[0002] An instruction set architecture (ISA) defines the set of instructions available to a software developer or compiler when developing a particular software program, and in a corresponding way, the set of instructions that must be supported by a processor implementation in hardware to enable the hardware to be compatible with software written according to the ISA. For example, an ISA may define, for each instruction, the encoding of the instruction, the representation of its input operands and result values, and a function for mapping the input operands to the result of the instruction.

[0003] A vector ISA supports at least one vector instruction that operates on vector operands containing two or more independent vector elements represented in a single register and / or produces a vector result containing two or more independent vector elements. Vector instructions may be processed in a SIMD (single instruction, multiple data) manner to allow multiple independent calculations to be performed on different data values ​​in response to a single instruction. Vector instructions may be useful, for example, to allow a scalar loop of instructions written in high-level code to be vectorized such that operations corresponding to multiple loop iterations may be performed in response to a single iteration of the vectorized loop. This helps improve performance by shrinking the number of instructions that need to be fetched, decoded, and executed to perform a particular amount of data processing.

[0004] At least some examples provide an apparatus comprising a processing circuit for performing data processing; and an instruction decode circuit for controlling the processing circuit to perform the data processing in response to decoding a program instruction defined according to a scalable vector instruction set architecture that supports vector instructions operating on vectors of scalable vector lengths to enable the same instruction sequence to be executed on devices having hardware supporting different maximum vector lengths, wherein the instruction decode circuit and the processing circuit are configured to support sub-vector support instructions that treat a given vector as including multiple sub-vectors, each sub-vector including multiple vector elements, each sub-vector having an equal sub-vector length, and in response to the sub-vector support instruction, the instruction decode circuit is configured to control the processing circuit to perform operations for the given vector at sub-vector granularity.

[0005] At least some examples provide a method that includes using an instruction decode circuit to decode program instructions defined in accordance with a scalable vector instruction set architecture that supports vector instructions operating on vectors of scalable vector lengths to enable the same instruction sequence to be executed on devices having hardware supporting different maximum vector lengths, and controlling a processing circuit to perform data processing in response to the decoding of the program instruction, wherein the instruction decode circuit and the processing circuit support sub-vector support instructions that treat a given vector as including multiple sub-vectors, each sub-vector including multiple vector elements, each sub-vector having an equal sub-vector length, and in response to the sub-vector support instruction, the instruction decode circuit controls the processing circuit to perform operations for the given vector at sub-vector granularity.

[0006] At least some examples provide a computer program for controlling a host data processing apparatus to provide an instruction execution environment for executing target code, the computer program including instruction decode program logic for decoding instructions of the target code to control the host data processing apparatus to perform data processing in response to instructions of the target code, the instruction decode program logic supporting decoding of program instructions defined according to a Scalable Vector Instruction Set Architecture that supports vector instructions operating on vectors of scalable vector lengths to enable the same instruction sequence to be executed on apparatuses having hardware supporting different maximum vector lengths, the instruction decode program logic including sub-vector support instruction decode program logic for decoding sub-vector support instructions, the sub-vector support instructions treating a given vector as including multiple sub-vectors, each sub-vector including multiple vector elements, each sub-vector having an equal sub-vector length, and in response to the sub-vector support instruction the instruction decode program logic is configured to control the host data processing apparatus to perform operations for the given vector at sub-vector granularity.

[0007] The computer program may be stored in a storage medium. The storage medium may be a non-transitory storage medium. [Brief description of the drawings]

[0008] Further aspects, features, and advantages of the present technique will become apparent from the following description of examples, read in conjunction with the accompanying drawings. [Figure 1] 1 illustrates an example of a data processing apparatus that supports a vector ISA. [Diagram 2] 1 shows an example of registers for the scalable vector ISA. [Diagram 3] 1 shows an example of prediction and variable vector element sizes. [Figure 4]We present an example of a scalable vector ISA that allows different hardware implementations that support different maximum vector lengths to execute the same instruction sequence. [Diagram 5] 1 shows an example of a vector being treated as a vector of subvectors. [Figure 6] 1 illustrates how to process subvector support instructions. [Figure 7] 1 illustrates several examples of sub-vector support permute instructions. [Figure 8] 1 illustrates several examples of sub-vector support permute instructions. [Figure 9] 1 illustrates several examples of sub-vector support permute instructions. [Figure 10] 1 illustrates several examples of sub-vector support permute instructions. [Figure 11] 1 illustrates several examples of sub-vector support permute instructions. [Figure 12] 1 illustrates an example of a subvector support reduce instruction. [Figure 13] 1 illustrates an example of a subvector support reduce instruction. [Figure 14] 1 shows an example of sub-vector support load / store instructions. [Figure 15] 1 shows an example of sub-vector support load / store instructions. [Figure 16] 13 shows an example of a subvector support predicate setting instruction. [Figure 17] 13 shows an example of a subvector support predicate setting instruction. [Figure 18] 13 shows an example of subvector support increment / decrement instructions. [Figure 19] 1 shows an implementation of a simulator.

[0009] The apparatus has a processing circuit for performing data processing, and an instruction decode circuit for controlling the processing circuit to perform data processing in response to decoding of a program instruction defined according to a scalable vector instruction set architecture (ISA). The scalable vector ISA (also known as a "vector length agnostic" vector ISA) supports vector instructions that operate on vectors of a scalable vector length to allow the same instruction sequence to be executed on devices having hardware that supports different maximum vector lengths. This is useful because it allows hardware designers of different processor implementations to choose different maximum vector lengths depending on whether their design priority is high performance or reduced circuit area and power consumption, while software written according to the scalable vector ISA can be executed across any hardware platform that supports the scalable vector ISA regardless of the specific maximum vector length supported by the specific hardware platform, so that software developers do not have to tailor their software to a specific hardware platform. Thus, the vector length used for a particular vector instruction of the scalable vector ISA is unknown at compile time (it is neither defined as fixed in the ISA itself nor specified by parameters of the software itself). The operations performed in response to a given vector instruction of the scalable vector ISA may vary depending on the vector length selected for a particular hardware implementation (e.g., hardware that supports a larger maximum vector length may process a larger number of vector elements for a given vector instruction than hardware that supports a smaller maximum vector length). Thus, an implementation with a shorter vector length may require a larger number of loop iterations to perform a particular function than an implementation with a longer vector length.

[0010] Although the scalable vector ISA can be very useful for enabling the development of platform-independent program code that can be easily ported between processor implementations with different maximum vector lengths, there may be a significant amount of legacy code that was compiled assuming a known vector length. Redeveloping the legacy software for use with the scalable vector ISA may require a significant amount of software development effort. This is especially true because some software techniques commonly used to improve the performance of vectorized code, such as software pipelining or loop unrolling, may rely on the vector length used for instructions being known at compile time. Thus, it may not be easy to remap instructions of a non-scalable vector ISA to instructions of a scalable vector ISA, since some techniques used in the legacy code may not be available in the scalable vector ISA. This may be a significant barrier to adoption of the scalable vector ISA and may result in some software developers choosing not to use it, and thus a significant amount of software running on newer processors that support the scalable vector ISA may still use a less performance-efficient non-scalable vector ISA that uses a relatively short maximum vector length, even on processor implementations that support a large maximum vector length using the scalable vector ISA (which may also support the non-scalable vector ISA for backward compatibility reasons). This means that the full execution capabilities of the hardware may not be used for many programs.

[0011] In the example described below, the instruction decode circuitry and processing circuitry support subvector support instructions in the scalable vector ISA that treat a given vector as including multiple subvectors, each subvector including multiple vector elements, each subvector having an equal subvector length. In response to the subvector support instruction, the instruction decode circuitry controls the processing circuitry to perform operations for the given vector at subvector granularity. This helps reduce the software development effort required to enable adoption of the scalable vector ISA, since each vector of the non-scalable vector ISA can be mapped to one of the subvectors of a vector in the scalable ISA. This makes it easier to map non-scalable software to scalable software, thus reducing the barrier to use of the scalable vector ISA, making it more likely that a larger portion of code executing on a device that supports the scalable vector ISA is actually using the scalable vector ISA, and tends to improve average performance across a range of processor implementations, since high-end processors that support longer vector lengths may be more likely to be able to take advantage of those longer vector lengths to improve performance.

[0012] Each subvector may have a subvector length that is known at compile time for a given sequence of instructions executed using the subvector support instructions. This is useful because it allows a vector operand or result of the scalable vector ISA to be defined as a "vector of vectors" that includes multiple smaller subvectors, each of known vector length, so that multiple vectors defined according to software written using a non-scalable vector ISA can be combined into a larger vector according to the scalable vector ISA. Because the length of each subvector is known at compile time, any performance improving software techniques that rely on knowledge of vector length at compile time can be applied at the granularity of a subvector, making it much easier for software developers to map code written according to a non-scalable vector ISA to code defined according to a scalable vector ISA while preserving those software techniques.

[0013] How many subvectors are included in a given vector is unknown at the time of compilation of a given sequence of instructions executed using the subvector support instructions. In other words, the overall vector length for a given vector may be the scalable vector length allowed by the scalable vector ISA (which may define various maximum vector lengths that may be allowed for different processor implementations). This means that the subvector support instructions can support a range of different performance / power points while still benefiting from the platform independent properties of the scalable vector ISA. Nevertheless, software optimizations that rely on knowledge of the vector length used as the granularity of vectorization can still be used, since subvectors of known subvector length can be referenced and applied before the subvector support instructions can be used to accommodate a variable number of subvectors into a given vector of a larger scalable vector length. For example, a variable number of iterations of a vectorized loop that was previously implemented in vectorized form using a non-scalable vector ISA can be mapped to a vectorized loop in the scalable vector ISA, with each iteration of the original vectorized loop corresponding to one of the subvectors of the vector processed by the subvector support instructions of the scalable vector ISA. This makes code compilation and software development much simpler, as it can avoid the need to go back from the vectorized non-scalable code to the scalar loop before converting the scalar loop back to vectorized scalable code according to the ISA; instead, it can be simpler to map vector instructions of the non-scalable ISA directly to scalable vector instructions of the scalable ISA, without an intervening de-vectorization step (other compilers can simply compile directly for the scalable ISA containing the sub-vector processing instructions, without basing their compilation on previous code compiled for the non-scalable ISA).The subvector length, which is known at compile time, may be independent of the vector length used for a given vector, and thus the subvector length is the same for a given instruction in a given piece of software regardless of the actual vector length used for a given vector overall by a given hardware implementation.

[0014] In response to the subvector support instruction, the instruction decode circuitry can control the processing circuitry to process each of the subvectors in response to the same instance of executing the subvector support instruction. For example, each of the operations performed at the subvector granularity may be processed in parallel. Alternatively, the operations performed at the subvector granularity may be processed sequentially, or partially sequentially and partially in parallel, or in a pipelined manner. Regardless of the exact timing at which the various operations are performed at the subvector granularity, each of the operations at the subvector granularity is performed in response to a single instance of execution of the subvector support instruction such that the SIMD benefits of the vector ISA may be realized.

[0015] There are some ways in which the subvector length can be known at compile time. In some implementations of a scalable vector ISA, the ISA can define the subvector length as a variable software-defined parameter that can be specified by the software code itself to allow the software to choose between two or more different subvector sizes. For example, this can be useful to provide support for remapping code from two or more different non-scalable vector ISAs with different non-scalable vector lengths.

[0016] However, in one example, each subvector may have an architecturally defined fixed-size subvector length that is independent of the vector length used for a given vector. This may simplify the architecture and avoid the need for software to specify the subvector length. Instead, the subvector length may be fixed in the architectural definition of the subvector support instructions defined in the scalable vector ISA.

[0017] The architecturally-defined fixed size may correspond to an architecturally-defined maximum vector length prescribed for vector instructions processed according to a given non-scalable vector ISA, for example, the given non-scalable vector ISA may be the "Advanced SIMD" architecture (also known as the Neon™ architecture) offered by Arm® Limited of Cambridge, UK.

[0018] For example, an architecturally defined fixed size for the subvector length may be 128 bits. This is useful for compatibility with the Advanced SIMD architecture, which defines a maximum vector length of 128 bits.

[0019] It is also possible to implement subvector support instructions that target other non-scalable vector ISAs, in which case the subvector length may vary depending on the particular ISA targeted.

[0020] It is also possible to implement subvector support instructions without any intention of targeting any particular non-scalable vector ISA, but simply choose a given fixed subvector length without regard to any objective of emulating lengths used in a particular non-scalable vector ISA. Even if there is no particular non-scalable vector ISA being targeted, it may still be useful to define subvectors that have an architecturally defined, fixed-size subvector length to allow software developers and compilers to take advantage of software performance optimizations that rely on compile-time knowledge of that fixed size.

[0021] The subvector support instructions may support variable element sizes such that each vector element of each subvector has a variable element size selected from two or more different sizes supported by the scalable vector ISA. The subvector length may be independent of which element size is used for each vector element in each subvector. Thus, the same subvector length may be used regardless of whether the selected element size is a larger element size or a smaller element size. The number of vector elements defined for each subvector may correspond to a ratio between the subvector length and the selected element size. The selected element size may be defined by a software-specified parameter of the instruction sequence including the subvector support instructions and is therefore known at compile time. Thus, since both the subvector length and element size may be known at compile time, the number of vector elements provided per subvector may also be known at compile time, but since the overall vector length of a given vector is not known at compile time according to the scalable vector ISA, the total number of vector elements in a given vector as a whole may not be known at compile time.

[0022] The operations performed at subvector granularity can vary: some different subvector support instructions may be defined as part of a scalable vector ISA to allow some different operations to be performed at subvector granularity, depending on the programmer's or compiler's choice.

[0023] In some examples, for at least one subvector support instruction, the operations performed at subvector granularity are operations performed for each subvector on the vector elements within that subvector, independent of the elements in other subvectors. This can thus enable operations that would have been performed using several separate vector instructions in a non-scalable vector ISA (each operating on a respective vector of a non-scalable vector length known at compile time) to be performed in a single subvector support instruction (e.g., those separate vector instructions may correspond to different iterations of a loop written into the code of the non-scalable vector ISA).

[0024] In some examples, for at least one subvector support instruction, the operations performed at subvector granularity are operations performed for each element position in a subvector on the respective vector element at that element position in each of a plurality of subvectors. Such instructions may be useful, for example, to replicate processing that would have been performed using a sequence of vector instructions in a single loop iteration, which would have combined data values ​​at corresponding element positions in some vector operands specified for that sequence of vector instructions.

[0025] In some examples, for at least one subvector support instruction, the operation performed at subvector granularity is an operation to set selected predicate bits of a predicate value or perform an operation accordingly, where the selected predicate bits are predicate bits corresponding to a subvector-sized portion of a vector. This may differ from many instructions of a scalable vector ISA that may set or interpret a predicate at the granularity of an individual vector element, which is smaller than the subvector length. Such subvector support predicate setting or predicate-dependent instructions may be useful in certain cases, for example, to allow processing of an entire subvector to be selectively masked in conditions where corresponding code of a non-scalable vector ISA would have masked out an entire iteration of a vectorization loop executed on vectors of a particular vector length known at compile time.

[0026] In some examples, the scalable vector ISA may support at least one variant of a subvector support permute instruction. In response to the subvector support permute instruction, the instruction decoder controls the processing circuitry to set, for each subvector of the vector result, the subvector to a permute of one or more vector elements selected from among the vector elements in the correspondingly located subvectors of the at least one vector operand. The subvector support permute instruction may not set the vector elements of a given subvector of the vector result based on bits of vector elements in different non-corresponding subvector positions in one of the vector operands. By performing permute at subvector granularity rather than across the vector length of a given vector as a whole, this may allow the behavior of the subvector support permute instruction to mirror the behavior of some separate non-scalable permute instructions defined in non-scalable vector ISAs that assume a known vector length for permutes, but still allow the number of such subvector granularity permutes performed for a given instruction to be scaled based on the implemented vector length supported in hardware according to the scalable vector ISA.

[0027] In some examples, the scalable vector ISA may support at least one variant of a subvector support reduce instruction. In response to the subvector support reduce instruction, the instruction decoder may control the processing circuit to perform at least one reduce operation at subvector granularity, each reduce multiple vector elements of an operand vector to a single data value in a result. When such a reduce operation is performed at the granularity of an individual subvector, it may provide a different result than a corresponding reduce operation performed over the entire vector length, since vector elements in different subvectors may not be combined with each other. Such a reduce may be useful in a sequence of non-scalable vectorized code to emulate processing that may have been implemented by a sequence of multiple instructions in a given loop iteration or a series of loop iterations, each loop iteration including a single instance of an instruction for combining each element of a vector operand with a corresponding element of an accumulator value that tracks the results of similar combinations in any preceding loop iterations.

[0028] Different variations of the subvector supporting reduce instruction are possible that differ in how the reduction is performed at the subvector granularity.

[0029] For example, for an inter-subvector subvector support reduce instruction, for each reduce operation, the plurality of vector elements includes respective vector elements in a corresponding subvector of the operand vector. Including such an instruction in the ISA may be useful to enable software developers to use the instruction to emulate the behavior of non-scalable code that performed a reduce across all vector elements of a single vector operand in a scalable architecture with unknown vector length at compile time. The result of each subvector granularity reduction may be placed in a different subvector of the result value. Alternatively, a variation of the inter-subvector subvector support reduce instruction may place the result of each subvector granularity reduction into respective vector elements of one or more subvectors of the result value.

[0030] In another variation, for an inter-subvector subvector support reduce instruction, for each reduce operation, the multiple vector elements include vector elements at corresponding element positions in multiple subvectors of the operand vector. For this type of instruction, the vector elements that are reduced to a single result are selected vector elements at intervals of the subvector length. Including such an instruction in the ISA may be useful to enable software developers to use the instruction to emulate the behavior of non-scalable code that performs a reduce across vector elements at the same element position in a vector in some consecutive loop iterations in a scalable architecture with unknown vector lengths at compile time.

[0031] A scalable vector ISA may support any one or more of these types of sub-vector support reduce instructions.

[0032] In some examples, the scalable vector ISA may support at least one variant of a sub-vector supported load / store instruction. In response to the sub-vector supported load / store instruction, the instruction decoder may control the processing circuitry to perform load / store operations to transfer one or more sub-vectors between the memory system and at least one vector register at sub-vector granularity. This may be useful to emulate the behavior of load / store instructions of a non-scalable vector ISA that would have performed corresponding load / store operations on vectors of known vector length.

[0033] The subvector support load / store instruction may be a predicated instruction associated with a predicate value. In response to the subvector support load / store instruction, the instruction decoder may control the processing circuitry to control whether each transfer of one or more subvectors is executed or masked based on a predicate bit selected from the predicate value at subvector granularity. This may differ from the behavior of other load / store instructions of the scalable vector ISA, which may perform load / store operations across the entire (scalable) vector length with a predicate selected at the granularity of the element size used for the vector elements of the vector (the element size is smaller than the subvector length).

[0034] In some examples, the scalable vector ISA may support at least one variant of a subvector support increment / decrement instruction. In response to the subvector support increment / decrement instruction, the instruction decoder may control the processing circuit to increment or decrement an operand value based on how many subvector-sized portions of the vector are indicated as active by bits of a predicate value selected from the predicate value at subvector granularity. This may be useful for loop control, such that a loop control variable used by the software to determine whether at least one further loop iteration still needs to be executed may be incremented or decremented according to the number of subvectors processed in the latest iteration of the loop (since the number of subvectors processed in that loop iteration may not be known at compile time, it may be useful to provide an instruction that allows the number of subvectors processed to be inferred and used to update the loop control variable accordingly).

[0035] The predicate value used by the subvector support increment / decrement instruction to determine how to update the operand value may be one of a predicate value specified as a predicate operand by the subvector support increment / decrement instruction and a predicate value implied by a predicate pattern identifier specified by the subvector support increment / decrement instruction, where the predicate pattern identifier specifies a predetermined pattern of predicate bits at subvector granularity.

[0036] In some examples, the scalable vector ISA may support at least one variant of a subvector support predicate setting instruction. In response to the subvector support predicate setting instruction, the instruction decoder may control the processing circuit to execute a predicate setting operation to set bits of a predicate value at subvector granularity to indicate which subvectors of a vector are active. Such instructions may be useful for controlling which subvectors are processed by other subvector support predicate instructions. A bit of the predicate value set to a particular value (e.g., 0) may cause the processing of the corresponding subvector to be masked. Such predicate setting instructions may be different instructions from other predicate setting instructions of the scalable vector ISA that may set predicate values ​​at the granularity of the vector element size, which may be smaller than the subvector length.

[0037] The predicate setting operation for the subvector support predicate setting instruction may include setting the predicate value based on one of a predicate pattern identifier that specifies a predetermined pattern of predicate bits to be applied at subvector granularity and a subvector granularity comparison operation that is based on a comparison of a first operand and a second operand. With this approach, the new value of the predicate may be defined according to some general pattern that is not explicitly specified in the subvector support predicate setting instruction but that may be scalable for different vector lengths. This is useful because the number of predicate bits to be set may be unknown at compile time due to the scalable vector lengths.

[0038] Various examples of sub-vector support instructions are described above. It will be understood that any given implementation of the scalable vector ISA need not support all of these types of instructions. Any one or more of the instructions described in this application may be implemented.

[0039] The techniques described above may be implemented within a data processing apparatus having hardware circuitry provided for implementing the instruction decoder and processing circuitry described above.

[0040] However, the same technique may also be implemented in a computer program that runs on a host data processing device to provide an instruction execution environment for execution of the target code. Such a computer program may control the host data processing device to simulate an architectural environment provided on a hardware device that actually supports the target code according to the scalable vector instruction set architecture, even if the host data processing device itself does not support that architecture. The computer program may have instruction decode program logic that emulates the functionality of the instruction decode circuitry described above. For example, the instruction decode program logic, in response to a given instruction of the target code, generates a corresponding sequence of code in the native instruction set of the host data processing device to control the host data processing device to perform a function corresponding to the decoded instruction. The instruction decode program logic includes sub-vector support instruction decode program logic for decoding sub-vector support instructions as described above to control the host data processing device to perform operations for a given vector at sub-vector granularity. Such a simulation program may be useful, for example, when legacy code written for one instruction set architecture is being executed on a host processor that supports a different instruction set architecture. Also, running the software on the simulation execution environment can enable testing of the software in parallel with ongoing development of hardware devices that support the new architecture, so that the simulation can enable software development of a new version of the instruction set architecture to begin before processing the hardware that supports the new architecture version. The simulation program may be stored in a storage medium, which may be a non-transitory storage medium.

[0041] Specific examples will now be described with reference to the drawings, with the understanding that the claims are not limited to these specific examples.

[0042] 1 illustrates diagrammatically an example of a data processing apparatus 2. The data processing apparatus has a processing pipeline 4 including a number of 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 decode circuit) for decoding the fetched program instructions to generate micro-ops (decoded instructions) that are processed by the remaining stages of the pipeline, an issue stage 12 for checking whether operands required for the micro-op are available in registers 14 and for issuing the micro-op for execution once the operands required for a given micro-op are available, an execute stage 16 (an example of a processing circuit) for performing a data processing operation corresponding to the micro-op by processing the operands read from registers 14 to generate a result value, and a writeback stage 18 for writing the results of the processing back to registers 14. It will be appreciated that this is just one example of a possible pipeline arrangement and other systems may have additional stages or different configurations of stages. For example, in an out-of-order processor, a register renaming stage may be included to map architectural registers specified by a program instruction or micro-op to physical register specifiers that identify physical registers in registers 14. In some examples, there may be a one-to-one relationship between program instructions decoded by decode stage 10 and corresponding micro-ops processed by the execution stage. There may also be a one-to-many or many-to-one relationship between program instructions and micro-ops, e.g., a single program instruction may be split into two or more micro-ops, or two or more program instructions may be fused together and processed as a single micro-op.

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

[0044] The registers 14 include scalar registers 25 for storing scalar values, vector registers 26 for storing vector values, and predicate registers 27 for storing predicate values. The predicate values ​​27 may be used by the vector processing unit 22 when processing vector instructions, with the predicate value in a given predicate register indicating which vector elements of a corresponding vector operand stored in the vector register 26 are active or inactive vector elements (operations corresponding to inactive data elements may be suppressed or may not affect result values ​​produced by the vector processing unit 22 in response to the vector instruction).

[0045] A memory management unit (MMU) 36 controls address translation between virtual addresses (specified by instruction fetches from fetch circuitry 6 or load / store requests from load / store unit 28) and physical addresses that identify locations in the memory system based on address mappings defined in page table structures stored in the memory system. The page table structures may also define memory attributes that may specify access permissions for accessing corresponding pages of the address space, for example, specifying whether a region of the address space is read-only or readable / writeable, specifying which privilege levels are permitted to access the region, and / or specifying other properties that govern how the corresponding region of the address space may be accessed. Entries from the page table structures may be cached in a translation lookaside buffer (TLB) 38, which is a cache maintained by MMU 36 to cache page table entries or other information to speed up access to page table entries from page table structures represented in memory.

[0046] In this example, the memory system includes a level 1 data cache 30, a level 1 instruction cache 8, a shared level 2 cache 32, and a main system memory 34. It will be appreciated that this is only one example of a possible memory hierarchy and other arrangements of caches can be provided. The particular types of processing units 20-28 shown in the execution stage 16 are only one example and other implementations may have different sets of processing units or may include multiple instances of the same type of processing unit such that multiple micro-operations of the same type may be processed in parallel. It will be appreciated that FIG. 1 is only a simplified representation of some components of a possible processor pipeline configuration and that the processor may include many other elements that are not shown for the sake of brevity.

[0047] The processing pipeline 4 supports a scalable vector ISA, which means that vector instructions of the ISA can be processed without it being known at compile time (the time the executed instructions are compiled by a compiler) what vector length will be used for the execution of those vector instructions. This allows the same software code to be executed by a variety of different processing devices supporting different maximum vector lengths, avoiding the burden on the software developer to generate software code suitable for execution across a range of processing platforms. This means that the hardware designer of a given processing device has the freedom to choose the maximum vector length implemented depending on the designer's preferred performance / power requirements (a system aiming for higher performance may choose a longer maximum vector length than a system aiming for better energy efficiency).

[0048] 2 shows an example of an architectural state of a scalable vector ISA. The ISA defines as vector registers 26 a number of scalable vector registers (e.g., 32 vector registers Z0-Z31) with implementation-selected vector lengths that can be any multiple of a particular unit size up to a particular architecturally-defined maximum length for a given hardware implementation. For example, in this example, the unit size is 128 bits, and the architecture supports a maximum vector length that is any multiple of 128 bits between 128 bits and 2048 bits (i.e., the vector length for a given processor is LEN *128 bits, where 1≦LEN≦16). This differs from non-scalable vector architectures, where registers may have a fixed architecture-defined vector length, e.g., 128 bits (see registers labeled V0-V31 in FIG. 2). The example shown in FIG. 2 is based on a scalable vector ISA, the “Scalable Vector Extension” (SVE) offered by Arm® Limited, and a non-scalable vector ISA, the “Advanced SIMD” architecture (Neon™) offered by Arm® Limited. Even when supporting vector lengths greater than 128 bits according to the scalable vector ISA, the instruction decoder 10 and processing circuitry 16 may also support the non-scalable vector ISA for backward compatibility reasons, and instructions of the non-scalable vector ISA may reference fixed-length (e.g., 128-bit) registers V0-V31. In practice, these registers can be represented using portions of longer registers accessible to instructions of the scalable vector ISA, so that the scalable vector registers Z0 to Z31 and the non-scalable vector registers V0 to V31 can share hardware storage circuitry.

[0049] Of course, other examples may be based on different scalable and non-scalable architectures, and thus the range of sizes available to select for the scalable vector lengths and the fixed sizes specified for the non-scalable vector lengths may differ from those shown in FIG. 2.

[0050] Similar to the vector registers 26, a number of predicate registers 27 (labeled P0 through P15) are provided to store predicate values ​​used to selectively mask operations performed on vector elements of vector operands provided using the vector registers 26. The predicate registers 27 may have a bit for each vector element in the vector registers 26, as defined according to the minimum vector element size supported by the ISA when the maximum vector length supported in the hardware is used (the maximum vector length here being the selected size LEN used by the particular hardware implementation). * LEN refers to 128, not to the maximum vector length allowed by the architecture for any hardware implementation (e.g., 2048 bits). For example, if the minimum element size is 8 bits, then LEN * In the example of a 128-bit vector register, each predicate register has size LEN *16 bits. FIG. 3 shows an example of a prediction applied to a vector per element. The instruction may define a variable element size, for example, FIG. 3 shows how a 256-bit vector can be logically divided into either 64-bit or 32-bit elements (other element sizes, e.g., 16 or 8-bit elements, may also be possible). The predicate register 27 specified for a given vector stored in the vector register 26 specifies a sufficient number of predicate bits to be able to specify a separate predicate bit for each vector element when the smallest element size is used, but with larger element sizes, not all of the predicate bits need to be read, instead, the predicate bits may be read at intervals corresponding to the element size. For example, for 64-bit elements, one out of every eight predicate bits may be read, as shown in the top example of FIG. 3, and for 32-bit elements, one out of every four predicate bits may be read (with an 8-bit element size, each predicate bit may be read). If a predicate bit is set to 1, the corresponding element is considered active, and a vector element with the corresponding predicate bit set to 0 is considered inactive. Elements of the result vector that correspond to inactive vector elements may be masked out from being updated based on the result of the vector operation (predicated instructions may include a zeroing predicate variant in which the masked-out result elements are set to 0, or a merging predicate variant in which the masked-out result elements are set to the same value as the corresponding element in the destination register before the vector instruction is executed).

[0051] As shown in FIG. 2, registers 14 may also include some control registers 29 (labeled ZCR) that may be used by more privileged software to limit the maximum vector length available to software executing in a less privileged state. For example, to save power, a given software may be restricted from utilizing the full vector length supported by the hardware. Nevertheless, even if the more privileged software applies a limit to the vector length, the vector length for the application software is still unknown at compile time, since it is not known whether the vector length actually implemented in a particular processor is greater or less than the limit defined in control register 29 (for implementations that have a maximum vector length less than the limit defined in control register 29, the vector length less than indicated by the limit is used).

[0052] The vector-length agnostic property of a scalable vector ISA is useful because, within the fixed encoding space available for encoding the instructions of an ISA, it is not feasible to create different instructions for each different vector length that may be required by processor designers, given the wide range of requirements scaling from relatively small energy-efficient microcontrollers to servers and other high-performance computing systems. By not having a fixed vector length known at compile time, the same ISA can be used to address multiple markets without effort from software developers in tailoring the code to each performance / power / area point.

[0053] To achieve the scalable property of the scalable vector ISA, the functionality of the vector instructions of the scalable vector ISA is defined in the architecture with reference to a parameter (e.g., LEN as shown in FIG. 2) indicating the vector length in use (taking into account the maximum vector length supported in hardware and any software-defined limitations using the control register 29), which parameter LEN is unknown at compile time. Thus, execution of the same vector instruction on different systems can produce different results (usually varying with respect to the number of vector elements generated, a subset of which may have the same result value on different platforms, but generally a platform implementing a larger vector length may generate additional vector elements compared to a platform implementing a smaller vector length). A predicate may be used to control which elements are generated in a given instance of the instruction, and may be set on a vector-length agnostic basis, such as by using a comparison instruction to automatically generate the value of the predicate for a particular loop iteration, or by applying some generally defined predicate pattern that can be scaled to different vector lengths. Certain instructions may update loop control parameters, such as an element count value, to track how many vector elements have been processed so far, such that an implementation with a wider vector length may require fewer loop iterations than an implementation with a narrower vector length, such that throughout the loop, both implementations with wider and narrower vector lengths may achieve different levels of performance, although they ultimately achieve the same results.

[0054] Figure 4 shows a working example that shows how the same sequence of instructions can be processed differently on different hardware implementations using different vector lengths. In this example, the code example performs a double precision floating point operation "daxpy" (double precision Ax plus y) to obtain y[i]=a for two arrays of input values ​​x[i], y[i]. *It is to calculate x[i]+y[i], where 0≦i<n. This can be implemented in a vectorized loop using a set of instructions from a scalable vector ISA as follows.

[0055] [Table 1]

[0056] Figure 4 shows the processing of these instructions for one example using a 128-bit vector length and another example using a 256-bit vector length. Variables a and arrays x[] and y[] are data stored in memory. Registers x0~x4 are scalar registers. Register p0 is a predicate register. Registers z0~z2 are vector registers, 128-bit registers in the first example and 256-bit registers in the second example (therefore, predicate register p0 is a longer register in the 256-bit example compared to the 128-bit example). Boxes outlined in solid lines indicate active elements processed or set by a given instruction, and boxes outlined in dashed lines indicate either non-active elements masked by predication or registers not used at all for a given instruction. Note that the numbering of the instructions shown in Figure 4 indicates the program order of the decoded instruction sequence executed by processing circuit 16 (some instructions may be executed multiple times, and since the branch point labels numbered in the above example are not numbered in Figure 4, it is different from the numbering of the compiled code shown above). Nevertheless, the same instruction sequence is shown in Figure 4 as shown above.

[0057] In both the 128-bit and 256-bit examples, the vector instructions scale to the number of vector elements that can fit within the corresponding vector length. In this example, the element size used is 64 bits, so there are two vector elements per vector in the 128-bit example and four vector elements per vector in the 256-bit example. Thus, only two predicate bits of p0 are used in the 128-bit example and only four predicate bits of p0 are used in the 256-bit example (in practice, register p0 may contain a larger number of predicate bits to allow smaller vector element sizes to be supported).

[0058] The whilelt, incd, and b.first instructions are loop control instructions that set a predicate, update a loop count value according to the supported vector length, and conditionally branch back to the beginning of the loop depending on a comparison of the loop count value. The other instructions are load / store or vector processing instructions that operate on some vector elements according to the supported vector length.

[0059] The increment instruction incd increments a loop counter based on the number of vector elements processed in the corresponding loop iteration (e.g., VL / ES, where VL is the vector length and ES is the vector element size). The predicate setting instruction whilelt uses a comparison between the loop counter (i, represented by register x4 in the instruction sequence) and the termination limit (n, represented by register x3, which is loaded from memory by the load instruction in line 3 of the code example above) to set a predicate depending on whether the various incremented versions of the loop counter are less than the limit value (lt). For elements where the incremented loop counter is still less than the limit value, the predicate is set to true, whereas when the incremented loop counter reaches the termination limit, the predicate is set to false (in this example, this occurs for the fourth element processed for instruction 2 in the 256-bit example, but for a two-element vector in the 128-bit example, this limit is not yet reached in the first pass, but only by a subsequent predicate-setting instruction (the whilelt instruction shown on line 14 of the code example above) which is executed to determine that there is yet another vector element to process (see the ninth instruction in decoded program order shown in the 128-bit example of FIG. 4), and therefore the branch instruction (instruction 10 in decoded program order) loops back for another pass. In the next pass, the whilelt instruction (the 16th instruction in decoded program order) determines that all predicates are “false”, at which point the branch instruction does not take the branch and the loop terminates. In contrast, in the 256-bit example, only one pass was needed which masked the effect of the fourth element in each vector register.

[0060] Finally, note that while the result produced by the instruction sequence is the same for both the 128-bit and 256-bit examples (the data stored in memory for array y[] has the same values ​​3, 50, 41, 32 (from highest address to lowest address)), the 128-bit example obtained its result in two loop iterations, while the 256-bit example required only one loop iteration. Thus, the instructions on lines 8-15 of the code example above needed to be decoded and executed twice in the 128-bit example (see instructions 4-17 numbered in the decoded program order of the 128-bit example in FIG. 4).

[0061] Although a scalable vector ISA can be very useful for allowing platform-independent code to be developed that supports a range of different hardware implementations, many software programs in use are nevertheless optimized for non-scalable vector ISAs that support fixed-length vector units, in particular the 128-bit vector unit provided for systems conforming to Arm® Limited's Neon™ non-scalable vector ISA. For backward compatibility, systems that support a scalable vector ISA may also support instructions of the non-scalable vector ISA to ensure that such legacy software can still be executed. However, this means that non-scalable software cannot benefit from the additional performance available in the hardware, even if the hardware supports longer vector lengths.

[0062] It may be desirable for program code written in a non-scalable vector ISA to be redeveloped using instructions of a scalable vector ISA, since it may open up greater performance opportunities by taking advantage of the longer vector lengths available on many hardware implementations of the scalable vector ISA. However, if an attempt is made to rewrite a program written for a non-scalable vector ISA (where the vector length is known at compile time) into program code written for a scalable vector ISA (where the vector length is unknown at compile time), this may require significant effort for the programmer or compiler writer. Since program code in a non-scalable ISA often includes certain optimizations that are selected relying on knowledge of a fixed vector length (e.g., 128 bits) known at compile time, the instructions of the non-scalable vector ISA may not map to scalable vector instructions in a straightforward manner, and this may prevent the use of some such optimizations if it is not possible to know at compile time which vector will be used next, which may in some cases completely prevent the use of vectorized loops in scalable vectorized code.

[0063] For example, the following C code can implement a partial sum reduction (for example, this can be an operation from a digital signal processing application):

[0064] [Table 2]

[0065] In the code above, the result of the multiply-add operation at each iteration is accumulated in acc and stored in state[biquad].y1. After vectorization, each element of the vector used to store the value of state[biquad].y1 should store a partial sum of the accumulation (element 0 should store the value of acc at the 0th iteration, element 1 should store the resulting value of acc after the first two iterations, and so on).

[0066] In a non-scalable vector ISA, this partial sum reduction can be achieved by broadcasting each of the four elements into new vector registers and partially accumulating these four vector registers using the mla (multiply-accumulate) instruction, as shown below:

[0067] [Table 3]

[0068] Here, the first duplicate (dup) instruction sets all vector elements in vector register v17 equal to element 0 of vector register v16, the second dup instruction sets all vector elements in vector register v18 equal to element 1 of vector register v16, and so on. There is one dup for each vector element in register v16. Because the vector length in a non-scalable vector ISA is known at compile time, the compiler can work out how many dup instructions to include given the size of the vector elements (in this example, four based on four 32-bit elements per 128-bit vector).

[0069] However, in a scalable vector ISA, this partial sum reduction cannot be performed in the same way because the vector length is unknown at compile time, and therefore the compiler does not know how many dup instructions should be included. This can prevent successful vectorization of scalar loops defined in C code, and can force scalable vector code to rely on scalar loops, which cannot realize the benefits of vectorization.

[0070] This is just one example of a software optimization that may rely on compile-time knowledge of vector lengths. Other examples may include loop unrolling, in which a certain number of original loop iterations are mapped to a smaller number of loop iterations, each with a larger number of instructions, thereby reducing the number of loop control instructions that need to be executed, such that one iteration of the "unrolled" loop corresponds to multiple iterations of the original loop, and software pipelining, in which a compiler reorders the execution of a loop's instructions so that some instructions of later loop iterations may be executed before instructions from earlier loop iterations.

[0071] Figure 5 shows a schematic of an example of a technique that can help with this problem. A vector with a scalable vector length (unknown at compile time) is logically treated as consisting of a scalable number of subvectors, each with equal subvector length. The subvector length is known at compile time. For example, each subvector can be a fixed size (e.g., 128 bits) that corresponds to a fixed vector length in a non-scalable vector architecture such as Neon™, or can simply be any fixed size defined in the scalable vector ISA (regardless of any correspondence with existing non-scalable vector ISAs). Alternatively, in some implementations of a scalable vector ISA, there may be the ability for software to specify the subvector length among two or more options, such that the subvector length is known at compile time (software defined), but can vary for different instances of an instruction that utilizes this subvector approach. Since the subvector length is known at compile time, but the overall vector length is not, the total number of subvectors that fit within a vector is also not known at compile time and may be scalable depending on the particular vector length selected for the particular hardware implementation executing the instruction designed to support the subvector approach. Each subvector has a variable number of vector elements, and the size of each vector element may be variable and may be selected by software from some options (e.g., 8, 16, 32, or 64 bits). Thus, the size and number of vector elements per subvector may be known at compile time, but the number of effect elements in the entire vector may be variable and unknown at compile time. The subvector length may be independent of both the overall vector length used by the hardware and the vector element size specified for a given instruction.

[0072] In this approach, because the subvector lengths are known, it becomes much easier to convert code compiled for use with a non-scalable vector ISA (assuming a fixed vector length) to code compiled for use with a scalable vector ISA (assuming subvectors of known subvector length, but using subvector support instructions that allow for scalable overall vector lengths). Also, even when directly compiling a scalable vector ISA that supports subvector support instructions (without starting from non-scalable vectorized code), the subvector support instructions can be useful in allowing software performance improvement techniques such as those described above to be applied that would not otherwise be possible for scalable vector instructions that operate at a per-element or full-vector granularity on scalable-length vectors, rather than at the granularity of a fixed-size subvector.

[0073] Thus, as described in the examples below, a number of subvector support instructions may be defined that control processing circuitry 16 (e.g., vector processing unit 22 and / or load / store unit 28) to perform operations at the granularity of a subvector rather than at the granularity of individual elements or at the granularity of an entire vector. Operations performed at the granularity of a subvector may be performed in parallel, sequentially, partially parallel and partially sequentially, or in a pipelined manner in response to a single instance of execution of a subvector support instruction (thus, it is not necessary to use a predicate value set between each instance of executing a subvector support instruction to partition a vector into subvectors, with each subvector being processed in a separate pass through the subvector support instruction).

[0074] It is not necessary to provide sub-vector support instructions corresponding to all vector operations that may be desired to be performed on vector operands. Many operations (e.g., addition or multiplication) may be applied at element-by-element granularity and therefore can provide correct results even when applied to operands designed to support a vector approach of vectors, as shown in FIG. 5. Thus, sub-vector granularity instructions may not be possible for certain types of processing operations. However, for some types of processing operations, such as substitution or reduction that are typically applied across an entire vector, it may be useful to define sub-vector support instructions that apply the corresponding operation at sub-vector granularity to give a different processing result. Similarly, it may be useful to implement certain types of load / store instructions and loop control or predicate setting instructions that operate at sub-vector granularity (e.g., by setting or reading predicate bits at sub-vector granularity rather than individual elements). By including such instructions in the scalable vector ISA, this can make it much easier to redevelop program code that was previously optimized for a non-scalable vector ISA to use the scalable vector ISA, allowing that code to achieve better performance when executed on high-end processor implementations that use the larger vector lengths supported by the scalable vector ISA.

[0075] FIG. 6 shows a flow diagram illustrating the processing of a subvector support instruction. In step 100, an instruction decoder 10 supporting a scalable vector ISA decodes the next instruction of the program being executed. In step 102, the instruction decoder 10 determines whether the decoded instruction is a subvector support instruction. If not, in step 104, the instruction decoder 10 controls the processing circuitry 16 to perform processing operations as indicated by other types of instructions. If the instruction decoded by the instruction decoder 10 is a subvector support instruction, in step 106, the instruction decoder 10 controls the processing circuitry 16 to perform operations at subvector granularity for a given vector that is treated as including two or more subvectors, each containing a particular number of vector elements, each subvector having an equal subvector length. The subvector length is known at compile time. However, the number of subvectors processed by the instruction is not known at compile time because the total vector length is not known at compile time.

[0076] 7-11 show various examples of subvector support permute instructions for applying a permute operation within each subvector of a vector operand. In each case, both the input operands and the result of the instruction are vectors that are considered to be logically divided into a number of subvectors, each having a subvector length (e.g., 128 bits) that is fixed in the architecture or known at compile time. The overall length of the vector operands and the result is scalable and unknown at compile time. For ease of explanation, all examples described below show examples with 32-bit elements, such that there are four vector elements per subvector, but it will be understood that other examples may use different element sizes. For each permute instruction, all elements in a given subvector of the result are set to a permute of bits selected from corresponding subvectors of one or more operand vectors. It is not possible to set a given element in a given subvector of the result according to bits selected from elements in other subvectors of the operand vector that are in different relative subvector positions compared to the given subvector of the result. Thus, the corresponding permute operation is performed multiple times at subvector granularity.

[0077] FIG. 7 shows a first example of a duplicate permute instruction, DUPQ, where the permute applied to a given subvector of the result Zd is to duplicate selected elements of the corresponding subvector of the operand vector Zn into each of the vector elements of the given subvector of the result. Which elements are duplicated is indicated by an immediate index value, #imm, which defines the element position relative to the start of the subvector. For example, in FIG. 7, the immediate value has a value of 1, indicating that element 1 of each subvector of the operand Zn is duplicated into every vector element position in the corresponding subvector of the result Zd. Thus, value A1 is copied into the first four element positions of Zd, value B1 is copied into the next four element positions, value C1 is copied into the next four element positions, and so on (since in this example each subvector contains four vector elements). The number of subvectors processed using the permute operation depends on the particular vector length used by the hardware, as allowed by the Scalable Vector ISA. Nevertheless, because the number of instances of a given vector element to be replicated (e.g., 4 in this case) is known at compile time, code optimizations such as those shown above for partial sum reduction can still be used to make it easier to adopt a scalable vector ISA while still allowing code optimizations that rely on knowledge of the (sub)vector length at compile time.

[0078] The bottom part of Figure 7 shows the corresponding copy permute when applied at the granularity of a whole vector, as might be expected for a traditional vector instruction. In this case, the immediate index value defines the vector element position relative to the start of the vector operand Zn, and the vector element at this position in the vector operand Zn is copied to every element of the result vector Zd. This clearly demonstrates the difference in results achieved using the sub-vector support variant of the permute instruction compared to the full-vector permute instruction.

[0079] FIG. 8 shows another example of the subvector support permute instruction EXTQ. In this example, the permute applied to each subvector is an extract permute that sets the lower portion of each subvector of the result Zdn' to the upper bits of the corresponding subvector of the first vector operand Zdn and sets the upper portion of each subvector to the lower bits of the corresponding subvector of the second vector operand Zm. In this example, the encoding is destructive and the result is written to the same register Zdn used to provide the first vector operand. Other examples can use constructive encoding that defines a further vector register to provide the first vector operand apart from the destination register used to store the result. The immediate index value defines the size of the portion extracted from the two operand vectors (e.g., the index may define a position relative to the start of the subvector from which the upper portion is extracted for the first operand that is copied to the lower bits of the corresponding subvector of the result, and the remaining bits of the corresponding subvector of the result may be filled with the least significant selected bits of the second operand). In this particular example, the immediate value is the bit [127-(imm * 8):0] is the bit [127:imm * 8] and bits [127:128-(imm * 8)] is the bit [(imm * The bit positions are selected with byte granularity (units of 8 bits) so that the bit positions are set equal to [[x,y,y]-1:0]. It will be appreciated that in other examples, the immediate value can be defined to select in increments of another unit other than 8 bits. Although this permutation is applied separately with subvector granularity, each subvector permutation uses the same immediate value that indicates the boundary between the portions extracted from corresponding subvectors of the two operands. Again, Figure 8 shows how applying this operation with subvector granularity differs from the overall vector permutation.

[0080] Figure 9 shows another example of a subvector support permutation instruction TBLQ where a table lookup permutation is applied per subvector. In this example, the first vector operand Zm defines a set of index values ​​indicating which elements of a given subvector of the second vector operand Zn are copied to the corresponding element location in the corresponding subvector of the result vector Zd. The index values ​​are defined relative to the start of the corresponding subvector, not relative to the whole vector. Thus, for the second subvector (corresponding to values ​​B0, B1, B2, B3 in the second operand Zn), element indices 3, 3, 1, 2 select values ​​B3, B3, B1, B2 (B3 is placed in the least significant element of the subvector and B2 is placed in the most significant element) for the corresponding vector elements of the corresponding subvector in the result. If a particular index value has a value greater than the maximum vector element index in a given subvector, then a 0 is written to the corresponding position in the result vector Zd (see, e.g., example index value 6 for the most significant vector element position in the third subvector, which is greater than the most significant index 3 for the four elements (labeled 0 through 3) in a given subvector, and thus a 0 is written to the corresponding position in the result Zd). Again, this approach to permutation by subvector differs from whole-vector permutation, where index values ​​are defined relative to the entire vector, and thus applying whole-vector permutation to the same two operands Zm, Zn shown in FIG. 9 gives different results to operations performed at subvector granularity, as shown in the lower portion of FIG. 9.

[0081] Figure 10 shows another example of the subvector support permutation instruction ZIPQ1, where the permutation applied to a given subvector is to interleave elements from the lower halves of the corresponding subvectors of the two vector operands Zn, Zm within the given subvector of the result vector Zd. This permutation is performed for each of the subvectors, again giving a different result than if a similar permutation were performed at the whole vector granularity, as shown at the bottom of Figure 10. While Figure 10 shows an example of interleaving elements from the lower half of each subvector, the corresponding instruction ZIPQ2 could also be defined to interleave elements from the upper half of each subvector instead.

[0082] Figure 11 shows another example of the subvector support permutation instruction UZPQ1, where the permutation applied to a given subvector is to concatenate the even-numbered vector elements of the corresponding subvectors of the two vector operands Zn, Zm in the corresponding subvector of the result vector Zd. Again, this results in a result with elements in a different order than would be achieved if a similar permutation were applied at the granularity of the whole vector. An alternative version of this instruction, UZPQ2, can concatenate odd-numbered elements instead of the even-numbered elements.

[0083] FIG. 12 illustrates an example of an inter-subvector reduction instruction that performs reduction operations at subvector granularity, where each reduction operation reduces multiple elements of an operand vector to a single data value in a result vector. This example illustrates a predicated instruction in which the instruction specifies a predicate value Pg associated with the operand vector Zn to indicate which elements are masked. The masked elements do not contribute to the reduced result. In this example, the reduction is performed across the correspondingly numbered elements in each subvector, and the reduction operator applied in this example is addition. Thus, element 0 of the result vector Zd is set to the sum of any unmasked elements at position 0 in each of the subvectors of the vector operand Zn, element 1 of the result vector Zd is set to the sum of any unmasked elements at position 1 in each of the subvectors of the vector operand Zn, and similarly for other element positions (if all of the elements at a given position in each subvector are masked, the corresponding element of the result is set to 0). Because the reduction operation reduces the total number of elements, the remaining elements of the result vector Zd that are not filled with the reduced result can be filled with zeros.

[0084] While FIG. 12 shows an example with additive reduction, similar reduction operations at sub-vector granularity may be performed for other operations such as, for example, AND, exclusive OR (EOR), floating-point addition (FADD), floating-point maximum (FMAX, which determines the maximum of a set of floating-point numbers), floating-point minimum (FMIN, which determines the minimum of a set of floating-point numbers), OR, signed maximum (SMAX, which determines the maximum of a set of signed integers), signed minimum (SMIN, which determines the minimum of a set of signed integers), unsigned maximum (UMAX, which determines the maximum of a set of unsigned integers), and unsigned minimum (UMIN, which determines the minimum of a set of unsigned integers).

[0085] It is also possible to provide an inter-subvector reduction instruction, as shown in FIG. 13, which performs a reduction within each subvector and reduces all elements of a given subvector of the input operand Zm to a single data value in the result vector Zd'. That single element may be sign-extended or zero-extended to fill the corresponding subvector of the result vector Zd'. As shown in FIG. 13, the reduction operation within a given subvector may also depend on an element extracted from a given element position (e.g., element position 0) in the corresponding subvector of the second vector operand Zd. Again, a predicate may be applied based on a predicate value Pg that defines the active or inactive elements of the Zm operand (an additional element taken from Zd may always be considered active, and this element may be used as an accumulator value that keeps track of the results of a series of previous reductions, which is why it may be useful to use a destructive encoding as shown in FIG. 13, where the result is written to the same register Zd used to provide the accumulator value).

[0086] Whether the reduction is implemented across corresponding elements of each subvector as shown in Figure 12, or for elements within a single subvector as shown in Figure 13, the reduction is an operation performed at subvector granularity and differs from the results achieved if the corresponding operation was performed at full vector granularity (reducing all elements of the vector to a single data value) or if the same reduction operation was implemented using an element-wise vector add instruction (or a similar element-wise instruction for other reduction operations) included in a loop or sequence of instructions to add or otherwise reduce elements at corresponding positions in the set of vectors. Subvector-based approaches can be useful to simplify the mapping of non-scalable vectorized code, which may assume a fixed vector length, into scalable vectorized code, where the subvectors correspond to that fixed vector length and the overall vector length is scalable according to the design choices of the hardware designer.

[0087] FIG. 14 illustrates an example of a sub-vector support load / store instruction that may be useful in supporting a vector-of-vector approach. FIG. 14 illustrates a contiguous load / store instruction in which a block of data loaded from memory to at least one vector register or stored to memory from at least one vector register corresponds to a contiguous block of data in a memory address space. Although FIG. 14 illustrates a load / store instruction that loads / stores a single vector register, other load / store instructions can be provided to support loading / storing multiple vector registers. Unlike other forms of vector load / store instructions, the sub-vector support vector load / store treats the sub-vector length, rather than the individual vector elements within the sub-vector, as the basic unit of vector load / store operations. Thus, the predicate value Pg used to indicate which portion of a vector register is loaded or stored is applied at the granularity of the sub-vector, rather than the granularity of the individual elements. The subvectors corresponding to predicate bits that are zero may be masked such that, for a load instruction, the corresponding subvector of the destination register Zt is not set to the value of the corresponding subvector loaded from memory, and for a store instruction, the data in the corresponding subvector of the source register Zt is not written to the corresponding addressed location in memory.

[0088] Similarly, Figure 15 illustrates a gather-scatter form of the subvector support load / store instructions that can load or store some subvectors from a non-contiguous block of addresses in memory to or from a vector register Zt. In this example, vector register Zm provides index values ​​that are used to determine the block of addresses that corresponds to a given subvector. Each index points to a multiple of a block of data whose size corresponds to the subvector length. Again, the predicate is applied at the subvector granularity.

[0089] It will be appreciated that the addressing schemes shown in Figures 14 and 15 are only examples, and other examples may use different techniques to determine the addresses of the sub-vectors to be loaded into or stored from the vector register. For example, for other gather-scatter instructions, the vector operand used to calculate the addresses for the load / store operations on each sub-vector may be used as a vector of base addresses rather than a vector of offsets. In general, the sub-vector supporting load / store instructions may be any load / store instructions that operate at the granularity of a sub-vector.

[0090] 16 shows an example of a predicate setting instruction that may be used to set a predicate corresponding to a given vector at sub-vector granularity. In this example, the predicate setting instruction is a comparison instruction that sets a predicate bit Pi corresponding to sub-vector i to "true" (1) if the comparison of "Rn"+i to "Rm" is true, where "Rn" is the value stored in the first scalar register Rn and "Rm" is the value stored in the second scalar register Rm. Different variants of the instruction may be provided that correspond to different comparison conditions, such as LO (unsigned lower) (lower than unsigned), LS (unsigned lower or same) (unsigned less than or equal), LT (signed less than), LE (signed less than or equal), HI (unsigned higher) (higher than unsigned), HS (unsigned higher or same) (unsigned greater than or equal), GT (signed greater than) (greater than signed), or GE (signed greater than or equal). This instruction is similar to the whilelt instruction shown in the scalable code example of Figure 4, but sets the predicate at sub-vector granularity rather than vector element granularity, which can be useful to emulate the behavior of code that masks the effect of an entire vector in non-scalable vectorized examples.

[0091] FIG. 17 shows a second example of a subvector support predicate setting instruction, where again the predicate value is set at subvector granularity, but in this example the instruction specifies a certain predefined pattern to be applied at subvector granularity (e.g., the predicate bits that are set / cleared according to the applied pattern are the predicate bits corresponding to the start of each subvector). This may differ from the corresponding predicate setting instruction, which may apply a pattern at the granularity of an individual vector element. For example, the predicate pattern may be to set a specified number of predicted bits as active, to set one out of every N predicates as active (where N is a value of 2, 3, 4, etc.), or to set some predicate bits as active that correspond to the largest power of 2 that fits the predicate value when considering the hardware's implemented vector length.

[0092] Figure 18 shows an example of a subvector support increment instruction that specifies a pattern identifier that identifies a given predicate pattern and that, when applied at subvector granularity, controls the processing circuit 16 to increment the scalar operand Xdn by a number corresponding to the number of active subvectors indicated by the specified predicate pattern. Alternatively, a corresponding instruction may be provided to decrement the operand by the number of active subvectors indicated for the predicate pattern. The predicate pattern may be defined in a manner corresponding to the pattern defined for the instruction of Figure 17. This instruction may be useful to control the increment or decrement of a loop count variable that is used to track whether it is still necessary to continue with further loop iterations or whether it is possible to terminate the loop because all required subvectors have been processed.

[0093] All of the instructions described above can help make it easier to adapt code written for fixed-length vector architectures to scalable vector architectures. It will be understood that not all of these instructions need to be implemented in a given implementation. Similar sub-vector granularity instructions can also be defined for other operations.

[0094] In summary, to enable a more straightforward transition for software developers moving from a non-scalable vector length defined architecture such as Neon™ to a scalable vector length agnostic architecture such as SVE, the above example adds sub-vector (e.g., quadword (128-bit) sized) elements and treats each sub-vector as an element in the scalable architecture. In doing so, a vector-in-vector style is formed to vectorize each fixed length vector of the non-scalable architecture using the vector length agnostic style of the scalable architecture. This allows the non-scalable code to be mapped to the scalable code with a rough one-to-one mapping of instructions so that vectorization can take advantage of the longer and more flexible vector lengths allowed in the scalable architecture and still retain code optimizations introduced for the non-scalable architecture that rely on the assumption of vector lengths being known at compile time.

[0095] FIG. 19 illustrates a simulator implementation that may be used. While the above embodiments implement the invention in terms of apparatus and methods for operating specific processing hardware that supports the technique, it is also possible to provide an instruction execution environment according to the embodiments described herein that is implemented by the use of a computer program. Such a computer program is often referred to as a simulator insofar as the computer program provides a software-based implementation of a hardware architecture. Various simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 330 that optionally runs a host operating system 320 that supports the simulator program 310. In some arrangements, there may be multiple layers of simulation between the hardware and the instruction execution environment provided, and / or there may be multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at reasonable speeds, but such an approach may be justified 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 may provide an instruction execution environment that has additional functionality not supported by the host processor hardware, or that is typically associated with a different hardware architecture. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques", Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0096] Although embodiments have been described above with reference to particular hardware constructs or characteristics, equivalent functionality may be provided in the simulated embodiments by suitable software constructs or features. For example, particular circuits may be implemented as computer program logic in the simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented in the simulated embodiments as software data structures stored in host storage (e.g., memory or registers) of the host processor 330. In configurations in which one or more of the hardware elements referenced in the preceding embodiments are present on the host hardware (e.g., the host processor 330), some simulated embodiments may utilize the host hardware where suitable.

[0097] Simulator program 310 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (an instruction execution environment) to target code 300 (which may include applications, operating systems, and hypervisors) that is the same as the interface of the hardware architecture being modeled by simulator program 310. Thus, program instructions of target code 300 may be executed from within the instruction execution environment using simulator program 310, such that a host computer 330 that does not actually have the hardware capabilities of device 2 discussed above (e.g., instruction decoder 10 and processing circuitry 16 that support the sub-vector support instructions discussed above) may emulate those capabilities.

[0098] Thus, the simulator program 310 may have instruction decode program logic 312 for decoding instructions of the target code 300 and mapping them to a corresponding set of instructions in the native instruction set of the host device 330. The instruction decode program logic 312 includes sub-vector support instruction decode program logic 313 for decoding the sub-vector support instructions described above. The register emulate program logic 314 maps register accesses requested by the target code to accesses to corresponding data structures maintained on the host hardware of the host device 330, such as by accessing data in registers or memory of the host device 330. The memory manager program logic 316 implements address translation, page table walks, and access permission checks to simulate accesses by the target code 300 to the simulated address space in a manner corresponding to the MMU 36 described in the hardware implemented embodiment above. Memory address space simulate 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 target program code 300 software to host virtual addresses used to access host memory of host processor 330. These host virtual addresses may themselves be translated to host physical addresses using standard address translation mechanisms supported by the host (the translation of host virtual addresses to host physical addresses is outside the scope of control by simulator program 310).

[0099] In this application, the term "configured to..." is used to mean that an element of an apparatus has a configuration that is capable of performing a defined operation. In this context, "configuration" refers to a manner of arrangement or interconnection of hardware or software. For example, an apparatus may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not imply that an apparatus element needs to be modified in any way to provide the defined operation.

[0100] Although exemplary embodiments of the present invention are described in detail herein with reference to the accompanying drawings, it will be understood that the invention is not limited to these precise embodiments, and that various changes and modifications can be made to the embodiments by those skilled in the art without departing from the scope of the present invention as defined by the appended claims.

Claims

1. 1. An apparatus comprising: a processing circuit for performing data processing; an instruction decode circuit for controlling said processing circuitry to perform said data processing in response to decoding a program instruction defined according to a scalable vector instruction set architecture that supports vector instructions operating on vectors of scalable vector lengths, so as to enable the same instruction sequence to be executed on devices having hardware that supports different maximum vector lengths; the instruction decode circuitry and the processing circuitry are configured to support subvector support instructions that treat a given vector as including multiple subvectors, each subvector including multiple vector elements, each subvector having an equal subvector length; In response to the subvector support instruction, the instruction decode circuitry is configured to control the processing circuitry to perform operations for the given vector at subvector granularity.

2. 2. The apparatus of claim 1, wherein each subvector has a subvector length that is known at compile time for a given sequence of instructions executed using the subvector support instructions.

3. 3. The apparatus of claim 1, wherein the number of sub-vectors the given vector contains is unknown at the time the given sequence of instructions is compiled.

4. 3. The apparatus of claim 1, wherein in response to the subvector support instruction, the instruction decode circuitry is configured to control the processing circuitry to process each of the subvectors in response to the same instance of executing the subvector support instruction.

5. 3. The apparatus of claim 1, wherein each sub-vector has an architecturally defined fixed-size sub-vector length that is independent of the vector length used for the given vector.

6. 6. The apparatus of claim 5, wherein the architecturally defined fixed size corresponds to an architecturally defined maximum vector length specified for vector instructions processed according to a given non-scalable vector instruction set architecture.

7. The apparatus of claim 5 , wherein the architecturally defined fixed size is 128 bits.

8. 3. The apparatus of claim 1, wherein each vector element of each sub-vector has a variable element size, and the sub-vector length is independent of which element size is used for each vector element within each sub-vector.

9. 3. The apparatus of claim 1, wherein for at least one subvector support instruction, the operations performed at subvector granularity are operations performed for each subvector on vector elements within that subvector independently of elements in other subvectors.

10. 3. The apparatus of claim 1, wherein for at least one subvector support instruction, the operations performed at subvector granularity are, for each element position within a subvector, an operation performed on a respective vector element at that element position within each of the plurality of subvectors.

11. 3. The apparatus of claim 1, wherein for at least one subvector support instruction, the operation performed at subvector granularity is an operation to set selected predicate bits of a predicate value or perform an operation accordingly, the selected predicate bits being predicate bits corresponding to a subvector-sized portion of a vector.

12. 3. The apparatus of claim 1, wherein in response to a subvector support permute instruction, the instruction decoder is configured to control the processing circuitry to, for each subvector of a vector result, set the subvector to a permute of one or more vector elements selected from among vector elements in correspondingly located subvectors of at least one vector operand.

13. 3. The apparatus of claim 1, wherein in response to a subvector support reduce instruction, the instruction decoder is configured to control the processing circuitry to perform at least one reduce operation at subvector granularity, each reduce operation reducing multiple vector elements of an operand vector to a single data value in a result.

14. 14. The apparatus of claim 13, wherein for an inter-subvector subvector support reduce instruction, for each reduce operation, the plurality of vector elements includes the respective vector elements in a corresponding subvector of the operand vector.

15. 14. The apparatus of claim 13, wherein for an inter-subvector subvector support reduce instruction, for each reduce operation, the plurality of vector elements includes the vector elements at corresponding element positions in a plurality of subvectors of the operand vector.

16. 3. The apparatus of claim 1, wherein in response to a sub-vector support load / store instruction, the instruction decoder is configured to control the processing circuitry to perform load / store operations to transfer one or more sub-vectors at sub-vector granularity between a memory system and at least one vector register.

17. the sub-vector support load / store instruction is a predicated instruction associated with a predicate value; 17. The apparatus of claim 16, wherein in response to the sub-vector support load / store instruction, the instruction decoder is configured to control the processing circuitry to control whether each transfer of the one or more sub-vectors is performed or masked based on a predicate bit selected from a predicate value at sub-vector granularity.

18. 3. The apparatus of claim 1, wherein in response to a subvector support increment / decrement instruction, the instruction decoder is configured to control the processing circuitry to increment or decrement an operand value based on how many subvector-sized portions of a vector are indicated as active by bits of a predicate value selected from a predicate value at subvector granularity.

19. The prefix value is a predicate value specified as a predicate operand by said subvector support increment / decrement instruction; a predicate value implied by a predicate pattern identifier specified by the subvector support increment / decrement instruction, the predicate pattern identifier specifying a predetermined pattern of predicate bits at subvector granularity.

20. 3. The apparatus of claim 1, wherein in response to a subvector support predicate setting instruction, the instruction decoder is configured to control the processing circuitry to perform a predicate setting operation to set bits of a predicate value at subvector granularity to indicate which subvectors of a vector are active.

21. The predicate setting operation is a predicate pattern identifier specifying a predetermined pattern of predicate bits to be applied at sub-vector granularity; a sub-vector granularity compare operation based on a comparison of a first operand and a second operand.

22. 1. A method comprising: using an instruction decode circuitry to decode program instructions defined in accordance with a scalable vector instruction set architecture that supports vector instructions operating on vectors of scalable vector lengths to allow the same instruction sequence to be executed on devices having hardware that supports different maximum vector lengths; controlling a processing circuit to perform data processing in response to decoding the program instructions; the instruction decode circuitry and the processing circuitry support subvector support instructions that treat a given vector as including multiple subvectors, each subvector including multiple vector elements, each subvector having an equal subvector length; In response to the subvector support instruction, the instruction decode circuitry controls the processing circuitry to perform operations for the given vector at subvector granularity.

23. 1. A computer program for controlling a host data processing apparatus to provide an instruction execution environment for execution of target code, said computer program comprising: instruction decoding program logic for decoding instructions of said target code in response to said instructions of said target code to control said host data processing apparatus to perform data processing; the instruction decode program logic supports decoding of program instructions defined according to a scalable vector instruction set architecture that supports vector instructions operating on vectors of scalable vector lengths to allow the same instruction sequence to be executed on devices having hardware that supports different maximum vector lengths; the instruction decode program logic includes subvector support instruction decode program logic for decoding subvector support instructions that treat a given vector as including a plurality of subvectors, each subvector including a plurality of vector elements, each subvector having an equal subvector length; A computer program product, wherein in response to the sub-vector support instruction, the instruction decode program logic is configured to control the host data processing apparatus to perform operations for the given vector at sub-vector granularity.

24. A storage medium storing the computer program according to claim 23.

Images