[Libre-soc-dev] FFT, DCT, REMAP

[Luke Kenneth Casson Leighton]

On 6/22/21, Jacob Lifshay <programmerjake at gmail.com> wrote:

> but that shift amount needs to live somewhere -- no space in the argument
> list -- and if you want the code to be able to handle variable-sized FFT
> then sticking the shift amount in an immediate won't work, hence the SPR.
> We wouldn't necessarily need a new SPR, we can re-use CTR or LR or
> something fast and accessible from userland.

LR is the return address from functions, CTR is used for automatic
countdown loops: we can't overload either of them. TAR is privileged
access only.

my feeling is that we need a new Form, one that combines DS-Form and
X-Form, with a reduced size immediate.  when OP=58 this is ld:

OP RT RA imm xxxxx
0  6  11 16  30 31

for byte-reversed mode SVP64 a new form would be used:

OP RT RA RC imm xxxxx
0  6  11 16 21   30 31

these are all major opcodes (58, 41 etc) because of the 16 bits
required for the immediate.  losing 5 of those bits (reducing imm to
11) is no big deal for bitreverse usage because the offsets are used
as a multiplier "jump" factor (i.e  are multiplied by the srcstep) and
i believe they're normally quite small i.e. used as multipliers of the
word size.

EA = RA +
     srcstep*imm

where what we need is:

EA = RA +
     (srcstep*imm)
     << RC

or actually it will be, for bitrev mode:

EA = RA +
     (bitrev(srcstep) * imm)
     << RC

if larger offsets are needed than can fit into imm then um well they
get put into extra RC shift.

does that look about right?

fitting an "override" into PowerDecoder2 is going to be a bit of a pig :)

it involves an extra bit, "is this an SVP64 instruction" if yes merge
in extra entry into case statements.

argh :)

or, have a completely separate tree which is first looked up, and if
that fails to give a match, look up the "normal" v3.0B tree instead.

this would be a lot cleaner, the Decoder logic is already pretty hairy
(recursive), i don't want to touch it.

l.