Obsolescent Platform Features

Platform
1

The Platform Steering Group agreed that we would provide some guidance for package and standard library maintainers as to platform features that we consider obsolescent and therefore not worth putting effort into supporting, the goal being to make it easier to develop and test code, and to lower the maintenance overhead by reducing the number of different permutations that maintainers must consider when writing new code or maintaining existing code.

As such, we consider the following to be obsolescent:

  • Big-endian byte ordering* †.
  • Non-eight-bit bytes.
  • Non-eight-bit C chars.
  • Non-IEEE floating point.‡
  • Non-ASCII-based character encodings (such as EBCDIC).
  • C int of less than 32-bits in size†.
  • Pointers (and thus Swift Ints) of less than 32-bits in size†.
  • Segmented addressing.**
  • Non-byte-addressable memory.††
  • Integer representations other than 2's complement*.
  • Representations of NULL other than all zeroes.

The Platform Steering Group would generally be opposed to adding official support to Swift for any platform that requires one or more of the above obsolescent features, and takes the view that it is not necessary for package authors, standard library maintainers, or indeed the core compiler itself to worry about supporting platforms that require those features.

Kind regards,

Alastair Houghton
Platform Steering Group

* This is specifically about the target platform and the built-in fixed-width types; it isn't a prohibition on types like BigInt using sign-and-magnitude or big-endian or even mixed-endian representations, or on having a BigEndianInt32 type, for instance, nor should it affect the need to use big-endian ordering or non-2's complement representations sometimes when serializing/deserializing data to disk or network.

† Except for the Embedded Swift variant of the standard library, which may support 16-bit pointers and ints as well as big-endian targets. Note that this does not extend to the Swift runtime or other libraries; those will be free to require 32-bit pointers as a minimum and may assume little-endian layout if they wish. Platforms with 16-bit pointers or that use big-endian layout may therefore need to supply their own runtime, and will generally require a 32-bit or 64-bit build machine.

‡ For primary CPU floating point, excluding long double; non-IEEE GPU and ML formats like NVFP4, FP8, BF16 and so on are fine.

** This does not preclude a platform using segmented addressing but supplying Swift with a flat memory map, nor does it preclude using a segment register as a base pointer for per-thread data or for other system-specific purposes that do not affect normal program code; the point is that Swift and its users will not have to deal with far pointers.

†† Platforms that are unable to access unaligned words are fine; this is about the ability to specify the addresses of individual bytes.

12 Likes
How to enable new CPU architectures for Swift?
2

Agree with dropping most of those old formats, but I'd like to point out that the last word has not been written on a couple of these:

My point is that just as we standardized on these machine widths and addressing schemes for most hardware over time, new tech is going to obsolete some of these standards also in time, so it would be good to not freeze these two if we can (I'm familiar with Swift's core support for Unicode, seemingly down to the ABI level, but I expect that that can be worked around).

3

To be clear, none of this is frozen in aspic. If in the future there is a shift to some other floating point standard, or to non-ASCII-based character encodings, we will be able to change our collective minds at that point.

Today, however, there is only one extant platform that uses non-IEEE floating point (IBM z/Series, which does have IEEE 754 support in addition to its own format). Historically there were many more (VAX, CDC, Cray, not to mention various software-defined formats for things like BASIC interpreters on smaller systems without dedicated floating point hardware).

Likewise, outside of special applications (primarily things like telephony and data compression), there is only one extant platform (again, IBM z/Series) using a non-ASCII-derived character encoding. Everyone else is using encodings based on ASCII, and frankly most people are using UTF-8 (non-Windows) or UTF-16 (Windows).

Note also that there is no reason you can't have e.g. a HexFloat32 or HexFloat64 type to hold IBM-style floating point, a PositFloat32 or PositFloat64 type to hold posit format floating point, or indeed a GSM7String or BaudotString type to hold strings in GSM-7 or 5-bit Baudot code. The point here is that, for now, we're saying it's reasonable for the compiler, runtime and standard library to assume IEEE 754 and ASCII-based encoding support on the platform. Indeed, I think we already do make those specific assumptions in various places, so we're just codifying existing practice here.

5 Likes
4

Would this guidance mean that we can remove support for big-endian systems from String, such as in the smol-string form?

2 Likes
5

Is Swift on Linux for IBM Z (aka s390x) not a concern anymore? That’s a big-endian architecture.

4 Likes
6

Are there not big-endian embedded architectures any more?

7

Of the items in this list, this is the only one that gives me pause. While Apple obviously hasn't supported 68K or PowerPC targets in oh god I'm old years, big endianness isn't obsolete. In particular, network byte order is big endian and so it's not uncommon for embedded networking hardware to use a big endian ISA.

Just gonna mention that the 32-bit Intel ISA is segmented, and even the 64-bit ISA has some segmentation support. :troll:

