Wasmtime GitHub notifications bot (May 04 2022 at 19:58): Wasmtime GitHub notifications bot (May 04 2022 at 19:58):cfallin edited issue #1980:
We don't currently have fully working x86 support, but we have a backend in-tree that's largely completely. However, it uses the old instructions selection framework, and as described in #1936, Cranelift is in the process of switching to a new one. While the old framework won't be removed until quite a bit later, that means that not much work will go into it anymore, and that any investments into backends based on it will become obsolete.
We should investigate the best approach to supporting x86 in the new framework.
There's active work going on to implement x64 support in the new framework, but no current effort around x86. In #1789 @whitequark mentions that she'd be happy to contribute to x86 support in the new framework, but only if the general support for targeting x86 exists.
@bnjbvr @julian-seward1, can you comment on what the best approach to take here would be? I understand that this isn't something that's high on your priority list, so as a first step we should just get a clearer picture of what this could look like, and the effort required.
Wasmtime GitHub notifications bot (May 04 2022 at 19:58):cfallin labeled issue #1980:
We don't currently have fully working x86 support, but we have a backend in-tree that's largely completely. However, it uses the old instructions selection framework, and as described in #1936, Cranelift is in the process of switching to a new one. While the old framework won't be removed until quite a bit later, that means that not much work will go into it anymore, and that any investments into backends based on it will become obsolete.
We should investigate the best approach to supporting x86 in the new framework.
There's active work going on to implement x64 support in the new framework, but no current effort around x86. In #1789 @whitequark mentions that she'd be happy to contribute to x86 support in the new framework, but only if the general support for targeting x86 exists.
@bnjbvr @julian-seward1, can you comment on what the best approach to take here would be? I understand that this isn't something that's high on your priority list, so as a first step we should just get a clearer picture of what this could look like, and the effort required.
Wasmtime GitHub notifications bot (Jul 12 2022 at 14:38):alexcrichton labeled issue #1980:
We don't currently have fully working x86 support, but we have a backend in-tree that's largely completely. However, it uses the old instructions selection framework, and as described in #1936, Cranelift is in the process of switching to a new one. While the old framework won't be removed until quite a bit later, that means that not much work will go into it anymore, and that any investments into backends based on it will become obsolete.
We should investigate the best approach to supporting x86 in the new framework.
There's active work going on to implement x64 support in the new framework, but no current effort around x86. In #1789 @whitequark mentions that she'd be happy to contribute to x86 support in the new framework, but only if the general support for targeting x86 exists.
@bnjbvr @julian-seward1, can you comment on what the best approach to take here would be? I understand that this isn't something that's high on your priority list, so as a first step we should just get a clearer picture of what this could look like, and the effort required.
Wasmtime GitHub notifications bot (Jan 15 2023 at 09:58):jain98 commented on issue #1980:
@tschneidereit @whitequark @cfallin @bjorn3 I would be interested in picking this up. I still need to dive deeper to come up with a concrete plan, but would one of you (or someone you could connect me to) be willing to mentor me?
Wasmtime GitHub notifications bot (Jan 17 2023 at 19:54):jameysharp commented on issue #1980:
Hi @jain98! We're always happy to answer questions and help however we can. I'd encourage you to join the
#craneliftstream at https://bytecodealliance.zulipchat.com/ as a good place to ask questions.Since all our current backends are 64-bit, we haven't necessarily designed everything to support 32-bit targets well. We'd like to fix that, but in the meantime just be aware that you may find some things are harder than they should be. There's been recent discussion about that in #5572, and the advice there applies here too.
Wasmtime GitHub notifications bot (Jan 22 2023 at 01:41):jain98 commented on issue #1980:
Hi @jameysharp, thanks for replying and a link to a recent discussion. I've already joined the cranelift zulip chat, but figured I'd start here as it seemed more intentional.
It at least looks like there's already an existing backend for x86-32, no? If yes, could you could point me to it? That might be a good starting point for me.
Wasmtime GitHub notifications bot (Jan 23 2023 at 19:45):jameysharp commented on issue #1980:
There used to be an x86-32 backend, but it was unmaintained and eventually got in the way of working on the rest of Cranelift, so it was deleted. If I'm reading the history correctly there have been at least two complete rewrites of how Cranelift backends are written since the last time that backend worked, so digging it up out of the git history probably won't help you much. Instead I'd suggest looking at the current x86-64 backend, which is mostly in
cranelift/codegen/src/isa/x64/.
Wasmtime GitHub notifications bot (Dec 20 2024 at 19:31):alexcrichton removed the wasmtime:platform-support label from Issue #1980.
Wasmtime GitHub notifications bot (Dec 20 2024 at 19:32):alexcrichton commented on issue #1980:
For those following this issue Wasmtime now supports 32-bit x86 via the Pulley interpreter which should now be able to run most wasm programs. Pulley is not 100% finished yet in that we still have some polish to do, but it should be suitable for testing at this time.
General support for Wasmtime on 32-bit x86 architectures should be "solved" now and if there are any issues please feel free to open a new issue, and this issue specifically will continue to track the addition of a 32-bit x86 backend for Cranelift.
Wasmtime GitHub notifications bot (Dec 20 2024 at 19:38):whitequark commented on issue #1980:
Oh, fantastic! From my perspective Pulley is probably good enough, since the failure case I'm trying to avoid is "YoWASP does not work"; if it works but is slow, I can print a message recommending to upgrade to a 64-bit Python.
(Is there a way to detect that Pulley is being used?)
Wasmtime GitHub notifications bot (Dec 20 2024 at 19:47):alexcrichton commented on issue #1980:
Not currently, but it'd be reasonable to add one for sure
Wasmtime GitHub notifications bot (Dec 20 2024 at 19:51):whitequark commented on issue #1980:
I'd really like to have that, since as I understand there is a ~10x perf degradation, which is fine in that it enables the capability, but this being someone's only impression without understanding that it's unusually slow wouldn't be good.
Last updated: Dec 23 2024 at 12:05 UTC