[Libre-soc-dev] complex numbers as matrices

[Luke Kenneth Casson Leighton]

On 6/30/21, Richard Wilbur <richard.wilbur at gmail.com> wrote:

> On the other hand, if we choose to represent the complex numbers as 2x2
> matrices of reals, then we have the following
> [ 1xNx2x2] = [ 1xNx2x2 ] x [ NxNx2x2 ]
> which yields under dimensional analysis
> 3D = 3D x 4D
> and thus no longer necessarily so trivial, even for a vector machine.

yes.

we established that when doing multiply Ca and Cb, Ca can be
represented as a 2x2 matrix (where its R and I can be "virtually"
copied rather than actually copied), Cb only need be a 1x2.

it is however an extra 2 dimensions, still.

> I would consider dedicating a mode to dealing with pairs of scalars that
> travel together as complex numbers.

i concur, with the Real part being the first part.  this means that a
scalar op on a complex one need...

ahhh.... actually, a case could be made that a *vector* of complex
numbers should have all real parts at the front then all imaginary
parts after.

otherwise, for operations on vectors of scalars times vectors of
complex numbers you would have to refer to every 2nd element... no
wait, that's something that's easy enough to do in hardware.

the "Bad Thing(tm)" to do would be to treat a complex array as a
scalar array without realising they were stored

r0=a0.r
r1=a0.i
r2=a1.r
r3=a1.i

you would need a VCOMPRESS-copy first (a predicate of 0b01010101) in
order to extract the real parts:

sv.mv/mask=0b01010101 r8.v, r0.v

r8=a0.r
r9=a1.r



>  The rules are slightly different than
> regular [ 1x2 ] vectors but they are very important in science and
> engineering and, this feeds into a different conversation on this mailing
> list, the normal result of a Fourier transform.
>
> With a mode to treat register pairs as the real and imaginary parts of
> complex numbers we can have double-precision complex number support for
> free.

yes.

> vector operations)
> abs(complex= a + jb) = sqrt(complex x conjugate(complex))
>   = sqrt((a + jb)(a - jb)) = sqrt(a^2 + b^2)
> (Same as vector magnitude.)

these are all doable using "microcoding"

i think... if we try not to overload REMAP itself, i.e. let REMAP
apply in the abstract just as well to complex-tagged registers as
non-tagged ones, then it becomes possible to expand *internally* the
number of hardware for-loops to the required 4D.. *without* the ISA or
the programmer having to know about it.

now, the only thing is, we have to have some way to store the extra
state information, in SVSTATE.

SVSTATE currently stores two "steps" srcstep and dststep.

correction, it also stores SUBVL steps.

now, if we are happy to stay within the limit of 64 elements total for
VL... wait ...

https://libre-soc.org/openpower/sv/sprs/

look up SVSTATE, note how srcstep and dststep are *seven* bits? this
means that as long as the total number of scalar "things" to be done
in 4D is below 128, we are ok.

by that i mean, if you nest the 4 loops and inside the very core you have

  for  REMAP X
    for REMAP Y
      for REMAP Z
        for complex mult
          srcstep++

as long as srcstep never exceeds 128 we have *no need to modify the
definition of SVSTATE*.

then the hardware can use srcstep as a reference in a Finite State
Machine to work out where it has gotten to (where it is in the 4-deep
nested for-loops).

i think we're good.

l.