[Libre-soc-isa] [Bug 213] SimpleV Standard writeup needed

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=213

--- Comment #41 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #39)
> (In reply to Luke Kenneth Casson Leighton from comment #37)
> > (In reply to Luke Kenneth Casson Leighton from comment #33)
> > 
> > > one thing though: i am really really leaning towards completely ignoring the
> > > XER SO field for SV when it comes to CRs, and potentially giving that bit in
> > > the CRs a new much more useful purpose.
> 
> If we use CRs for compare results, we still need the SO bit since it is used
> for "unordered" for floating-point compares.

right.  ok.  so FP ops i see don't have an OE bit.  which tends to suggest
that only the INT ops could have the trick of using SO as a "spare predicate
bit" and using OE to indicate that it's enabled.

for FP, yes, we would need to leave it alone, and use one of the prefix bits
to specify whether the FP op is to be predicated or not (and which CR bit
to select to do so)

however - what we *can* do - after each vectorised FPop has produced a
vectorised CR array (including still having that "unordered" bit) is use
vectorised crand/cror/mfcr (etc) to post-analyse the *array* of CR bits
in a useful manner.

such as masking out any "unordered" operations (saving CPU cycles and
Reservation Stations at the ALU in the process)

the idea of transferring to INT-GPRs by vectorising isel is still "a valid
possibility" but i think by keeping predicates in CRs we don't *need* to
transfer to intregs, and consequently wouldn't need that "special bit-wise
RT-to-CR" operation which doesn't seem to exist in PowerISA anyway

hmmm....

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