classification
Title: Windows 10 ARM64 platform support
Type: enhancement Stage:
Components: Windows Versions: Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Paul Monson, Steven Noonan, paul.moore, steve.dower, steven.downum, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2018-03-23 01:03 by Steven Noonan, last changed 2018-08-10 18:37 by Paul Monson.

Messages (8)
msg314295 - (view) Author: Steven Noonan (Steven Noonan) Date: 2018-03-23 01:03
The Windows 10 ARM64 release is out along with a bunch of ARM64 devices. This version of Windows has full support for building native Win32 applications (this isn't just some rehash of Windows RT). It also can run x86 (but not x86_64) apps under a transparent emulation layer.

I would like to see a native build of Python on Windows 10 ARM64.

I did some very basic work to get it compiling (add 10.0.16299.0 as DefaultWindowsSDKVersion, add WindowsSDKDesktopARM64Support property). But there's still a lot missing: ssl, tk, and ctypes don't build.

ssl/ctypes have some assembly that needs writing/porting.

tk has some kind of build failure with the newer Windows SDK: https://core.tcl.tk/tk/tktview?name=3d34589aa0
msg314296 - (view) Author: Steven Noonan (Steven Noonan) Date: 2018-03-23 01:07
Oh, another change I had to make was remove all the BaseAddress elements in the Link sections. The linker complains if these are used (the lower 4GB of memory are apparently reserved for the x86 emulation). Also, from what I was told by someone over at Microsoft, the BaseAddress options don't do anything useful on modern Windows versions unless you build with -fixed as well, because everything gets relocated anyway.
msg314308 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-03-23 13:10
I'd like to see this as well, but just to set expectations, it can't be any earlier than 3.8 at this stage (for upstream support), and we need access to some real hardware to regularly run tests on.

That said, most of the changes you describe are on my list of things to do anyway. If you've done them and would like to submit a pull request (against master) then we'll happily take them now and include them in 3.7. But you'll still need to build the ARM versions yourself.
msg314309 - (view) Author: Steven Noonan (Steven Noonan) Date: 2018-03-23 13:26
I originally tagged this issue against 3.6 just because that's what I was attempting to build. But I'm not super concerned about what release these changes actually land in, I can always backport it to my own builds (and at my own risk).

Even though I'm super interested in seeing these changes done, I'm not sure I'm the right person to do the heavy lifting on this. I don't know if the seemingly undocumented (?) Windows ARM64 ABI matches the well-documented Linux AArch64 ABI, for example. If it does match, that would make porting the asm bits pretty straightforward (mostly just translating GNU assembler AT&T syntax to MASM, I suppose). I could do that. But if it doesn't match then I'd probably need to dig into ARM architecture manuals. Someone else could likely do it in their sleep.
msg314311 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2018-03-23 16:11
Ideally, all of the changes necessary in OpenSSL, libffi, and Tcl/Tk will happen upstream and we'll just update to new versions of them.  We have PR 3806 in progress to extract libffi from our repo and treat it just as any other external dependency on Windows, but neither Steve nor I have had a chance to work on it in quite a long time.  That will probably be a prerequisite for properly supporting ARM64 Windows.
msg323310 - (view) Author: Paul Monson (Paul Monson) Date: 2018-08-09 02:19
I'm interested in getting python working on Windows running on Raspberry Pi (Thumb-2 instruction set).  I can also contribute to ARM64 Windows.  I've made some progress getting ARM32 working on a fork.  The next roadblock for my investigation is libffi support for ARM32 on Windows.  Can I help with that?
msg323368 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-08-10 13:03
If libffi already has support and just needs to be updated in CPython, then sure. I thought we'd finished extracting it, but Zach posted aPR link above that apparently still needs finishing.

However, if libffi doesn't have the support yet then you'll have to approach them.
msg323382 - (view) Author: Paul Monson (Paul Monson) Date: 2018-08-10 18:37
The PR hasn't changed since September.  Is it still active? 

Should I consider updating the libffi_msvc code to support ARM32 in Python?  Completing the switch to libffi makes more sense to me.

I fetched the PR code to my fork and rebased it on the current master branch.  When I run python -m test there are 2 tests that fail.  Is that what's holding the PR up? or is it something more?  I'm new to the Python codebase but I can try to help debugging if the failing tests are the issue.
History
Date User Action Args
2018-08-10 18:37:04Paul Monsonsetmessages: + msg323382
2018-08-10 13:03:58steve.dowersetmessages: + msg323368
2018-08-09 02:19:18Paul Monsonsetnosy: + Paul Monson
messages: + msg323310
2018-03-23 16:21:29steven.downumsetnosy: + steven.downum
2018-03-23 16:11:21zach.waresetmessages: + msg314311
2018-03-23 13:26:14Steven Noonansetmessages: + msg314309
2018-03-23 13:10:04steve.dowersetmessages: + msg314308
versions: + Python 3.8, - Python 3.6
2018-03-23 01:07:22Steven Noonansetmessages: + msg314296
2018-03-23 01:03:31Steven Noonancreate