jmkrauz opened Issue #1342:
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 commented on Issue #1342:
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 bit encoding or abi level to need a separate issue?
bjorn3 edited a comment on Issue #1342:
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 commented on Issue #1342:
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 commented on Issue #1342:
I was referring more 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.
bjorn3 edited a comment on Issue #1342:
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 commented on Issue #1342:
On arm differences are much bigger, encodings are definitely different.
jmkrauz edited a comment on Issue #1342:
On arm differences are much bigger. Encodings are definitely different.
julian-seward1 commented on Issue #1342:
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 commented on Issue #1342:
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 commented on Issue #1342:
Ok, I will wait then.
alexcrichton transferred Issue #1342:
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.
Last updated: Nov 22 2024 at 16:03 UTC