Fix aarch64 bitmask immediate encoding and implement some aarch64 instructions

[DukMastaaa]

File restructuring

To manage growth of file sizes when implementing more of the ARMv8 ISA, this PR splits the instructions implemented in aarch64.lisp into smaller files based on category:

• arithmetic
• atomic (CAS, CSEL and the like)
• branch
• data movement (load, store, move)
• logical
• processor state
• special (barriers, etc)

A full list of the instructions belonging to each category has been developed here.

aarch64 Bitmask Immediate decoding

Before this PR, running bap mc --arch=aarch64 --show-bil -- 20 00 7f 92 (assembly instruction and x0, x1, 2) incorrectly lifted the instruction:

{
  R0 := R1 & 0x7C0
}

The constant 0x7C0 appears in place of 2 due to ARMv8's "bitmask immediates" which encode immediate values for the logical instructions AND, ORR and EOR. This PR implements helper functions in Primus Lisp which decode these immediates using the algorithm from the ARMv8 ISA pseudocode, and updates the semantics of those logical instructions. Helper functions specific for aarch64 such as these have been moved to aarch64-helper.lisp.

Barriers

This PR represents the DMB, DSB and ISB barriers as external function calls using the new (special) primitive implemented in #1410. For example, running bap mc --arch=aarch64 --show-bil --show-bir -- bf 3b 03 d5 (instruction dmb ish) gives

{
  call(special:barrier:dmb:ish)
}
0000000c:
0000000b: goto @special:barrier:dmb:ish

Load-acquire and store-release

This PR represents load-acquire and store-release semantics using the (special) primitive like barriers described above. It's used in the implementation of CAS* instructions. For example, running bap mc --arch=aarch64 --show-bil -- 41 fc e0 88 (instruction casal w0, w1, [x2]) gives

{
  #0 := mem[R2, el]:u32
  call(special:load-acquire)
  #1 := #0 = extract:31:0[R0]
  if (#1) {
    call(special:store-release)
    mem := mem with [R2, el]:u32 <- low:32[extract:31:0[R1]]
  }
  R0 := #0
}

All CAS* instructions except the CASP* family are implemented in this PR.

Other instructions

Here are all the instructions that have been implemented in this PR.

• Arithmetic: SDIV, UDIV, MADD, MSUB
• Atomic: CSEL, CSINC, CSINV, CSNEG, CAS* except CASP*
• Branch: TBZ, TBNZ
• Data movement: STUR, STURH, STURB
• Logical: AND*ri, ORR*ri, EOR*ri
• Processor state: CCMN, CCMP, RMIF, SETF8, SETF16
• Special: DMB, DSB, ISB

Possible issues

Update: the below issues have been fixed with #1461; these instructions now work correctly.

LLVM can't seem to disassemble the RMIF, SETF8 and SETF16 instructions (try bap-mc --show-bil --arch=aarch64 -- "00 04 00 ba" corresponding to rmif x0, 0, 0). These three are part of ARMv8.4; perhaps LLVM does not implement this version? Since --show-knowledge output gives no information, the LLVM opcodes for these instructions in aarch64-pstate.lisp may be incorrect, and the semantics have not been tested yet.

Another ARMv8.4 instruction, CFINV, does get disassembled but gets turned into MSR (register) even though CFINV isn't an alias. --show-knowledge reports that LLVM returned msr 0x200 XZR for CFINV but this isn't even a valid opcode; both arguments of MSR (register) need to be registers. Not sure what's going on here.

[ivg]

The tests are failing with Unresolved function or primitive aarch64:CASordXr'and indeed I can only find a definition ofCASordX`. Maybe a typo?

Besides, you can run tests using make test

[ivg]

See #1461, it should enable instructions such as RMIF, SET8, CASX, and others that are available only in armv8.1a through v8.6a. Also, if you enable the "allow edits from the maintainers" checkbox on the pull request, then I can push fixes directly to your branch. But if you have reasons to keep it unchecked, then no worries, I can create pull requests.

[DukMastaaa]

Here's some things I noticed while fixing up the code:

1. Can the code for SETF8 be optimised in any way? Currently, the code outputs the following BIL for setf8 w0:

{
  NF := extract:7:7[extract:31:0[R0]]
  ZF := extract:7:0[extract:31:0[R0]] = 0
  VF := extract:8:8[extract:31:0[R0]] ^ extract:7:7[extract:31:0[R0]]
}

