This is the first stage to real disassembly: support at least the very basic information, like determining the name, decoding the operands, and so on.
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)