[Libre-soc-bugs] [Bug 898] binutils svp64 objdump support

[bugzilla-daemon at libre-soc.org]

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

--- Comment #15 from Dmitry Selyutin <ghostmansd at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #14)
> (In reply to Dmitry Selyutin from comment #12)
> > Yet another day of banging my head towards metaclasses wall, but again, a
> > success story!
> > 
> > 1. We now have a really pretty print!
> 
> in which universe? :)
> fascinatingly it looks like it's repr()able
> 
> 
> > print(some_insn)
> > SVP64Instruction(0x54027a47d68f215, major=0x1f, prefix={0x54027a4,
> > insn=0x54027a4, major=0x1, pid=0x3, rm={0x27a4, spr=0x27a4, mmode=0x0,
> > mask=0x0, elwidth=0x0, ewsrc=0x0, subvl=0x0, extra=0x13d, mode=0x4,
> 
> ahh, that's really handy.
> 
> 
> > 2. We now have a clear syntax to remap some field, as long as it is wrapped
> > with a class.
> 
> making some of these optional is probably not a good ides
> except by an inheriting class.  or... maybe,i dunno.

No-no, these are not optional, don't think of metaclasses. If we have record
like `x: Y = z`, it means "create field named x of type Y, remapped to z". More
details below

> pack/unpack bits need to be added here.
> pack bit 4
> Unpack bit 5

I'll add these, thanks for reminder!

> can you give an example how that works? like an amoeba
> this has grown to a multicellular organism :)

Sure! The Fields class basically subclasses FieldSelectableInt, but also checks
for some -- unsurprisingly -- class-level immutable fields. Here are Major,
PID, RM and Prefix classes.

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_fields.py;h=98d2a5ae4e8800326fcf3c3d64d15e4eecd8be61;hb=cdd9b4ace0d8417c4caa49741046bf75dfb6b112#l288

Major and PID don't have subfields, so we simply declare these with the only
field (the magic field I mentioned). PID (2 bits) perhaps doesn't need a class
and can be class-less field; as for Major (6 bits), it's used in another place
(Instruction and PrefixedInstruction classes), and it's remapped differently in
these. We also declare RM field (24 bits), with some additional fields.

Now, let's take a look at the Prefix class. We know it contains "rm" RM field,
but the bits are mapped non-sequentially, unlike in RM vanilla class. What do
we do? We declare the RM field as remapped RM:
https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_fields.py;h=98d2a5ae4e8800326fcf3c3d64d15e4eecd8be61;hb=cdd9b4ace0d8417c4caa49741046bf75dfb6b112#l327

This basically says "look at the RM class field, iterate over all its
subfields, and make so that these subfields are all remapped appropriately".
So, for example, the RM.mask field in the new class is remapped from (1, 2, 3)
to (8, 10, 11). And so for other fields. An alternative way to remap would be,
instead of `rm: RM.remap(...)`, to do `rm: Field = ...`. This is just a
syntactic sugar.

Now, let's take a look at how we handle instructions...

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_insn.py;h=03a134d041d0826567640006696c7e61b4d43cb8;hb=b187c5c0c6c9b728f450bd0c129018a42be9637a#l539

Here we have Instruction class. It inherits from Fields, but it's flexible
(size of 0 bits). Nobody should instantiate this class directly. Still, it does
provides some instruction-agnostic stuff (e.g. way to obtain the corresponding
database entry).

Next, we have WordInstruction class.

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_insn.py;h=03a134d041d0826567640006696c7e61b4d43cb8;hb=b187c5c0c6c9b728f450bd0c129018a42be9637a#l570

It already has defined size of 32 bits, and also provides the "major" field.
The major is mapped exactly from 0 to 6 bits, like the parent class. I
inherited it one more time in case I need to extend the Major at power_insn
level (and also for a reason below). Here we also have `disassemble` method
(which by the way accesses instruction-type-agnostic dbrecord).

Now, we want to have a prefixed instruction, which we represent for now as a
pair of WordInstructions.

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_insn.py;h=03a134d041d0826567640006696c7e61b4d43cb8;hb=b187c5c0c6c9b728f450bd0c129018a42be9637a#l589

Unlike the usual Prefix class from field, only suitable for interpreting, we
also want to ensure that the major field is OK. So we define our Prefix class
and in its __post_init__ check that the major field equals to 0x1. We map this
prefix at bits 0..31.

Then, we have a suffix, also with a custom class (for no real purpose yet, only
for explicitness). We map the suffix at bits 32..63.

Next, we provide our own major field, mapped to the same place
PrefixedInstruction.suffix field is. We go to PrefixedInstruction.Suffix
(inherited from the WordInstruction), then access Major (obtained from
WordInstruction.Major via inheritance), and then map this Major to the place we
need (that is, PrefixedInstruction not only has prefix.major and suffix.major,
but also a major alias referring to suffix.major).

We also tune disassemble method.

Now, to gory SVP64 details!

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_insn.py;h=03a134d041d0826567640006696c7e61b4d43cb8;hb=b187c5c0c6c9b728f450bd0c129018a42be9637a#l622

Actually not that gory. We inherit PrefixedInstruction class, so we have
everything it has. We only tune the Prefix class and prefix field so that they
check PID field. And we also tune disassemble method (notice this "sv").

This all is used in pysvp64asm.

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/pysvp64dis.py;h=23e02859d88a9237da3b0ac899897c2915ec1994;hb=refs/heads/pysvp64dis#l33

We read the WordInstruction (potentially a prefix). If the WordInstruction has
non-prefix major, we return this instruction. Otherwise we try reading the
suffix and instantiate either SVP64 or other prefixed instruction.

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