Hi folks,
The Platform Steering Group has been working on a statement about obsolescent architectural features that we don't feel the Swift compiler, Swift runtime and Swift standard library should support.
One thing that has come up and that we wanted to ask the community about is 16-bit support. Are there platforms with 16-bit pointers that we think we might care about? How about 16-bit int?
Kind regards,
Alastair Houghton
Platform Steering Group
Microcontrollers with 16-bit addressing are still very common. Whether or not the Swift community and the PSG want to support them (as Embedded Swift targets, presumably) is its own separate question.
There's been an ongoing third-party Swift on AVR8 toolchain effort, which has a 16-bit address space: Swift For Arduino Community · GitHub
Even 8-bit microcontrollers are still in wide use. https://www.microchip.com/en-us/products/microcontrollers/8-bit-mcus
Aren't those small number formats a thing in AI in these days? For quantizing models and such? Or am I barking up the wrong tree?
Support for small number formats like bf16 and float16 is orthogonal to the architecture's word size. I'm not aware of any AI processors with 16-bit addresses; that would actually be very problematic, because models are generally much, much larger than 64KB even if they use 16-bit weights.
Indeed. I think there's a strong argument these days though to default to using a 32-bit MCU; ARM Cortex-M0-based devices are very cheap (as low as 18¢ in quantities of 1,000 according to Digikey) and considerably more capable than their 8-bit and 16-bit brethren, and I think are much more likely to be targeted by people who want to use Swift.
(I'd acknowledge that there might still be some applications for 8-bit and 16-bit MCUs, particularly for people with legacy codebases, but if we further restrict ourselves to devices that could conceivably and reasonably run Swift code, I think that, at least for new hardware designs, it would make sense to go 32-bit.)
Indeed, I was concerned about that one specifically. What we were thinking is that we might make 32-bit pointers and integers a minimum requirement for a platform to be officially supported.
@carlos4242, the AVR toolchain has its own separate standard library and presumably isn't necessarily compatible with any given Swift package?
I think there's a difference here between what the compiler can generate code for and what the runtime and standard library need to support.
The question here is specifically about pointers and integers. We're aware of the small floating point formats (and indeed the non-standard larger ones).
Swift for Arduino is now run by @pdshelley, @axello, @randomeizer and @Swany , so I'll let them chip in about how they feel.
From what I know, it's still an active product, they have internships, daily meetings, ongoing projects and they have a lot of exciting and fun work going on (they can tell you... I encourage them to talk about all the things they're doing on the Swift Forums, don't be shy!)
From a technical viewpoint, I would guess they don't mind what is done, so long as it still works! The way I left it when I handed over to them in the fall of last year, their IDE uses...
a custom fork of the swift compiler... this is very close to the mainstream compiler (or was as of around october), essentially it's just https://github.com/swiftlang/swift/pull/78810/changes which is important, and a couple of lower priority extra features that are somewhat helpful for AVR (interrupt handlers and string interning in flash memory)... these could maybe technically both be done in C instead if need be, with a bit less nice user experience
a custom, minimal standard library, suitable for very limited resource microcontrollers this is based on the normal standard library but heavily trimmed and customised
a custom, super minimal runtime, with embedded swift mode this is barely used nowadays
...the compiler fork is public/open source. The custom standard library/runtime were meant to be open sourced. All the other projects built in their toolchain (e.g. swift-driver) are just standard mainstream, no other patches/fixes remain in their tools.
Before I handed over I had planned to...
land PR 78810 upstream
separate out the custom standard library/runtime and make it open source
work with the community to decide how to handle their extra features, either remove those features if they're not needed/used much, or if there's a helpful way they can be contributed to the main compiler... ultimately changing their IDE to use a compiler built from swiftlang/swift instead of a fork
once done, update their build engine to be able to switch between using the custom standard library and the normal standard library, to give people the choice depending on the needs of their project
...unfortunately, I ran out of time to achieve those goals before I handed over to the current board of trustees. I think the first three aren't a lot of work and I will get round to them one day... the only issue from this approach is it sounds like the last one might not be possible, if 16-bit support is removed from the standard library.
Hi, I'm one of the contributors to the Swift for Arduino project. I think @carlos42421 outlined the technical issues well with our project. I personally would like to see continued support for 16-bit.
While I do agree with some of what was said about many new MCUs being 32 bit there is still a lot of 8 bit microcontrollers in use, particularly in education and hobby markets where many people get their start. That being said I think it's an oversimplification to say that you can get 32 bit MCUs for very cheap, many of the very low cost 32 bit chips don't come with certifications or other less obvious considerations that are taken when selecting components.
I am actively working on expanding support for our tools to 32 bit. It's hard to have tools that only work with subset of MCUs because many organizations have some strange requirements or use multiple MCUs in products. I also want to allow for switching between MCUs more easily.
It is also notable that Rust still supports 16 bit. My dream is for Swift to be a contender for memory safe languages in embedded systems.
That's a fair point. To me, it doesn't seem farfetched to say that 16-bit platforms are supported only as embedded Swift targets, which would mean that the full runtime and most of the standard library could still assume a minimum 32 bits.
Another possibility is that we say that we maintain an IP32 programming model even on 16-bit platforms, so that Int is always at least 32 bits, and we maintain the sizeof(Int) == sizeof(*Pointer) invariant, at the cost of having to move some useless bytes around on narrowed CPUs. That might be a bit weird but would make the programming model for smaller microcontrollers more consistent.
Oh, quite — there's more to consider than just unit cost, and the 18¢ Cortex-M0 is admittedly a random Singaporean one, but for 30¢ you can have a Ti part, and another few cents will get you an STM32. The cheapest I can see for a 8-bit ATTiny is 42¢.
I think my point is more that, at least for new designs, going 8-bit or 16-bit is unlikely to be a cost-saving in and of itself.
FWIW, I think a lot of us share that enthusiasm.
What we're really trying to drill into in this thread is to what extent should the standard Swift distribution support 16-bit things, remembering that there is a maintenance cost involved and if we claim to officially support things we should probably at least make some nod towards testing them 
That's my current thinking, certainly; I'm interested to know what the Arduino crowd feel about that. They currently have their own runtime/standard library, which I think is in some senses a hint that this might be a reasonable place to land.
I would really like to hear from people who work in embedded systems design and procurement before basing this decision on publicly advertised unit prices of off-the-shelf parts. I think we might have access to a few of those people.
I completely agree with this, and to be honest I am not very deep into the compiler or language tooling itself and have been focused more on libraries and tools so take anything I say with a grain of salt.
In general I still think 8 bit MCUs have their place but I will acknowledge that they are on their way out. My assumption is that the official Embedded Swift stuff would only ever support 32 bit and above. This makes sense as I think we can all agree that this is where the growth is. I do think there is value to supporting more constrained environments because I think this generally pushes for the product to be better.
I'll leave this quote I like here from Dan Formosa: "...If we understand what the extremes are, the middle will take care of itself.”
I'd also like to voice my opinion on this subtopic: in my opinion, imported C types should generally be supported regardless of which Swift types they map to. CInt could be 16 bits on an otherwise supportable system (and there are historical 32-bit systems that evolved from 16-bit systems and make their int 16 bits for historical reasons). That shouldn't really impact Swift at all because Swift doesn't use CInt except to interface with C code that uses int.
(Pointer width being equal to Int width, on the other hand, is an invariant we shouldn't break, but Int ≠ int so it's orthogonal to my previous screed).
Please explain why not... in C there's ptrdiff_t which might not match int, can't Swift be the same way?
Int in Swift is equivalent to intptr_t today. That's an invariant for the stdlib and a lot of downstream code.
If this was doable, that would be quite acceptable. Recent improvements to Swift like InlineArray and some (still unofficial) support for volatile register access has made life simpler for embedded devices, in particular the 16-bit ones which are even more constrained. It's so close to being usable without any shims, would be great if we could get it all the way there.
I'm not aware of any/many 16-bit MCUs, but it seems like to me that if Swift wants to support them it should be with Embedded only. I actually don't know if Linux would even run on many 16-bit targets anyways, so it would make sense.
AVRs and PICs are available in 16-bit versions; there are some others too (Renesas RL78, Ti MSP430, Rohm ML62, likely some enhanced Intel 8051 derivatives as well).
As far as Swift is concerned, at the moment I think everything aside from AVR is theoretical?
It sounds like everyone is roughly on the same page here, so, we think:
That means building code for 16-bit platforms will be possible in Embedded Swift mode, while providing us with the ability to rely on having at least 32-bit pointers/integers for the rest of the codebase.
Would keeping support for 8-bit in embedded only be worth the effort? There are still some devices around.