Bug 919

I've updated the disassembly with the following:
1. pysvp64dis prints the instructions themselves, too. This allows to analyze the binary data simultaneously. Unknown instructions are printed as .long; SVP64 instructions are printed in parts, with the first part dedicated to the instruction and second empty (binutils way).
2. I added support for LK and AA matching whenever one tries to find the instruction name in the database. Rc matching follows the same pattern.
3. The "database" classes hierarchy is changed, so the name matching applies to SV-enabled instructions, too.
4. Various fixes, e.g. now we don't panic when there's a simple word instruction followed by SVP64 instruction.

Below is an example of the output.

14 6a e2 7e    add r23,r2,r13
40 0a 40 05    sv.add
14 6a e2 7e
08 00 49 40    bc 2,9,0x8
00 00 40 05    sv.bc
08 00 49 40
15 02 41 7c    add. r2,r1,r0
21 04 80 4e    bcctrl 20,0,0
2b 00 85 40    bcla 4,5,0x28

We don't handle registers other than GPR and FPR yet, and don't (won't?) handle aliases, but, other than that, I'd say we're close to completing. Do we need support for pretty-printable CR_BIT/CR_REG? If so, how would it look in assembly? IIRC binutils treat these like `bdzf    4*cr2+gt,0x14`. If so, that'd be tricky a little bit, since we handle operand-per-operand, separated by comma; but, considering real operands, there are three of them, not two (like if we count commas).

(In reply to Dmitry Selyutin from comment #1)

> 2. I added support for LK and AA matching whenever one tries to find the
> instruction name in the database. Rc matching follows the same pattern.

briiilliant.  this is done manually for now, in PowerDecoder2 DecodeOE
(blegh)


            with m.Case(MicrOp.OP_MUL_H64, MicrOp.OP_MUL_H32,
                        MicrOp.OP_EXTS, MicrOp.OP_CNTZ,
                        MicrOp.OP_SHL, MicrOp.OP_SHR, MicrOp.OP_RLC,
                        MicrOp.OP_LOAD, MicrOp.OP_STORE,
                        MicrOp.OP_RLCL, MicrOp.OP_RLCR,
                        MicrOp.OP_SETVL, MicrOp.OP_SVSHAPE,
                        MicrOp.OP_SVINDEX, MicrOp.OP_SVREMAP,
                        MicrOp.OP_SVSTEP,
                        MicrOp.OP_EXTSWSLI, MicrOp.OP_GREV, MicrOp.OP_TERNLOG):
                pass

            # all other ops decode OE field
            with m.Default():

                    with m.Case(RC.RC):
                        comb += self.oe_out.data.eq(self.dec.OE)
                        comb += self.oe_out.ok.eq(1)

(In reply to Dmitry Selyutin from comment #2)
> We don't handle registers other than GPR and FPR yet, and don't (won't?)
> handle aliases, but, other than that, I'd say we're close to completing. Do
> we need support for pretty-printable CR_BIT/CR_REG?

don't worry about it.  it's icing :)

Progress on word instructions: implemented `pysvp64dis -v` flag, which dumps the information like this:

15 6a e2 7e    add. r23,r2,r13
    spec   add. RT,RA,RB (OE=0 Rc=1)
    opcode 0x7c000215
    mask   0xfc0007ff
    RT     10111 [6, 7, 8, 9, 10]
    RA     00010 [11, 12, 13, 14, 15]
    RB     01101 [16, 17, 18, 19, 20]
    OE     0 [21]
    Rc     1 [31]
08 00 49 40    bc 2,9,0x8
    spec   bc BO,BI,BD (AA=0 LK=0)
    opcode 0x40000000
    mask   0xfc000003
    BO     00010 [6, 7, 8, 9, 10]
    BI     01001 [11, 12, 13, 14, 15]
    BD     00000000000010 [16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29] (target_addr=EXTS(BD || 0b00))
    AA     0 [30]
    LK     0 [31]

I had to refactor the verbose output, since some fields are way too wide. Also, if we dump all SVP64 fields, this will become even wider. Now it looks like this:

08 00 49 40    bc 2,9,0x8
    spec
        bc BO,BI,BD (AA=0 LK=0)
    binary
        [0:8]   01000000
        [8:16]  01001001
        [16:24] 00000000
        [24:32] 00001000
    opcode
        0x40000000
    mask
        0xfc000003
    BO
        00010
        [6, 7, 8, 9, 10]
    BI
        01001
        [11, 12, 13, 14, 15]
    BD
        00000000000010
        [16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29]
        target_addr = EXTS(BD || 0b00))
    AA
        0
        [30]
    LK
        0
        [31]

Longer but now any operand can print an arbitrary amount of lines.

(In reply to Dmitry Selyutin from comment #6)
 
> 08 00 49 40    bc 2,9,0x8
>     spec
>         bc BO,BI,BD (AA=0 LK=0)

needs the commit reverting the
change to the mdwn, BO,BI,target_addr

I fixed the immediate operands, both for spec and per-operand information. Here's how it looks:

00 20 40 05    sv.lwz
08 00 61 80
    spec
        sv.lwz RT,D(RA)
    binary
        [0:8]   00000101
        [8:16]  01000000
        [16:24] 00100000
        [24:32] 00000000
        [32:40] 10000000
        [40:48] 01100001
        [48:56] 00000000
        [56:64] 00001000
    opcode
        0x80000000
    mask
        0xfc000000
    RT
        01010
        [6, 7, 8, 9, 10]
    D
        0010000000000000
        [16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31]
    RA
        00000
        [11, 12, 13, 14, 15]

can you take a look at this to see if you agree with it?

https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=d657266ae0e4b6c034e67ec1797c24e59861b547

it causes pysvp64dis (i added a new console script command via
setup.py entry_points) to output v3.0/v3.1 spec-correct definitions

09 08 00 40    bcl 0,0,0x808
    spec
        bcl BO,BI,target_addr (AA=0 LK=1)