From WikiChip
Difference between revisions of "arm/helium"
< arm

(MVE initial page)
 
Line 11: Line 11:
  
 
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'''. 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.
 +
 +
=== 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}}

Revision as of 23:41, 16 February 2020

v · d · e
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.

Overview

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:

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. 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.

helium vector reg file alias.svg

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.

Predication/conditional execution

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.

Load/Stores

Interleaving/Deinterleaving

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

MVE supports scatter and gather. They are done using the VSTR{B, H, W, D} and VLDR{B, H, W, D} instructions.

bibliography

  • ARMv8-M Architecture Reference Manual, Chapter B5. Vector Extension.
  • Arm. personal communication. February 2020.
Retrieved from "https://en.wikichip.org/w/index.php?title=arm/helium&oldid=96019"