| Latest revision |
Your text |
| 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 10: |
Line 7: |
| | 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 integer data types | + | * '''MVE-I''' operates on 32-bit, 16-bit, and 8-bit 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 |
| | | | |
| | 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. | | 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 ===
| |
| − | 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]]
| |
| − |
| |
| − | === Lanes and beats ===
| |
| − | 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 ==
| |
| − |
| |
| − | === Predication/conditional execution ===
| |
| − | MVE supports lane predictions, allowing each lane within a vector operation to be independently masked.
| |
| − |
| |
| − | * '''Loop tail predication''' - works with {{arm|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.
| |
| − |
| |
| − | {| class="wikitable collapsible collapsed"
| |
| − | |-
| |
| − | ! rowspan="2" | Instruction !! rowspan="2" | Mask !! rowspan="2" | # Instruction !! colspan="4" | Instruction decorator
| |
| − | |-
| |
| − | ! 1 !! 2 !! 3 !! 4
| |
| − | |-
| |
| − | | <code>VPT</code> || 0b1000 || 1 || T || - || - || -
| |
| − | |-
| |
| − | | <code>VPTT</code> || 0b0100 || 2 || T || T || - || -
| |
| − | |-
| |
| − | | <code>VPTE</code> || 0b1100 || 2 || T || E || - || -
| |
| − | |-
| |
| − | | <code>VPTTT</code> || 0b0010 || 3 || T || T || T || -
| |
| − | |-
| |
| − | | <code>VPTTE</code> || 0b0110 || 3 || T || T || E || -
| |
| − | |-
| |
| − | | <code>VPTEE</code> || 0b1010 || 3 || T || E || E || -
| |
| − | |-
| |
| − | | <code>VPTET</code> || 0b1110 || 3 || T || E || T || -
| |
| − | |-
| |
| − | | <code>VPTTTT</code> || 0b0001 || 4 || T || T || T || T
| |
| − | |-
| |
| − | | <code>VPTTTE</code> || 0b0011 || 4 || T || T || T || E
| |
| − | |-
| |
| − | | <code>VPTTEE</code> || 0b0101 || 4 || T || T || E || E
| |
| − | |-
| |
| − | | <code>VPTTET</code> || 0b0111 || 4 || T || T || E || T
| |
| − | |-
| |
| − | | <code>VPTEEE</code> || 0b1001 || 4 || T || E || E || E
| |
| − | |-
| |
| − | | <code>VPTEET</code> || 0b1011 || 4 || T || E || E || T
| |
| − | |-
| |
| − | | <code>VPTETT</code> || 0b1101 || 4 || T || E || T || T
| |
| − | |-
| |
| − | | <code>VPTETE</code> || 0b1111 || 4 || T || E || T || E
| |
| − | |-
| |
| − | | colspan="7" | same encoding applies to <code>VPST</code>
| |
| − | |}
| |
| − |
| |
| − | === Load/Stores ===
| |
| − | ==== Interleaving/Deinterleaving ====
| |
| − | MVE supports interleaving data streams with strides of 2 and 4. They are done using the <code>VLD{2,4}x</code> and <code>VST{2,4}x</code> 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 ====
| |
| − | MVE supports scatter and gather. They are done using the <code> VSTR{B, H, W, D}</code> and <code>VLDR{B, H, W, D}</code> instructions.
| |
| − |
| |
| − | == bibliography ==
| |
| − | * ''ARMv8-M Architecture Reference Manual'', Chapter B5. Vector Extension.
| |
| − | * {{bib|personal|February 2020|Arm}}
| |
