Cranelift: arm32 support

[jmkrauz]

• What is the feature or code improvement you would like to do in Cranelift?
  I would like to add ARM support by implementing ARM (not Thumb) encodings/recipes and abi. I am especially interested in armv7 little endian support.
• What is the value of adding this in Cranelift?
  Emit code that could run on ARM architecture.
• Do you have an implementation plan, and/or ideas for data structures or
  algorithms to use?
  At first i want to add basic integer operations followed by floating point instructions. I thought about implementing the latter using VFP rather than the NEON extension (As far as I know NEON does not support double precision). As for calling convention, I would like to implement AAPCS.
  I already have some code that i hope to push after necessary modifications.
• Have you considered alternative implementations? If so, how are they better
  or worse than your proposal?
  No, but I am open to suggestions.

[bjorn3]

There is already an issue for arm64 support: https://github.com/bytecodealliance/cranelift/issues/719. Should this be merged, or is arm32 different enough at instruction encoding or abi level to need a separate issue?

[jmkrauz]

I don't know much about arm64, but I believe there are some important differences (for example on arm64 NEON supports double precision). However if someone thinks it should be merged, feel free to do it.

[bjorn3]

I was referring to which bits represent an instruction. For x86/x86_64 the difference is small. Instructions with 32bit registers are often the same on x86 and x86_64, and the 64bit register variant just needs an extra byte (rex). I don't know if arm has something similar.

[jmkrauz]

On arm differences are much bigger. Encodings are definitely different.

[julian-seward1]

arm32 and arm64 are majorly different, both architecturally and at the encoding level. I'd suggest that attempts to unify them will lead to big problems, and it would be easier to treat them as two completely unrelated architectures.

Also, it's worth being aware that arm32 has two different encodings: the traditional ARM encoding, and the newer Thumb2. It will be necessary to choose one or the other, and I believe the standard recommendation is to use Thumb2.

[cfallin]

We're building a new instruction selector infrastructure (#1344), so it would likely be best for new backends to be built once that is ready (the hope is to land it in the next month or two at most!). As part of the work, we're building an ARM64 backend as well; this is quite different from ARM32, as Julian mentions, but it could serve as an example for someone building out an ARM32 backend.

[jmkrauz]

Ok, I will wait then.

[squillace]

Hi all; what's the status with ARM32/ARM 64? It appears that #1344 was merged. Love to use wasmtime on Pis..... and I thank you for your efforts here.

[bjorn3]

As part of #1174 an ARM backend is being developed. It may take a while before it is complete enough to be merged into master, as #1174 is a big change to Cranelift. Deveopment happens at the https://github.com/cfallin/wasmtime/ fork if you want to try it. Discussion happens at https://bytecodealliance.zulipchat.com/#narrow/stream/225524-cranelift-new-backend

[toothbrush7777777]

It appears that AArch64/ARM64 support was merged in #1494.

[tschneidereit]

Indeed! \o/

Note that it's not yet entirely complete, and not passing the entire test suite. It's getting close, though!

[autodidaddict]

Just dropping in here to check on whether there's a timeframe for when armv7 compilation might be supported? This basically includes 95% of the Raspberry Pis on the market today. aarch64 (as far as I've been able to determine) is only applicable to the Pi4s, and only then if you've managed to install the 64-bit Raspbian.