[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 #33 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #32)
> My comments on jitsi call:
> what about redirecting cr* to integer registers for vector compares?

interesting thought.. ah wait so instead of the CR going into an actual CR it
gies directly into an int regfile?

so sort-of an implicit vector-mcrf?

my concern with that idea although it gas merit in that we would not need to
expand CR to 64 entries is, it kinda breaks the way PowerISA works.

it does have advantages so let's add it to the list of options, comparing it
against simply "vectorising mcrf".

the reason for that being, CR operations are designed to operate at the
bitlevel where INT operations are not.

> kinda like Luke did with branches on RISC-V
> we can put the condition code in the prefix on compare instructions

yes or it is implicit.  or, ah, we perhaps reserve a bit to say whether the
vector-of-compares is to be stored in *one* CR or whether each compare is to be
stored *individually*.

and if there is space (which there will likely be in the SV-P64) we can say if
that single result is to be an "all", "some" or "none" of the compares.

or, it may be possible to introduce that into the vectorisation of
crand/cror/etc CR logic operations, if the src is a vector and the dest a
scalar.

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.  SO causes massive headaches for OoO
and is so rarely used i think we can get away with it.

which, if we do that, we can potentially also repurpose the OE field in the
scalar instructions as a 12th bit in SV-P48.

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