Wasmtime GitHub notifications bot (Apr 27 2020 at 21:55): Wasmtime GitHub notifications bot (Apr 27 2020 at 21:55):whitequark commented on Issue #1089:
I'm very interested in seeing this issue fixed, since it has a significant impact on the usefulness of wasmtime-py; if you navigate to python.org on Windows, either 32-bit or 64-bit, it always suggests you a 32-bit Python build, so most people certainly end up with 32-bit Python that cannot run wasmtime.pyd. Not only that, but the link to the 64-bit installer is somewhat hard to find, and there AFAIK isn't a redirect I can send to people to ask them to install 64-bit Python that is compatible with wamtime-py.
Could one of the developers more familiar with the codebase provide some guidance? I've tried running a few WASI applications with wasmtime targeting i686 Linux but they all crash with a register allocator issue that only ever mentions x86_64 registers (
rax, etc) so I'm not sure if I'm doing something seriously wrong.(I do understand that a Windows port is more complex--I've heard that SEH is going to be involved--but even an i686 Linux port would be useful, both on its own and as a starting point.)
Wasmtime GitHub notifications bot (Apr 27 2020 at 21:55):whitequark edited a comment on Issue #1089:
I'm very interested in seeing this issue fixed, since it has a significant impact on the usefulness of wasmtime-py; if you navigate to python.org on Windows, either 32-bit or 64-bit, it always suggests you a 32-bit Python build, so most people certainly end up with 32-bit Python that cannot run wasmtime.pyd. Not only that, but the link to the 64-bit installer is somewhat hard to find, and there AFAIK isn't a redirect I can send to people to ask them to install 64-bit Python that is compatible with wasmtime-py.
Could one of the developers more familiar with the codebase provide some guidance? I've tried running a few WASI applications with wasmtime targeting i686 Linux but they all crash with a register allocator issue that only ever mentions x86_64 registers (
rax, etc) so I'm not sure if I'm doing something seriously wrong.(I do understand that a Windows port is more complex--I've heard that SEH is going to be involved--but even an i686 Linux port would be useful, both on its own and as a starting point.)
Wasmtime GitHub notifications bot (Apr 27 2020 at 22:00):whitequark edited a comment on Issue #1089:
I'm very interested in seeing this issue fixed, since it has a significant impact on the usefulness of wasmtime-py; if you navigate to python.org on Windows, either 32-bit or 64-bit, it always suggests you a 32-bit Python build, so most people certainly end up with 32-bit Python that cannot run wasmtime.pyd. Not only that, but the link to the 64-bit installer is somewhat hard to find, and there AFAIK isn't a redirect I can send to people to ask them to install 64-bit Python that is compatible with wasmtime-py.
Could one of the developers more familiar with the codebase provide some guidance? I've tried running a few WASI applications with wasmtime targeting i686 Linux but they all crash with a constraint issue that only ever mentions x86_64 registers (
rax, etc) so I'm not sure if I'm doing something seriously wrong, see below.block0(v0: i32 [ss0], v1: i32 [ss1], v94: i32 [%rbp], v95: i32 [%rdi]): [Op1ld#8b,%rax] v90 = load.i32 notrap aligned v0 ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ; error: inst112: Op1ld#8b constraints not satisfied in: v90 = load.i32 notrap aligned v0 function u0:15(i32 vmctx [0], i32 [4], i32 fp [%rbp], i32 csr [%rdi]) -> i32 fp [%rbp], i32 csr [%rdi] system_v {(I do understand that a Windows port is more complex--I've heard that SEH is going to be involved--but even an i686 Linux port would be useful, both on its own and as a starting point.)
Wasmtime GitHub notifications bot (Apr 28 2020 at 08:27):tschneidereit commented on Issue #1089:
Thank you for bringing this up, and for starting to work on it!
I at least wasn't aware of the unfortunate situation with 64-bit Python on Windows, which I agree makes this more important.
One thing to be aware of is that we're in the middle of a pretty big change to Cranelift, involving a rewrite of the instruction selector (and register allocator, but I don't think that's too important here.) I'm not sure how that factors in, but @cfallin, @bnjbvr, or @julian-seward1 would.
Wasmtime GitHub notifications bot (Apr 28 2020 at 10:20):bnjbvr commented on Issue #1089:
Hi @whitequark and thanks for working on it!
As Till pointed out, we're in the middle of switching the instruction selection and codegen backends in Cranelift. As a matter of fact, we're rewriting the codegen bits, which include recipes/encodings and all of this, to a simpler and more straightforward system (see for example the new
aarch64directory undercodegen/src/isa).At this point, the current meta system should be considered in maintenance-only mode. Note that since the two codegen backend frameworks are very different, we won't be able to port x86 32 bits changes to the old backend onto the new backend, so this work will likely be thrown away.
Since there might be some time until we get to the final switch to the new system (and plain removal of the previous one), I don't think we should get in the way of good will. Meaning that if people want to submit patches, and other people want to review them, this is totally fine; this is useful up to the point where we switch to the new system.
Note there is a work-in-progress PR for a new x64 backend. This code could be a great base for a new x86 32-bits backend too, duplicating code for a new codegen backend, or sharing and reusing most of the x64 code there.
Wasmtime GitHub notifications bot (Apr 28 2020 at 14:48):whitequark commented on Issue #1089:
Ah, I see. In that case I would probably not put any effort towards a Windows port until the x64 backend is ready.
Last updated: Oct 23 2024 at 20:03 UTC