[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