[Libre-soc-dev] mfocr and mtocrf v3.0B spec ambiguity

[Luke Kenneth Casson Leighton]

On Friday, August 28, 2020, Paul Mackerras <paulus at ozlabs.org> wrote:

>
> > otherwise, applications are guaranteed to break.
>
> Well, only if compilers or assembly language programmers use mfocrf
> with more than one bit set in FXM, which would be a perverse thing to
> do...


:)

they aren't likely to, i would agree, if they don't know it's possible.
still, clarifying the spec here to take into account bit 20 is.. sensible.
it would mean back at section 1.6 to add a field in XFX-Form (please not
"L"!  or if it is, only "L" if there are no other fields named "L" in
XFX-Form)

then referencing that in the text for mfocr and mtocrf.


fascinatingly the design of the CR regfile in libresoc is unary encoded
with an 8 bit mask that could, in fact, use FXM directly, both as read or
write.

as in the FXM field literally wired bit-for-bit gets the CR value needed,
making the CR pipeline for mfocr etc trivial.  no read modify write needed,
no mask needed.

having to do the one-hot picking is ironically a "nuisance" (not really),
it is quite trivial to put FXM through a one-hot (or not) depending on
whether bit 20 is set.

i can see how this instruction evolved, it is quite fascinating.

l.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68