(I'm aware your footnote de facto accounts for this cruft.)

5 Likes
8

It's worth being clear that Float16, Float, and Double are the IEEE binary16, 32, and 64 types, regardless of what any hardware platform does or doesn't support. If someone implements an alternative floating-point scheme in hardware, we would provide some other type name to bind it on that platform, not bind these names with different semantics. So there's not even any need to call such a platform "obsolescent"--it's just orthogonal to Swift support and program semantics.

5 Likes
9

Any parts of String that are not supported by and will not be supported by Embedded Swift could drop big-endian support. The rest should keep it. You’d probably want to talk to @Douglas_Gregor to agree on what that means.

10

Again, I am doubtful about considering big endian “obsolescent.” Is the Platform Steering Group stating that the Swift project is officially ending support for Linux on IBM Z?

11

We don’t have official support for Linux on IBM Z, or indeed for z/OS so we aren’t “officially ending” anything. Further, if some third party wishes to work on a port to those platforms, nobody is stopping them.

12

Embedded Swift will continue to support big-endian hardware for that very reason. Network byte order isn’t a particularly strong reason to use big-endian architectures, mind, not these days at least. Plus a lot of newer hardware devices are themselves little-endian (mainly because PCI was defined as being little-endian), so while you might save on some byte swapping from network packets, you may then lose on having to byte swap to talk to peripherals.

13

Usage of Swift on Linux/s390x dates back to 2016, long before the formation of the Platform Steering Group or the formalization of platform support tiers. While it may not be a very popular platform for Swift today, it seems inaccurate to call the platform “obsolete,” and shortsighted to make intentionally breaking changes to the Standard Library that will prevent Swift from compiling for s390x out of the box. What third party would find that a welcoming environment to develop with, let alone maintain a big-endian fork of?

2 Likes
14

Which has been unmaintained since IBM stepped away AFAIK. Is there any activity on the port, people who are supporting it, and availability of releases, or at least signs that the compiler, runtime, and supporting libraries are being kept in working order?

We are not declaring the platform obsolete, rather that the computing model is not one that modern systems use. It is currently not even listed as an exploratory platform. If there is interest, with backing engineering resources, we can re-evaluate the situation.

One could argue the same for the Windows port. Doing that required changing many assumptions built into the system. That is a real cost of supporting a platform and one which must be paid in order to be supported.

I acknowledge this raises the barrier for entry for a select few environments, but it reduces the cost for the overall maintenance of the project. Consider the fact that none of the current maintained platforms support any means for easily testing the support because none of them support this configuration. It has become exceedingly rare to the point where it is uncertain that BE helps expand Swift into further environments but does incur a penalty. As stated previously, the support can be re-evaluated when there is an engineering reason to do so.

5 Likes
15

This is such a key point here. In theory, having everything in the standard library working for big-endian platforms could be nice. Personally, for example, I was happy to tweak my last PR so that it wouldn't unnecessarily rely on little-endian byte order. But there just isn't a practical way to test big-endian behavior, locally or otherwise; after staring at the code really hard, there was nothing to prove that I got it right.

So it simply isn't the case that Swift supports big-endian platforms now but will stop doing so because of this policy. Rather, numerous small and large problems have certainly accumulated in the project to make big-endian platforms already unsupported. To leave this state of affairs unacknowledged such that contributors might wonder about or spend effort to write new but untested big-endian code paths doesn't really make big-endian platforms any more supported.

13 Likes
16

Is there anything significant in the standard library or toolchain that actually cares about byte order? (compile-time big-endian ELF image output, okay sure, but that's maintained by LLVM and/or the linker and we don't need to make any claims about it at our layer). Is there a maintenance burden on us if we continue to "support" big-endian targets by… doing very little?

I was thinking hardware like switches, which only communicate with the outside world via Ethernet. I acknowledge that PCI cards will need to do at least some byte swapping before talking to the host. Anyway, I'm not a domain expert in the field of networking hardware so I won't pretend to have anything to back up my wild claims here.

1 Like
17

Yes, definitely. Not a lot, but e.g. the logic for manipulating small strings and some other low-level object representation stuff is endianness-sensitive. We can live with it, it's fine, but there is a small burden that comes with it.

18

"continue" what?

Who is doing this support?

Where is the CI server for big-endian currently hosted?

Who is fixing big-endian bugs?

If there is not some person doing this today, then it's not supported.

Tim

4 Likes
19

As such, we consider the following to be obsolescent:

  • Big-endian byte ordering* †.

That seems a bit hasty when there are capable big-endian machines to be
had and operating systems to run them.

  • Representations of NULL other than all zeroes.

Are you following the C compiler implementors here? Or has the ISO C
committee given up on non-zero NULL?

I thought that recent C standards still allowed for NULL representations
other than all zeroes, with C23 introducing an empty-initializer syntax
for structs that "properly" initializes pointer members to NULL.

David

1 Like
20

C does. LLVM does not, and Swift is very much entwined with LLVM. And for comparison, Rust does not either.

4 Likes