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.

[toothbrush7777777]

@autodidaddict The Raspberry Pi 3B, 3B+ and 4B can execute AArch64 (ARMv8) code.

[autodidaddict]

When I attempt to run an aarch64 binary on the pi3b+ it tells me it's the wrong file type. Does one need something other than stock Raspian?

$ file wascc-host 
wascc-host: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=f6aa49c6dd0106c9b069ed1c1e97de095d83fd89, for GNU/Linux 3.7.0, with debug_info, not stripped
pi@officelight:~/wascclight $ ./wascc-host 
-bash: ./wascc-host: cannot execute binary file: Exec format error

[bjorn3]

Stock Raspbian has a 32bit kernel, so it doesn't support 64bit binaries.

[autodidaddict]

Ok so it looks like I just need an os like Gentoo that gives me aarch64 userland on the pi3b+. Thanks for the info!

[toothbrush7777777]

@autodidaddict You can try the new beta 64-bit version of Raspberry Pi OS (https://www.raspberrypi.org/forums/viewtopic.php?f=117&t=27537) or use Ubuntu or Gentoo.

[julian-seward1]

FWIW, I have been running 64-bit Fedora 32 on my Pi 3B for months, maybe even a year, and it works just great. wasmtime, using the new aarch64 backend under development, works on it no problem.

[squillace]

Yup, some issues here and there remain for 32-bit builds:

error[E0308]: mismatched types
--> crates/environ/src/tunables.rs:65:34
|
65 | static_memory_bound: (10 * (1 << 20)) / crate::WASM_PAGE_SIZE,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected u64, found u32

[bjorn3]

Not just that, I believe the arm32 backend is too incomplete to do much useful.

[cfallin]

Indeed, the high-order bit is that the compiler backend on arm32 can only generate code for 32-bit operators right now, not 64-bit ones, and in general is pretty incomplete. There is some hope that the new isel framework could make this work easier to complete, but until then, mismatching types in the runtime are the least of our worries :-)

[akirilov-arm]

Note (@jmkrauz in particular) that in issue #3721 we are discussing potential removal of the 32-bit Arm backend.

[cfallin]

For completeness to keep this issue up-to-date: we indeed removed the halfway-complete ARM32 backend because, unfortunately, no one had the resources to bring it up to a Wasm-MVP level of completeness, nor maintain it as we continue to evolve the compiler. However, we would absolutely welcome a new contribution of ARM32 support, as long as (i) it starts at a relatively complete state, i.e., is usable to run wasmtime as-is; and (ii) has an active and interested community of contributors willing to help maintain it and resolve issues.