openpower/sv/biginteger.mdwn

   1 [[!tag standards]]
   2
   3 # Big Integer Arithmetic
   4
   5 **DRAFT STATUS** 19apr2021
   6
   7 (see [[discussion]] page for notes)
   8
   9 BigNum arithmetic is extremely common especially in cryptography,
  10 where for example RSA relies on arithmetic of 2048 or 4096 bits
  11 in length.  The primary operations are add, multiply and divide
  12 (and modulo) with specialisations of subtract and signed multiply.
  13
  14 A reminder that a particular focus of SVP64 is that it is built on
  15 top of Scalar operations, where those scalar operations are useful in
  16 their own right without SVP64. Thus the operstions here are proposed
  17 first as Scalar Extensions to the Power ISA.
  18
  19 A secondary focus is that if Vectorised, implementors may choose
  20 to deploy macro-op fusion targetting back-end 256-bit or greater
  21 Dynamic SIMD ALUs for maximum performance and effectiveness.
  22
  23 # Analysis
  24
  25 Covered in [[biginteger/analysis]] the summary is that standard `adde`
  26 is sufficient for SVP64 Vectorisation of big-integer addition (and subfe
  27 for subtraction) but that big-integer multiply and divide require two
  28 extra 3-in 2-out instructions, similar to Intel's `mulx`, to be efficient.
  29 Macro-op Fusion and back-end massively-wide SIMD ALUs may be deployed in a
  30 fashion that is hidden from the user, behind a consistent, stable ISA API.
  31
  32 # Instructions
  33
  34 **DRAFT**
  35
  36 Both `madded` and `msubed` are VA-Form:
  37
  38 |0.....5|6..10|11..15|16..20|21..25|26..31|
  39 |-------|-----|------|------|------|------|
  40 | EXT04 | RT  |  RA  |  RB  |   RC |  XO  |
  41
  42 For the Opcode map (XO Field)
  43 see Power ISA v3.1, Book III, Appendix D, Table 13 (sheet 7 of 8), p1357.
  44 Proposed is the addition of `msubed` (**DRAFT, NOT APPROVED**) which is
  45 in `110110`.  A corresponding `madded` is proposed for `110010`
  46
  47 | 110000 | 110001  | 110010 | 110011 | 110100 | 110101 | 110110 | 110111 |
  48 | ------ | ------- | ------ | ------ | ------ | ------ | ------ | ------ |
  49 | maddhd | maddhdu | madded | maddld | rsvd   | rsvd   | msubed | rsvd   |
  50
  51 For SVP64 EXTRA register extension, the `RM-1P-3S-1D` format is
  52 used with the additional bit set for determining RS.
  53
  54 | Field Name | Field bits | Description                            |
  55 |------------|------------|----------------------------------------|
  56 | Rdest\_EXTRA2 | `10:11` | extends RT (R\*\_EXTRA2 Encoding)   |
  57 | Rsrc1\_EXTRA2 | `12:13` | extends RA (R\*\_EXTRA2 Encoding)   |
  58 | Rsrc2\_EXTRA2 | `14:15` | extends RB (R\*\_EXTRA2 Encoding)   |
  59 | Rsrc3\_EXTRA2 | `16:17` | extends RC (R\*\_EXTRA2 Encoding)   |
  60 | EXTRA2_MODE   | `18`    | used by `msubed` and `madded` for RS   |
  61
  62 When `EXTRA2_MODE` is set to zero, the implicit RS register takes
  63 its Vector/Scalar setting from Rdest_EXTRA2, and takes
  64 the register number from RT, but all numbering
  65 is offset by VL. *Note that element-width overrides influence this
  66 offset* (see SVP64 [[svp64/appendix]] for full details).
  67
  68 When `EXTRA2_MODE` is set to one, the implicit RS register is identical
  69 to RC extended to SVP64 numbering, including whether RC is set Scalar or
  70 Vector.
  71
  72 ## msubed
  73
  74 The pseudocode for `msubed RT, RA, RB, RC`` is:
  75
  76     prod[0:127] = (RA) * (RB)
  77     sub[0:127] = EXTZ(RC) - prod
  78     RT <- sub[64:127]
  79     RS <- sub[0:63] # RS is either RC or RT+VL
  80
  81 Note that RC is not sign-extended to 64-bit.  In a Vector Loop
  82 it contains the top half of the previous multiply-with-subtract,
  83 and the current product must be subtracted from it.
  84
  85 ## madded
  86
  87 The pseudocode for `madded RT, RA, RB, RC` is:
  88
  89     prod[0:127] = (RA) * (RB)
  90     sum[0:127] = EXTZ(RC) + prod
  91     RT <- sum[64:127]
  92     RS <- sum[0:63] # RS is either RC or RT+VL
  93
  94 Again RC is zero-extended (not shifted), the 128-bit product added
  95 to it; the lower half of the result stored in RT and the upper half
  96 in RS.
  97
  98 The differences here to `maddhdu` are that `maddhdu` stores the upper
  99 half in RT, where `madded` stores the upper half in RS. There is no
 100 equivalent to `maddld` because `maddld` performs sign-extension on RC.
 101