target-arm: AArch32 Neon integer data processing and loads and stores

[tamnd]

Part of #8.

The first Neon slice for AArch32: the integer data-processing instructions, the loads and stores, and VMOV and VDUP between core registers and scalars. It covers A32 and T32.

• neon-dp.decode and neon-ls.decode are generated as for QEMU. T32 encodings are rewritten to their A32 form before decoding, as in translate.c.
• The integer ops include:
  • three registers of the same length, and three of different lengths
  • two registers and a shift, including the narrowing and long forms
  • two registers and a scalar
  • the two-register miscellaneous group without the FP ops
  • VEXT, VTBL/VTBX, VDUP (scalar), VSWP, VTRN/VUZP/VZIP
  • the modified immediates
• They run on the A64 vector helper through a new a32_neon helper, which maps D registers onto the Q registers. FPSCR.QC is set on saturation. Pair ops write Dm and then Dd, as QEMU does, so VTRN, VUZP and VZIP with d == m match.
• VLDn/VSTn cover all forms: multiple structures, single lane and all lanes, with writeback by size or by register. Alignment checks follow QEMU's finalize_memop in user mode, so a hint is checked and the default alignment is not.
• VMOV between core registers and scalars, and VDUP from a core register.

Not included: the FP ops (VADD.F32, the FP 2-reg-misc and the conversions), VRECPE/VRSQRTE, crypto, the neon-shared group, and the BF16 and dot product ops. They UNDEF for now. HWCAP_NEON stays clear until the next slice adds them, so glibc doesn't pick Neon routines.

Compared against QEMU 11.1 qemu-arm on server3:

• 10714 generated tests, one instruction each. They are random encodings in the dp and ls groups plus the VMOV and VDUP forms, with objdump's FP and crypto forms filtered out. The inputs are random and special D register values, and base addresses at offsets 0 to 32, so misaligned hints fault. The tests compare the changed D registers, FPSCR, the base and Rm registers, the memory written, and SIGILL, SIGSEGV and SIGBUS.
  • Built for A32 and for T32, so all 10714 run in both states. 6271 of them UNDEF on both emulators.
  • The output is identical in both states.
• A vectorized C program at -O1 and -O3 with intrinsics: vld3, vtbl3/vtbx1, saturating and rounding ops, vmlal_lane, vqdmlsl, zip/uzp and vpadd. It ran as A32 and as Thumb, and the output and the final FPSCR match.
• Hello and the VFP tests match.
• The signal tests differ from QEMU in the same way they did before this slice (already present at linux-user: arm kuser helpers, commpage and signal frames #333). In the same environment, one line differs: the CPSR GE bits in the handler. Change the environment size and the fault address can also move by 0x10. There are two causes, and both are in the loader:
  • ruvm doesn't provide AT_SYSINFO_EHDR yet, so the auxv is one 8 byte entry shorter and the initial stack sits 8 bytes higher. After 16 byte alignment that shows up as a 0x10 shift, depending on the environment size.
  • ruvm masks HWCAP (0x005fa0d7 against QEMU's 0x0fdfb0d7, HWCAP2 0x70 against 0x7f), so glibc picks other string routines. These leave different GE bits behind.
    The next slice addresses both, along with HWCAP_NEON.

All of the above ran on the merge commit e498d17 (this branch with main at 2a32ea6 merged in).

Checks, all on e498d17:

• fmt
• clippy -D warnings, native x86_64 Linux and cross for x86_64-pc-windows-gnu and aarch64-apple-darwin
• tests: ruvm-linux-user, ruvm-target-arm and ruvm-machine-arm (which include AArch64 system mode), and ruvm-system --lib
• the four xtasks: provenance, unsafe-audit, layers and style
• the release build of ruvm-cli