[Libre-soc-bugs] [Bug 950] pysvp64asm: support insndb-based assembly for SVP64 instructions

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sun Jan 15 15:54:21 GMT 2023


--- Comment #15 from Dmitry Selyutin <ghostmansd at gmail.com> ---
There are 4 failures so far in disassembler test when the new assembly is used.

1. test_4_sv_crand: I have no idea how to encode `sv.crand/ff=XX`. What I see
in pysvp64asm contradicts to https://libre-soc.org/openpower/sv/cr_ops/ page.
Please visit
to check. Please update the fields to reflect the `mode |= failfirst << BO_MSB`
combination. But I suspect all fields in the specs must be revisited. There's
no RC1 field at all in the spec at CR ops.

2. test_20_cmp fails at `sv.cmp/dz/ff=RC1/m=r3/sz *4,1,*0,1`. It doesn't look
like we're able to use dst-zero at either ff or pr modes.

3. test_16_bc fails at `sv.bc` instructions. These are likely mismatched due to
the fact that they are not usual entries. We generally keep unprefixed
instructions in both markdown and CSVs; `bc`, however, is a different beast. Is
it possible to make it follow the well-known convention? If not, I'll have to
add some hack into lookup, say, check `sv.XX` explicitly and, if `sv.XX` is
found in markdown, emit these as separate records. I'd rather prefer to follow
the standard convention, though.

4. test_15_predicates fails on `sv.extsw/dm=eq/sm=gt 3,7` instruction.
According to pysvp64asm, it should have failed before: extsw is P2, and we
cannot have different twin predicates.

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

More information about the libre-soc-bugs mailing list