[Libre-soc-bugs] [Bug 845] binutils: drop svmagic and deal with the prefix instead

[bugzilla-daemon at libre-soc.org]

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

--- Comment #3 from Dmitry Selyutin <ghostmansd at gmail.com> ---
Here's what we have in binutils:

#define A(op, xop, rc)                          \
  (OP (op)                                      \
   | ((((uint64_t)(xop)) & 0x1f) << 1)  \
   | (((uint64_t)(rc)) & 1))
#define A_MASK A (0x3f, 0x1f, 1)
{"fsub",        A(63,20,0),     AFRC_MASK,   PPCCOM,    PPCEFS|PPCVLE,  {FRT,
FRA, FRB}},
{"fsub.",       A(63,20,1),     AFRC_MASK,   PPCCOM,    PPCEFS|PPCVLE,  {FRT,
FRA, FRB}},

Notice A(63,20,0) and A(63,20,1) fields. They serve the purpose of
instantiating the "opcode" field; this field is exactly what we use for lookup
in disassembler code.

We can get the following upon calling
openpower.decoder.power_svp64.SVP64RM.get_svp64_csv:

minor_63.csv shows that the major opcode is 63 (op == 63).
20 can be obtained from -----11100 record for fsub at minor_63.csv.
0/1 corresponds to RC field.

My question is, do we have some common technique to construct the whole
"opcode" stuff? I mean, I understand the logic for cases like major.csv (where
the OP is a simple integer) and for cases like minor_#.csv (where OP is # and
XOP is determined by the entry). But how do we address other CSVs? Perhaps
there's a simple way to get the "opcode" immediately in Python?

For the record, here are CSVs we currently handle:

    paths = (
        "minor_19.csv",
        "minor_30.csv",
        "minor_31.csv",
        "minor_58.csv",
        "minor_62.csv",
        "minor_22.csv",
        "minor_5.csv",
        "minor_63.csv",
        "minor_59.csv",
        "major.csv",
        "extra.csv",
    )

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