[Libre-soc-bugs] [Bug 838] sync or at least statically check fields.text, power_decoder, trans/svp64, CSVs between each other

[bugzilla-daemon at libre-soc.org]

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

--- Comment #42 from Dmitry Selyutin <ghostmansd at gmail.com> ---
Yet another inconsistency spotted, this time for Rc stuff.

Here are the instructions which are marked as RC.ONE (with the names exactly as
they appear in our CSVs, I don't update the names for RC.ONE): ['lwbrx',
'addic.', 'andi.', 'andis.', 'stbcx', 'stdcx', 'sthcx', 'stwcx'].


First, binutils names don't match in case of stbcx, stdcx, sthcx, stwcx
instructions: in binutils, they all are marked with dot (stdbcx., stdcx.,
etc.). It looks like we got it wrong, spec also talks of Rc marks, like
binutils. I suggest marking these with dot explicitly, exactly like andi. or
addic. are marked.


Second, some instructions are marked as RC in CSVs, but their forms lack Rc
field. Here's the form mapping for the instructions which have this problem:
andis.: B-FORM
addic.: D-FORM
andi.: B-FORM

Neither D-FORM nor B-FORM have Rc bit present. These entries in binutils seem
special and simply define OP_MASK as mask (that is, the mask for the major
code: (0x3f << 26). I'm not sure how to do it correctly since we calculate the
opcode based on the form; I could hack the code based on instruction names, but
perhaps I miss something and I can do it in a generic way.


Third, I'm not sure whether it's correct that we have "attn" instruction marked
with RC (extra.csv). Binutils don't have "attn.", and also this is yet another
instruction which can have Rc mark but has no specific form, therefore cannot
have Rc field (where should it belong?).

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