From 53ae6f66181f9f75de184757ce24893199826e23 Mon Sep 17 00:00:00 2001 From: lkcl Date: Wed, 1 Jun 2022 04:14:11 +0100 Subject: [PATCH] --- openpower/sv/svp64_quirks.mdwn | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn index 7c0221772..ec64b9429 100644 --- a/openpower/sv/svp64_quirks.mdwn +++ b/openpower/sv/svp64_quirks.mdwn @@ -31,6 +31,22 @@ different encoding if SVP64-prefixed: it did not go well. The complexity that resulted in the decode phase was too great)* +# Instruction Groups + +The basic principle of SVP64 is the prefix, which contains mode +as well as register augmentation and predicates. When thinking of +instructions and Vectorising them, it is natural for arithmetic +operations (ADD, OR) to be the first to spring to mind. +Arithmetic instructions have registers, therefore augmentation +applies, end of story, right? + +Except, Load and Store deals also with Memory, not just registers. +Power ISA has Condition Register Fields: how can element widths +apply there? And branches: how can you have Saturation on something +that does not return an arithmetic result? In short: there are actually +four different categories (five including those for which Vectorisation +makes no sense at all, such as `sc` or `mtmsr`). + # CR weird instructions [[sv/int_cr_predication]] is by far the biggest violator of the SVP64 -- 2.30.2