From 8c6a27b790f97b7f5e7c658d4389db2de70417c4 Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Sun, 2 Apr 2023 19:50:31 +0100 Subject: [PATCH] bring in edits from web on ls010 --- openpower/sv/svp64.mdwn | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn index 829474e20..728e09c9a 100644 --- a/openpower/sv/svp64.mdwn +++ b/openpower/sv/svp64.mdwn @@ -31,6 +31,8 @@ Links: * Saturating description. * TODO [[sv/svp64-single]] * External RFC ls010 +* [[sv/branches]] chapter +* [[sv/ldst]] chapter Table of contents @@ -236,14 +238,19 @@ MSB0 numbering in both bits and elements, adapting in full to LSB0 numbering, and obeying LE ordering*. **Crucial to understanding why the subtraction from 1,3,7,15 is present -is because VSX Registers number elements also in MSB0 order**. SVP64 -very specifically numbers elements in **LSB0** order with the first -element being at the **LSB** end of the register, where VSX places -the numerically-lowest element at the **MSB** end of the register. +is because the Power ISA numbers VSX Registers elements also in MSB0 order**. +SVP64 very specifically numbers elements in **LSB0** order with the first +element (numbered zero) being at the bitwise-numbered **LSB** end of the register, where VSX +does the reverse: places the numerically-*highest* (last-numbered) element at +the LSB end of the register. + ``` #pragma pack typedef union { + // these do NOT match their Power ISA VSX numbering directly, they are all reversed + // bytes[15] is actually VSR.byte[0] for example. if this convention is not + // followed then everything ends up in the wrong place uint8_t bytes[16]; // elwidth 8, QTY 16 FIXED total uint16_t hwords[8]; // elwidth 16, QTY 8 FIXED total uint32_t words[4]; // elwidth 32, QTY 8 FIXED total -- 2.30.2