From 143145ccd09850a4aacd01f1f7a79de0ed9af2d3 Mon Sep 17 00:00:00 2001 From: lkcl Date: Tue, 4 Apr 2023 00:55:10 +0100 Subject: [PATCH] --- openpower/sv/svp64/appendix.mdwn | 60 -------------------------------- 1 file changed, 60 deletions(-) diff --git a/openpower/sv/svp64/appendix.mdwn b/openpower/sv/svp64/appendix.mdwn index 5d51e3481..c6b25a4c2 100644 --- a/openpower/sv/svp64/appendix.mdwn +++ b/openpower/sv/svp64/appendix.mdwn @@ -81,66 +81,6 @@ may be performed by setting VL=8, and a one-instruction 1024-bit Add-with-Carry by setting VL=16, and so on. More on this in [[openpower/sv/biginteger]] -# v3.0B/v3.1 relevant instructions - -SV is primarily designed for use as an efficient hybrid 3D GPU / VPU / -CPU ISA. - -Vectorisation of the VSX Packed SIMD system makes no sense whatsoever, -the sole exceptions potentially being any operations with 128-bit -operands such as `vrlq` (Rotate Quad Word) and `xsaddqp` (Scalar -Quad-precision Add). -SV effectively *replaces* the majority of VSX, requiring far less -instructions, and provides, at the very minimum, predication -(which VSX was designed without). - -Likewise, Load/Store Multiple make no sense to -have because they are not only provided by SV, the SV alternatives may -be predicated as well, making them far better suited to use in function -calls and context-switching. - -Additionally, some v3.0/1 instructions simply make no sense at all in a -Vector context: `rfid` falls into this category, -as well as `sc` and `scv`. Here there is simply no point -trying to Vectorise them: the standard OpenPOWER v3.0/1 instructions -should be called instead. - -Fortuitously this leaves several Major Opcodes free for use by SV -to fit alternative future instructions. In a 3D context this means -Vector Product, Vector Normalise, [[sv/mv.swizzle]], Texture LD/ST -operations, and others critical to an efficient, effective 3D GPU and -VPU ISA. With such instructions being included as standard in other -commercially-successful GPU ISAs it is likewise critical that a 3D -GPU/VPU based on svp64 also have such instructions. - -Note however that svp64 is stand-alone and is in no way -critically dependent on the existence or provision of 3D GPU or VPU -instructions. These should be considered entirely separate -extensions, and their discussion -and specification is out of scope for this document. - -## Major opcode map (v3.0B) - -This table is taken from v3.0B. -Table 9: Primary Opcode Map (opcode bits 0:5) - -``` - | 000 | 001 | 010 | 011 | 100 | 101 | 110 | 111 -000 | | | tdi | twi | EXT04 | | | mulli | 000 -001 | subfic | | cmpli | cmpi | addic | addic. | addi | addis | 001 -010 | bc/l/a | EXT17 | b/l/a | EXT19 | rlwimi| rlwinm | | rlwnm | 010 -011 | ori | oris | xori | xoris | andi. | andis. | EXT30 | EXT31 | 011 -100 | lwz | lwzu | lbz | lbzu | stw | stwu | stb | stbu | 100 -101 | lhz | lhzu | lha | lhau | sth | sthu | lmw | stmw | 101 -110 | lfs | lfsu | lfd | lfdu | stfs | stfsu | stfd | stfdu | 110 -111 | lq | EXT57 | EXT58 | EXT59 | EXT60 | EXT61 | EXT62 | EXT63 | 111 - | 000 | 001 | 010 | 011 | 100 | 101 | 110 | 111 -``` - -It is important to note that having a different v3.0B Scalar opcode -that is different from an SVP64 one is highly undesirable: the complexity -in the decoder is greatly increased, through breaking of the RISC paradigm. - # EXTRA Field Mapping The purpose of the 9-bit EXTRA field mapping is to mark individual -- 2.30.2