From 70596adc47c62a443dc00e70451b51917c2a2dc9 Mon Sep 17 00:00:00 2001 From: lkcl Date: Sat, 8 Apr 2023 13:01:46 +0100 Subject: [PATCH] --- openpower/sv/rfc/ls012.mdwn | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/openpower/sv/rfc/ls012.mdwn b/openpower/sv/rfc/ls012.mdwn index a1ee3b889..331ad9b30 100644 --- a/openpower/sv/rfc/ls012.mdwn +++ b/openpower/sv/rfc/ls012.mdwn @@ -220,7 +220,7 @@ increases the efficiency of arbitrary-precision integer arithmetic by combining what would otherwise be half a dozen instructions into one. However it is still not a huge priority unlike `bmask` so is probably best placed in EXT2xx. -* Float-Load-Immediate +## Float-Load-Immediate Very easily justified. As explained in [[ls002]] these always saves one LD L1/2/3 D-Cache memory-lookup operation, by virtue of the Immediate @@ -238,6 +238,25 @@ instuction. Thus they qualify as both high priority and also EXT0xx candidates. +# FPR/GPR LD/ST-PostIncrement-Update + +These instruction, outlined in [[ls011]], save hugely in hot-loops. Early ISAs +such as PDP-8, PDP-11, which inspired the iconic Motorola 68000, 88100, Mitch +Alsup's MyISA 66000, and can even be traced back to the iconic ultra-RISC CDC 6600, +all had both pre- and post- increment Addressing Modes. + +The reason is very simple: it is a direct recognition of the practice in c to +frequently utilise both `*p++` and `*++p` which itself stems from common need in +Computer Science algorithms. + +The problem for the Power ISA is - was - that the opcode space needed to support both +was far too great, and the decision was made to go with pre-increment, on the basis +that outside the loop a "pre-subtraction" may be performed. + +Whilst this is a "solution" it is less than ideal, and the opportunity exists now +with the EXT2xx Primary Opcodes to correct this and bring Power ISA up a level. + + [[!inline pages="openpower/sv/rfc/ls012/areas.mdwn" raw=yes ]] -- 2.30.2