[Libre-soc-isa] [Bug 1092] OPF RFC ISA WG questions feedback on ls002 float-load-immediate

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Thu Jun 22 11:43:28 BST 2023


--- Comment #23 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Paul Mackerras from comment #20)
> Here is a suggestion which you might like to consider, and which might be
> more easily accepted by the IBM architects (no guarantees, I don't know what
> they will think of it).


> If you look at xxspltidp, it is actually quite close to what you want.

this is a good goal to have, to make SFFS stand-alone independent,
but also as you suggest bear in mind that the intention was to
fit VRs on top of FP and "merge" the two groups of instructions,
there will have been a lot of thought gone into them.

we need to "extract" that merging with the least disruption, this is
a valuable insight, thank you Paul.

> It is
> a prefixed instruction (using a PO1 prefix) which has 32 bits of immediate
> field containing a single-precision value, which is converted to double
> precision and stored into the two halves of a VSR.
> My suggestion is to define a "floating load immediate single-precision"
> (flis) instruction which differs from xxspltidp in only one bit in its
> instruction encoding, specifically that bit 12 of the suffix would be 1 in
> flis vs. 0 in xxspltidp.

ahhh. minimise gates.

> The difference in behaviour would be that flis
> would test MSR.FP rather than MSR.VSX, it would only address the FPRs (so
> bit 15 of the suffix is always 0), and it would only write one value (vs.
> two copies for xxspltidp).
> This should add minimal extra work for implementations which have VSX
> already,

agreed reducing Decode gates and also implementation work is really

> and it wouldn't use up any PO9 opcode space.

this is ironically the one instruction that cannot go into PO9 because
it is so crucial to SFFS

it is always always crucial to treat PO9 as if it was an entirely
independent 32-bit instruction.

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

More information about the Libre-SOC-ISA mailing list