windows: Support EMIT_X64/X86 with msvc toolchain #4699
Conversation
| @@ -0,0 +1,101 @@ | |||
| /* | |||
There was a problem hiding this comment.
This looks like a copy of unix/alloc.c with like 3 lines changed. In such case I think it's better to modify unix/alloc.c instead to make it work with windows builds.
|
Interesting, but not all Appveyor builds pass: the native_try/viper_try tests fail for the 64bit debug build |
| @@ -0,0 +1,75 @@ | |||
| /* | |||
There was a problem hiding this comment.
Same remark as the other file: I'm not sure there even is a functional difference with unix/gccollect.c?
There was a problem hiding this comment.
There's windows api used. I'm not sure it's ok to put them in unix folder. So I made a copy.
There was a problem hiding this comment.
If it's only a slight change, or a function which has the same signature in POSIX but just a different name, it's ok to do this I think. Else the way this has be fixed until now is to define our own implementation of the posix function (for example like is done for realpath/gettimeofday/opendir/...).
|
Any suggestion on the AppVeyor fails? I cannot reproduce it on my Windows 10. |
If you don't find an actual machine to reproduce it on, log in to Appveyor for your fork, adjust the settings to allow you to login with remote desktop (https://www.appveyor.com/docs/how-to/rdp-to-build-worker/) then start a build and login to the VM. |
|
I was thinking it's probably better to split this in separate commits: one for the changes to nlr, one for the other changes, because those 2 are basically unrelated (as in, first one can exist without the other) and that weill be easier to see what goes on. Maybe even a seperate commit for implementing alloc.c but that's maybe a bit too much. On the other hand it would still be easier to follow, imo. Also since nlr_jump is now available in assembly, wouldn't it be possible to use it instead of setjmp for collecting regs/stack as well (i.e. MICROPY_GCREGS_SETJMP put to 0)? |
|
Ok. I'll first fix the failed cases, and then split the commits with other changes to address review comments got so far. Thanks |
|
Thanks for the contribution. As @stinos says, it'd be best to not duplicate alloc.c/gccollect.c if they are basically the same as in the unix port. The unix port already has some And please do separate the changes to asmx64/emitnx64 into a separate commit, since they are logically separate (adding WIN64 ABI support to this emitter). If in doubt prefer more commits rather than less, since they can always be squashed together during merge if needed.
I think this test also fails on the unix debug build, maybe x86 (but that's not part of Travis). I think it's related to |
|
Closing due to inactivity. It's a nice feature so feel free to reopen and address review comments. |
The patches in this PR add support of MICROPY_EMIT_X64 and MICROPY_EMIT_X86 for msvc toolchain in ports/windows. They are enabled by default if building with msvc toolchain, but not with mingw and cygwin toolchain. It includes following changes:
The patches pass all test cases of tests/micropython/native_,viper_ on Windows.