Maybe we can move the extract:7:0 into a local variable or something?

2. Is the output of the bitmask immediate code correct? Given the instruction and w0, w1, 3, BIL output is

{
  R0 := extend:64[extract:31:0[R1]] & 0x300000003
}

Just wanting to confirm that the leading 3 there will still zero out the upper 32 bits of R0, since we've zero-extended the bottom 32 bits then applied AND to the mask. This weird 30000... occurs for all immediate values with W registers but not X.

3. Every time I invoke bap mc to test lifter output, it tells me that '+v8.6a' is not a recognized feature for this target (ignoring feature). Is this anything to be worried about?

[ivg]

3. Every time I invoke bap mc to test lifter output, it tells me that '+v8.6a' is not a recognized feature for this target (ignoring feature). Is this anything to be worried about?

It looks like v8.6a is not supported by your version of LLVM. We need to be more careful when adding the features and consider the llvm version, I will work on the fix.

2. Is the output of the bitmask immediate code correct? Given the instruction and w0, w1, 3, BIL output is

Yep, looks like that it doesn't work for some reason for 32-bit version of instructions, see how llvm encodes them,

echo "and w0, w1, 3" | llvm-mc -triple aarch64 --show-encoding --show-inst
	.text
	and	w0, w1, #0x3                    // encoding: [0x20,0x04,0x00,0x12]
                                        // <MCInst #784 ANDWri
                                        //  <MCOperand Reg:186>
                                        //  <MCOperand Reg:187>
                                        //  <MCOperand Imm:1>>
                                        

vs.

echo "and x0, x1, 3" | llvm-mc -triple aarch64 --show-encoding --show-inst
	.text
	and	x0, x1, #0x3                    // encoding: [0x20,0x04,0x40,0x92]
                                        // <MCInst #786 ANDXri
                                        //  <MCOperand Reg:217>
                                        //  <MCOperand Reg:218>
                                        //  <MCOperand Imm:4097>>

So it looks like that ANDWri and ANDXri have different encodings, so we can represent both with log*ri. I am currently trying to figure out what kind of encoding is used on the W versions.

So I looked into the LLVM code, and they pass the bitness to their decoding function

/// decodeLogicalImmediate - Decode a logical immediate value in the form
/// "N:immr:imms" (where the immr and imms fields are each 6 bits) into the
/// integer value it represents with regSize bits.
static inline uint64_t decodeLogicalImmediate(uint64_t val, unsigned regSize) {
  // Extract the N, imms, and immr fields.
  unsigned N = (val >> 12) & 1;
  unsigned immr = (val >> 6) & 0x3f;
  unsigned imms = val & 0x3f;

  assert((regSize == 64 || N == 0) && "undefined logical immediate encoding");
  int len = 31 - countLeadingZeros((N << 6) | (~imms & 0x3f));
  assert(len >= 0 && "undefined logical immediate encoding");
  unsigned size = (1 << len);
  unsigned R = immr & (size - 1);
  unsigned S = imms & (size - 1);
  assert(S != size - 1 && "undefined logical immediate encoding");
  uint64_t pattern = (1ULL << (S + 1)) - 1;
  for (unsigned i = 0; i < R; ++i)
    pattern = ror(pattern, size);

  // Replicate the pattern to fill the regSize.
  while (size != regSize) {
    pattern |= (pattern << size);
    size *= 2;
  }
  return pattern;
}

Maybe it is better to implement it using the LLVM approach?

1. Can the code for SETF8 be optimised in any way? Currently, the code outputs the following BIL for setf8 w0:

Are you talking about nesting extracts that could be optimized away?

[ivg]

PR UQ-PAC#4 will resolve the conflicts and will make the decoding closer. It looks like we need to properly cast the immediate to 32 bits to get the correct result, though I am not very sure. Passing on the baton to you)

[DukMastaaa]

Thanks for the PR, it's merged in now.
After comparing the ISA pseudocode to the LLVM decoding code you sent, the issue was the result needs to be replicated to fill the width of the register we're operating on. I hardcoded memory-width as 64, but I've modified the functions to take register-width as an argument now like LLVM and it works correctly.

[ivg]

LGTM, thanks!

[ivg]

Thanks again, guys, for an awesome contribution!