[Libre-soc-dev] LD/ST Elwidth Overrides

lkcl luke.leighton at gmail.com
Wed Sep 1 16:59:51 BST 2021



On September 1, 2021 3:32:44 PM UTC, Dmitry Selyutin <dmitry.selyutin at 3mdeb.com> wrote:

>> question: what should the behaviour be?
>
>I'm by no means an expert in instructions, but doesn't it quack like an
>
>illegal instruction?

it does, it's just that it's the combination of interaction and detection between prefix and suffix requires a lot more gates, and creates unnecessary "linkage" between prefix decoding and suffix decoding.

in an absolutely ideal world you would be able to decode the prefix entirely without knowing *at all* what the v3.0B 32 bit suffix contained.

unnnfortunately, that's also impractical, there are just not enough bits.

already we have to do this:

* partial decode of v3.0B 32 bit suffix, is it
   - a LD/ST
   - a Branch
   - a CR op
   - anything else
* if one of the 4 types, interpret the 24 bit prefix MODE
   bits in totally different ways
* further partial decode, what Micro-Op is it.
  OP_ADD, OP_EXTS, OP_SHIFT, etc etc
* based on OP_type, identify if it is:
   - Twin or Single Predication
   - 2-bit or 3-bit EXTRA Register fields
   - which EXTRA fields apply to which registers
     RA RB RT RS, for INTs, FRA etc for GPRs, BA, BT
     etc for Condition Register Fields

which is a hell of a lot of linkage which is unavoidable if we want to keep to a sane number of bits for the SVP64 Prefix (currently 24 bits)

l.



More information about the Libre-soc-dev mailing list