[Libre-soc-bugs] [Bug 917] pysvp64dis: support SVP64 disassembly

[bugzilla-daemon at libre-soc.org]

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

--- Comment #60 from Dmitry Selyutin <ghostmansd at gmail.com> ---
OK we only have BRANCH left. The recent changes in dis branch consider common
BRANCH bits. It works with the disassembly and tests I've written, and to my
understanding matches the tables. However, I cannot make
`src/openpower/decoder/isa/test_caller_svp64_bc.py` work.

Let's consider `sv.bc/all 12,*1,0xc` instruction. Here's what I get:

00 24 48 05    sv.bc/all 12,*1,0xc
0c 00 81 41    
    spec
        sv.bc BO,BI,target_addr AA=0 LK=0
    pcode
        if (mode_is_64bit) then M <- 0
        else M <- 32
        if ¬BO[2] then CTR <- CTR - 1
        ctr_ok <- BO[2] | ((CTR[M:63] != 0) ^ BO[3])
        cond_ok <- BO[0] | ¬(CR[BI+32] ^ BO[1])
        if ctr_ok & cond_ok then
          if AA then NIA <-iea EXTS(BD || 0b00)
          else       NIA <-iea CIA + EXTS(BD || 0b00)
        if LK then LR  <-iea  CIA + 4
    binary
        [0:8]   00000101
        [8:16]  01001000
        [16:24] 00100100
        [24:32] 00000000
        [32:40] 01000001
        [40:48] 10000001
        [48:56] 00000000
        [56:64] 00001100
    opcodes
        010000------------------------00
    BO
        01100
        38, 39, 40, 41, 42
    BI (vector)
        000000001
        43, 44, 45, 46, 47, 22, 23, {0}, {0}, 43, 44, 45, 46, 47
        extra3[1]
    target_addr = EXTS(BD || 0b00))
        BD
            0000000000001100
            48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, {0}, {0}
    AA
        0
        62
    LK
        0
        63
    RM
        branch: simple mode
        RM
            000010000010010000000000
            6, 8, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24,
25, 26, 27, 28, 29, 30, 31
        RM.mmode
            0
            6
        RM.mask
            000
            8, 10, 11
        RM.elwidth
            10
            12, 13
        RM.ewsrc
            00
            14, 15
        RM.subvl
            00
            16, 17
        RM.mode
            00000
            27, 28, 29, 30, 31
        RM.smask
            000
            24, 25, 26
        RM.extra
            100100000
            18, 19, 20, 21, 22, 23, 24, 25, 26
        RM.extra2
            100100000
            18, 19, 20, 21, 22, 23, 24, 25, 26
        RM.extra2.idx0
            10
            18, 19
        RM.extra2.idx1
            01
            20, 21
        RM.extra2.idx2
            00
            22, 23
        RM.extra2.idx3
            00
            24, 25
        RM.extra3
            100100000
            18, 19, 20, 21, 22, 23, 24, 25, 26
        RM.extra3.idx0
            100
            18, 19, 20
        RM.extra3.idx1
            100
            21, 22, 23
        RM.extra3.idx2
            000
            24, 25, 26
        RM.ALL
            1
            12
        RM.SNZ
            0
            13
        RM.SL
            0
            25
        RM.SLu
            0
            26
        RM.LRu
            0
            30
        RM.sz
            0
            31
        RM.CTR
            0
            27
        RM.VLS
            0
            28

This produces RM 0b000010000010010000000000. However, the original code did
this:

-            sv_mode = ((bc_svstep << SVP64MODE.MOD2_MSB) |
-                       (bc_vlset << SVP64MODE.MOD2_LSB) |
-                       (bc_snz << SVP64MODE.BC_SNZ))
-            srcwid = (bc_vsb << 1) | bc_lru
-            destwid = (bc_lru << 1) | bc_all

This doesn't look like the correct thing (or at least it doesn't matches the
table, where LRu goes to bit 22 and ALL goes to bit 4; same with VSb and
(again??) LRu. For now it looks that the original code was incorrect, but I'd
like to have a confirmation on this guess.

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