[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 #48 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Dmitry Selyutin from comment #47)

> Yeah this was a huge mix-up. The code now produces Instruction(name='lwbrx',
> opcode=FieldsOpcode(value=0x7c00042c, mask=0xfc0007fe)). 

Hoorah. 

> However, that said,
> the _binutils_ mask should have been be 0xfc0007ff, because X_MASK includes
> Rc field. 

ok see below.

> unlike our mask, the binutils mask is just the way to describe
> which fields are not expected to be operands. 

Yes. And they construct that by hand rather than autogenerate .

right. Deep breath. Paul Anton and the others at IBM Research
who wrote microwatt kinda know power ISA the *real* Power ISA
which is actually implemented by IBM POWER8 9 10 as opposed
to what went in the spec if you know what I mean.

One of the very annoying things that was done in the spec was,
you can have bits that are ignored rather than have to be
set to RESERVED values.  Divide returns zero on overflow
by POWER9 but the spec says "UNDEFINED" for example.

Also mulhw if you look at the opcode there is *room* for an
OE bit but rather than throw an exception POWER9 will
blithely IGNORE that bit and execute the instruction as
if it had not been set.  There is a whole list of those
in DecodeOE in power_decoder2.py, sigh.

Likewise in the case of lwbrx, you *can* actually set bit 31
to 1 or 0 and IBM POWER9 hardware will *not care*

you should be getting a sinking feeling or at least face-palm
moment, but also understanding and appreciating that because
Power ISA decode is so complex they *had* to take these
shortcuts.

Normally a spec makes these things RESERVED, basica!ly, so
an illegal instruction trap should be thrown, but it is too
costly in gates.

Point is, how binutils does things is perfectly legal but
misses instructions that should *not be attempted anyway*
(bit 31=1) and *our* decode will get *both* the decodes,
the one that is normally done (0x7c00042c) *and* also the
one that strictly speaking you should not create (0x7c00042d)
but if you did *IBM hardware would actually execute it*.

sigh :)

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