[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 #45 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Dmitry Selyutin from comment #43)
> (In reply to Dmitry Selyutin from comment #42)
> > as they appear in our CSVs, I don't update the names for RC.ONE): ['lwbrx',
> > 'addic.', 'andi.', 'andis.', 'stbcx', 'stdcx', 'sthcx', 'stwcx'].
> 
> Sorry, lwbrx appeared there by mistake, don't consider it.
> 
> A minor note so that it' clear which opcode values and masks I mean from
> binutils point of view. Let's consider entry for lwbrx.
> 
> https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=opcodes/ppc-opc.
> c#l8223
> 
> {"lwbrx",       X(31,534),      X_MASK,      PPCCOM,    0,              {RT,
> RA0, RB}},
> 
> #define X(op, xop)          (OP (op) | ((((uint64_t)(xop)) & 0x3ff) << 1))
> #define OP(x)               ((((uint64_t)(x)) & 0x3f) << 26)
> #define XRC(op, xop, rc)    (X ((op), (xop)) | ((rc) & 1))
> #define X_MASK              XRC (0x3f, 0x3ff, 1)
> 
> With our code, what we get is:
> Instruction(name='lwbrx', opcode=FieldsOpcode(value=0x7c00042d,
> mask=0xfc0007ff))

Looks great (perfect). 

I have no problem at all understanding that 0xfc0007ff came
from a *pair* of CSV files, or a hierarchy from power_decoder(). The major
contributed to the fc the
Minor 31 to the 7ff

Most of binutils is quite obviously handwritten and given the
number of instructions I consider that quite insane.

the minor 31 CSV is NOT the same as how binutils does it.
changing the CSV files absolutely cannot happen.

Hang on...

 733   Subdecoder(pattern=31, opcodes=get_csv("minor_31.csv"),
 734.             opint=True, bitsel=(1, 11), suffix=0b00101,
                  subdecoders=[]),

0x7ff is off by one.  It should be 0x7fe.  bitsel is 1..11
so bits in mask must be 0b0000000...11111111110

111 1111 1110 is 7 f e not 7ff

you may also find that 00042d has not been shifted up by
one (start of bitsel)

42d binary 100 0010 1101 no needs shifting. Bit 0 should be 0

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