[libre-riscv-dev] [Bug 139] Add LD.X and ST.X? Strided

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=139

--- Comment #52 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #47)
> (In reply to Jacob Lifshay from comment #45)
> > so it uses 5 funct3 values overall, which is appropriate, since swizzle is
> > probably right after muladd in usage in graphics shaders.
> 
> These are 4 op, take up 50 to 80% of a major opcode. That's really, *really*
> high.

62.5% for the encodings proposed in comment #45,
25% if the immediate forms are left out.

Note that the above is ignoring the %71 unused space in the immediate field for
[f]swizzlei due to the upper bits of the swizzle field always being zero for
smaller DESTSUBVL values and DESTSUBVL == 4 not sharing funct3 values.

Taking that in to account:
35.7% for the encodings proposed in comment #45

(I may have made a mistake in my calculations though)

> 
> I wonder instead if we can fit some bits into VBLOCK or SVP64.

Didn't check for VBLOCK, but I would be surprised if they won't fit in SVP64.

However, since swizzles are one of the few instruction types that require
multiple non-trivial [1] SUBVL fields/values, I think having it encoded in the
swizzle instruction itself [2] would be better.

1: I count instructions like load-gather/store-scatter as trivial, since all
instruction arguments either use SUBVL (for src/dest reg) or SUBVL is always 1
(for address reg), so multiple SUBVL's don't need to be encoded

2: includes the prefix if the prefix is always required

> 
> If these ops are that common and that important, trying to cram everything
> into OP32 is just asking for trouble.

They can go in other opcode blocks. We could do something such as share the
opcode with JAL (for example) and [f]swizzle[i/2] would only be valid inside
VBLOCK or prefixed, where JAL isn't valid anyway.

-- 
You are receiving this mail because:
You are on the CC list for the bug.