[Libre-soc-isa] [Bug 1056] questions and feedback (v2) on OPF RFC ls010

[bugzilla-daemon at libre-soc.org]

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

--- Comment #53 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Paul Mackerras from comment #25)
> (In reply to Luke Kenneth Casson Leighton from comment #12)

> > it is *always* a Defined-word-instruction, where that DWI **MUST**
> > have the exact same definition as if it had no prefix at all
> > (caveat: bar the niggles on elwidth).
> 
> I think it's not just element width, it's also the possiblity of doing
> multiple operations, 

it *is* a sequentially-ordered loop, that is mandatory.

> and potentially not doing some or all of them, 

standard In/Out-Order Single/Multi Issue Hazard techniques
have that covered.  even on REMAP.

> leaving the corresponding parts of the destination register unchanged.

solved with byte-level write-enable lines


> > split-field si0-si1, it seems like i am freaking out, but i really
> > *really* don't want to hit the Power ISA Spec with 200+ changes
> > to the RTL and instruction definitions.
> 
> Yeah, neither do I. But the effects of vectorization do have to be
> completely and accurately described somewhere.

indeed.

> > if you really really are asking for split fields to be introduced
> > for RT, RA, RS, RB, BA, BFA, FRS, FRC, BT (basically everything)
> > then i feel the entire suite - over 200 {PO9-DWI}s - should be
> > autogenerated.
> 
> Sorry, I don't get why you're talking about split fields here. I don't
> recall mentioning split fields in this discussion.

si0-si1 in EXT1xx, the IMM field is a new definition

EXTRA bits in the 24-bit RM prefix area combined with e.g. RT=insn[6:10]
technically/pedantically RT as a 7-bit is a "split field".

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