Support for 32-bit CPUs

I know that 64-bit CPUs offer many advantages, and that the main one is that there are more unused bits in an object pointer, which lets compiler writers implement constant values like short strings, floats, integers and so on as just a pointer rather than a malloc'd chunk of memory. (Sometimes called a packed pointer.)
However 32-bit CPUs still exist and are widely used in the Linux realm e.g. in IoT, in single-board computers, and of course in older computers that haven't been abandoned.
What are the current reasons for Swift's not supporting 32-bit CPUs?
I did compile Swift for a 32-bit Raspberry pi and it got almost entirely through it before the last link phase which failed.

1 Like

Swift doesn’t not support 32-bit platforms. As an open source project, interested developers can certainly step up to maintain those ports.

In fact, we already support several 32-bit platforms, including both architectures of the Apple Watch. I believe supporting 32-bit Windows is also on the roadmap, although @compnerd can speak better to that.

In general, ports to other platforms are extremely welcome, and I think there are already people in the community working on Raspberry support.

4 Likes

@John_McCall is absolutely correct about the 32-bit support. In addition to the apple platforms, the Windows and Linux do support 32-bit targets.

The Windows 32-bit target needs some attention to address regressions, and is part of the roadmap. There isn’t as much benefit to the 64-bit on Windows unlike other platforms, and would be better served with improvements to the 32-bit target. The toolchain itself uses swift, and in order to improve the developer experience the majority of the focus has remained on the 64-bit target as that does benefit from the 64-bit support.

The Linux 32-bit targets also are in somewhat similar state with needing attention for addressing regressions. Using the android armv7 as a proxy for Linux armv7, which is still 32-bit, there’s only a couple of failures, so it should be possible to get things working. I had a couple of local patches for it, but @Buttaface actually independently had the same changes and actually was kind enough to work through upstreaming them.

The statement of “swift doesn’t support 32-bit” is not very accurate. The support is there in the toolchain, and improving that requires regular maintenance work which needs more engineering support due to competing priorities.

I maintain maybe the only 32-bit Swift 5.3 toolchain right now, available on any Android ARMv7 device running 7.0 or later, and @uraimo has been putting out 32-bit ARM builds for much longer. As Saleem says, 32-bit arches are supported but since not many are actively building for or maintaining those platforms, regressions have cropped up. I upstreamed the small patch I needed for Android ARMv7 last month (two of the changes were not Android-specific and fixed all 32-bit platforms) and if you share the link error you got, I'm sure that could be fixed too.

I use Swift on Raspberry Pi 4 every day in 64-bit mode.

2 Likes

We're building a ~15k line Swift library for macOS, iOS, Windows, Ubuntu, and Android at the moment. We are trying to round out our platform support before releasing the library for deployment along with a large software product on those platforms. We have good builds and CI/CD set up for macOS 10.13 and up, iOS v13 and up, Ubuntu 16.04 and up, Android 7 (32-bit & 64-bit) (thanks @Buttaface!) and up, and Windows 10 x86_64.

Since we have many users of the product, we had hoped to also release Windows 10 x86, as it appears we do have a small percentage of users on it. However I have not been able to get a development environment set up to compile for 32-bit. It also appears that the DLLs bundled with the official releases are all compiled for 64-bit.

How should I best invest time in trying to get a Windows 10 x86 build going? Use the existing binary toolchain release and cross-compile from Windows 10 x86_64? Build the SDK and toolchain from source? Another way?

This is intentional. I don't think that we should ever bother with a 32-bit toolchain for Windows. The toolchain should always be 64-bit, and you would cross-compile to 32-bit. The only piece that should be needed is the i686 SDK and runtime (for distribution and testing). The currently distributed Windows toolchain is already setup to support x86 target.

Windows x86 was supported a long time back. However, it currently is not possible to build. If you want to revive the target, the first "last" piece to be done is fixing LLVM. The LLVM code generation for x86 Windows currently does not handle floating point conversion correctly, and the result is that you cannot build the standard library for x86.

The next piece where I suspect that you will hit issues is with Foundation as I never actually built that for a 32-bit platform, and so there may be issues with value truncation that will need to be addressed, but that should be relatively easy to get working, and is a matter of just running through the test suite.

Wow! Thanks for the prompt reply! I will see how much effort I can get scheduled for 32-bit support given the percentage of current users. If / when I start trying to revive the target, I'll follow up.

We've unfortunately decided to skip Windows 10 32-bit support for now. Windows 10 64-bit, Ubuntu, macOS, iOS, Android are a pretty good list to start I suppose. If anyone does choose to take up the Windows 10 32-bit effort, please let us all know!

Terms of Service

Privacy Policy

Cookie Policy