Currently our support for RA_OR_ZERO and RT_OR_ZERO leaves much to be desired. These, when 0 is supplied as an operand, should yield 0, not r0, as usual RA and RT operands do. 1. openpower-isa disassembly doesn't diagnose these correctly at all, and treats them as usual GPRs. 2. binutils lack RT0 operand, the only instruction using RT0 is setvl, and support for this operand has been missing. More details in IRC: https://libre-soc.org/irclog/%23libre-soc.2023-05-29.log.html#t2023-05-29T16:37:17.
apologies, this is just something that "fell through the gaps".
This task has really evolved. Below is the list of instructions which don't pass the check[0] for different extras: rlwimi rlwimi. fishmv rldimi rldimi. [0] https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_insn.py;h=41a0c88e88f7dbeb21ef8df15b2e2205e20b196f;hb=refs/heads/master#l1269
This error doesn't stops this task, it's just that this task helped to find this problem.
I had to refactor operands and extras relationship, but now it works. No new failures in master for test_pysvp64dis, but I'll wait for CI. 17 new commits in extras branch (some are minor, though, just a style): https://git.libre-soc.org/?p=openpower-isa.git;a=shortlog;h=refs/heads/extras. Luke, this task definitely deserves a budget, but I have no idea where to take it from. Could you take a look, please?
No new failures on extras branch compared to the master. extras: https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/jobs/4265682 master: https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/jobs/4265458
The implementation is pushed into master. The rebase didn't cause any conflicts.
(In reply to Dmitry Selyutin from comment #3) > This error doesn't stops this task, it's just that this task helped to find > this problem. ok i have it. * there is no specifying "None" in the 4 Indexed areas * therefore the value "0" is being detected/treated as "valid" * but it contains corrupted data elif insn_name == 'rlwinm': # weird one, RA is a dest but not in bits 6:10 res['0'] = 'd:RA;d:CR0' # RA: Rdest1_EXTRA3 res['1'] = 's:RS' # RS: Rsrc1_EXTRA3 that's valid. * *only* position Idx0 is valid * *only* position Idx1 is valid positions Idx2 and Idx3 are *not* valid and i think what is happening is that "because not zero equals active": line 1227 if spec != 0: vector = bool(spec[0])