Testing against big-endian and 32-bit cpus

Using Swift
1

I'd like to ensure some packages of mine work properly on big-endian cpus as well as 32-bit cpus. So I want to set up my GitHub Actions CI to run tests against a 32-bit and a big-endian cpu.

Any suggestions how I can achieve that?

I guess I could test against Android for 32-bit?
@Finagolfin does the Android CI workflows/SDKs run on 32-bit?

Still unsure how I can cover big-endian cpus. I'm hoping for some kind of Docker container that supports Swift and emulates big-endian but I'm also all-ears if the way to do this is more complicated than just picking a Docker container.

1 Like
2

This may be a question for the GitHub support team. I believe that their built-in VMs are all little-endian, but they may have some bespoke or niche solutions available.

3

The official Android workflows currently only cross-compile against the Swift SDK for Android, no testing yet. You can specify armv7-unknown-linux-androideabi29, or some other Android API level, along with other Android triples that you want to apply.

There are three other 32-bit platforms you could try with the Swift compiler: 32-bit Wasm, Windows i686, and 32-bit watchOS. I have never tried any of those, but they may be further along than Android armv7 right now, as they were available before an official 32-bit Android SDK.

Why? A little bit of web searching seems to indicate that almost nobody is supporting big-endian in software anymore, though the linux kernel can still be compiled to support it.

4

I don't have a usecase myself, but I recently had to introduce a 128-bit unsigned integer type to be able to support macOS versions lower than 15 in swift-endpoint (named it UnsignedInt128, intentionally a bit of a longer name so it maybe helps users to still choose Swift's UInt128 over using this type where available.).
(After this, I managed to get swift-endpoint to support macOS 10.15+ instead of 15+.)

Right now there is almost a 100% test coverage over the UnsignedInt128 which tests that type's behavior against Swift's own UInt128 on macOS 15+.
Some properties in UnsignedInt128 are endian-specific just like Swift's own UInt128, so I thought it'd be nice to be able to have the CI test those as well.

Also if you do e.g. withUnsafeBytes(of: myInt) { ptr in } then again being able to test correctness when the byte order is reversed would be nice.

5

FWIW, the last time I saw serious work to support Swift on big-endian systems was for the IBM Z series. For example, this. I don’t think that went anywhere )-:

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple

1 Like
6

I guess then the takeaway is to "don't even bother with big-endian". That's fine by me.

7

Some embedded boards using big endian still? (for Swift to bother)

I remember days when programming languages went extra mile supporting one-compliment architectures! (hence "SHRT_MIN Minimum value for an object of type short int -32767 (-2^15+1) or less". We are past that period. Now it seems we are also past the need for big endian support (other than for usages in network protocols).