(→Overview: I and F stand for int and float) |
|||
(2 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
{{arm title|Helium (MVE)}}{{arm isa main}} | {{arm title|Helium (MVE)}}{{arm isa main}} | ||
'''Helium''' or '''M-Profile Vector Extension''' ('''MVE''') is an optional vector architectural extension introduced as part of the {{arm|ARMv8.1-M}} architecture. Implementations that include MVE also include the DSP extension. | '''Helium''' or '''M-Profile Vector Extension''' ('''MVE''') is an optional vector architectural extension introduced as part of the {{arm|ARMv8.1-M}} architecture. Implementations that include MVE also include the DSP extension. | ||
+ | |||
+ | == Etymology == | ||
+ | Arm's main vector extension is called ''{{\\|Neon}}''. Designed to be a lighter vector extension, MVE was branded ''Helium'' which is another noble gas with a lighter atomic weight. | ||
== Overview == | == Overview == | ||
Line 7: | Line 10: | ||
MVE instructions comes in two distinct flavors: '''MVE-I''' and '''MVE-F''': | MVE instructions comes in two distinct flavors: '''MVE-I''' and '''MVE-F''': | ||
− | * '''MVE-I''' operates on 32-bit, 16-bit, and 8-bit data types | + | * '''MVE-I''' operates on 32-bit, 16-bit, and 8-bit integer data types |
* '''MVE-F''' operates on [[half-precision]] and [[single-precision]] [[floating-point]] values | * '''MVE-F''' operates on [[half-precision]] and [[single-precision]] [[floating-point]] values | ||
Line 13: | Line 16: | ||
=== Registers === | === Registers === | ||
− | MVE defines eight vector registers: '''Q0''' .. '''Q7'''. In order to maximize area reuse, the eight vector registers are defined as aliases onto the Floating-point Extension register file. There are many vector instructions that can use scalar arguments from the general-purpose register file. This was done in order to reduce pressure on the vector register file. | + | MVE defines eight vector registers: '''Q0''' .. '''Q7'''. These registers are all 128-bit wide. In order to maximize area reuse, the eight vector registers are defined as aliases onto the Floating-point Extension register file. There are many vector instructions that can use scalar arguments from the general-purpose register file. This was done in order to reduce pressure on the vector register file. |
:[[File:helium vector reg file alias.svg|500px]] | :[[File:helium vector reg file alias.svg|500px]] | ||
Line 32: | Line 35: | ||
It's worth noting that the number of beats per cycle is not required to be a constant and is allowed to change at runtime. One important rule associated with a dual-beat system is that they may overlap. In other words, an implementation may execute the last two beats of an operation along with the first two beats of the next vector instruction. | It's worth noting that the number of beats per cycle is not required to be a constant and is allowed to change at runtime. One important rule associated with a dual-beat system is that they may overlap. In other words, an implementation may execute the last two beats of an operation along with the first two beats of the next vector instruction. | ||
+ | |||
+ | == Features == | ||
=== Predication/conditional execution === | === Predication/conditional execution === |
Latest revision as of 18:09, 2 October 2020
ARM ISA | |
General | |
Variants | |
Extensions | |
Topics | |
Versions(all) | |
Helium or M-Profile Vector Extension (MVE) is an optional vector architectural extension introduced as part of the ARMv8.1-M architecture. Implementations that include MVE also include the DSP extension.
Contents
Etymology[edit]
Arm's main vector extension is called Neon. Designed to be a lighter vector extension, MVE was branded Helium which is another noble gas with a lighter atomic weight.
Overview[edit]
The M-Profile Vector Extension (MVE) is a vector architectural extension introduced by Arm as part of the ARMv8.1-M architecture. For Arm Cortex-M processors, MVE goes by the brand name Helium. The extension is optional and heavily repurposes the FPU extension in order to maximize the implementation area and power. MVE was introduced in order to enable more efficient DSP-like operations on the Cortex-M family of cores.
MVE instructions comes in two distinct flavors: MVE-I and MVE-F:
- MVE-I operates on 32-bit, 16-bit, and 8-bit integer data types
- MVE-F operates on half-precision and single-precision floating-point values
All vector instructions operate on a fixed vector width of 128 bits. It's worth pointing out that MVE-I instructions can be implemented with or without the MVE-F scalar floating-point extension.
Registers[edit]
MVE defines eight vector registers: Q0 .. Q7. These registers are all 128-bit wide. In order to maximize area reuse, the eight vector registers are defined as aliases onto the Floating-point Extension register file. There are many vector instructions that can use scalar arguments from the general-purpose register file. This was done in order to reduce pressure on the vector register file.
Lanes and beats[edit]
MVE operations are divided orthogonally in two ways: lanes and beats.
- Lane a portion of a vector register or operation
- Beat a quarter (¼) of an MVE vector operation
A lane refers to the width of the operation to be performed. For example, when working on 8-bit integers, instructions will have 8-bit lane numbers. A beat refers to a quarter of an MVE vector operation. Since vector lengths are 128-bit wide, one beat is a function of the lane width. For example, when working with 32-bit integers, a beat performs one lane operations whereas when working with an 8-bit lane size, a beat performs a four-lane operation.
The purpose of lanes and beats is to allow implementations to make the right compromises in terms of power, performance, and area. It is up to the implementation to define how many beats are executed each clock cycle. The number of beats that are executed at once describes how much of the architectural state is updated each time. Systems are classified by this number:
- Single-beat system: one beat each clock
- Dual-beat system: two beats each clock
- Quad-beat system: four beats each clock
It's worth noting that the number of beats per cycle is not required to be a constant and is allowed to change at runtime. One important rule associated with a dual-beat system is that they may overlap. In other words, an implementation may execute the last two beats of an operation along with the first two beats of the next vector instruction.
Features[edit]
Predication/conditional execution[edit]
MVE supports lane predictions, allowing each lane within a vector operation to be independently masked.
- Loop tail predication - works with hardware loops - offers the ability to eliminate the need for special tail handling in the event where the number of elements being operated on is not a multiple of the lane size. It does this by iterating over the number of elements that need to be processed and on the final iteration, the remaining elements count determines the number of vector lanes to be masked.
- VPT prediction - works on a vector predication (VPT) block - offers the ability to mask a whole block of (1-4) instructions based on predication conditions. Instructions within the VPT block works with the defined condition or its inverse, allowing instructions from both the 'then' (T decorator) and 'else' (E decorator) parts of an if statement to grouped together within a single VPT block.
Both predictions can be used together. In that situation, the two predictions operate separately and the resulting prediction flags from each are ANDed together. In other words, when both predictions are used, a vector operation is executed on lanes where both predictions conditions are determined to be true.
Instruction | Mask | # Instruction | Instruction decorator | |||
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
VPT |
0b1000 | 1 | T | - | - | - |
VPTT |
0b0100 | 2 | T | T | - | - |
VPTE |
0b1100 | 2 | T | E | - | - |
VPTTT |
0b0010 | 3 | T | T | T | - |
VPTTE |
0b0110 | 3 | T | T | E | - |
VPTEE |
0b1010 | 3 | T | E | E | - |
VPTET |
0b1110 | 3 | T | E | T | - |
VPTTTT |
0b0001 | 4 | T | T | T | T |
VPTTTE |
0b0011 | 4 | T | T | T | E |
VPTTEE |
0b0101 | 4 | T | T | E | E |
VPTTET |
0b0111 | 4 | T | T | E | T |
VPTEEE |
0b1001 | 4 | T | E | E | E |
VPTEET |
0b1011 | 4 | T | E | E | T |
VPTETT |
0b1101 | 4 | T | E | T | T |
VPTETE |
0b1111 | 4 | T | E | T | E |
same encoding applies to VPST
|
Load/Stores[edit]
Interleaving/Deinterleaving[edit]
MVE supports interleaving data streams with strides of 2 and 4. They are done using the VLD{2,4}x
and VST{2,4}x
instructions. The pairs come in variants indicating which part of each register they store or load from. By executing each of the variants, the full set of registers is then stored or loaded from memory.
Scatter/Gather[edit]
MVE supports scatter and gather. They are done using the VSTR{B, H, W, D}
and VLDR{B, H, W, D}
instructions.
bibliography[edit]
- ARMv8-M Architecture Reference Manual, Chapter B5. Vector Extension.
- Arm. personal communication. February 2020.