squillace commented on issue #1173:
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,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expectedu64
, foundu32
bjorn3 commented on issue #1173:
Not just that, I believe the arm32 backend is too incomplete to do much useful.
cfallin commented on issue #1173:
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 commented on issue #1173:
Note (@jmkrauz in particular) that in issue #3721 we are discussing potential removal of the 32-bit Arm backend.
cfallin labeled issue #1173:
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.
cfallin labeled issue #1173:
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.
cfallin commented on issue #1173:
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.
alexcrichton added the wasmtime:platform-support label to Issue #1173.
Last updated: Nov 22 2024 at 16:03 UTC