Embedded Swift

It is not clear to me, why print needs to be removed. Isn’t it possible to provide an alternative implementation, that would be “source code compatible” but would refrain from using Any (by taking advantage of pacs+macro combo)?

This is something I think we should really think about as part of the Embedded Swift movement. IMO Rust does this pretty well, with a distinction between std and core, and allowing you to substitute in pieces of std, allowing you then to access more and more abstractions on top of the pieces of std that you've replaced. Implement an allocator? Nice, you get fmt!().


There is a prototype, the images/videos are real, and we plan to add the functionality of the prototype under experimental flags into the compiler soon, so that it's available for early experimental use.


You can send the output to a particular stream. I use it for stderr. Some embedded platforms I’ve worked with had printf that would do nothing unless you provide your implementation. But the program would compile.

Yes, but fixed size Arrays are essentail for precisely those usecases where malloc is missing imo.

1 Like

It is not clear to me, why print needs to be removed.

There's no intention to remove print(), the vision document just states that we have to provide some alternative implementation (compared to what's in the stdlib today); and your suggestion is one possible option for that, yes.


One interesting intersection is where the artifact bundle definitions of sdks can interplay here. I could imagine that the definition could ferry along information of what type of restrictions are made. E.g. some restricted environments may not have malloc, but others may have full-on concurrency support. Targeting AVR wouldn't be able to have nearly as much available to it as say targeting ESP32-S3/H2.

This may need some alteration linguistically to support additional parameters to #if style guards (or something to that effect). A low level interface to bare metal systems is definitely useful, but it would also be interesting to consider what a more user-welcoming library space would look like too (not just the stdlib).

I see three layers of experiences that could be tackled here: platform engineering (folks bringing in new chips/boards etc), library engineering (folks building out the standard library or other under-pinning libraries for smol swift), and end use engineering (folks building products for that hardware). Each of those audiences have distinct needs, and there likely are tunings that can be focused on each of them.

To be honest - if done well this could be really exciting for many developers - not just large projects but to maker level projects too!

  • The types of thrown errors will be restricted in some manner, because thrown errors are of existential type any Error (which is disallowed by the prior item).

Sounds like this has Typed throws as a prerequisite?

#if os(Darwin), a shorthand for checking for Darwin platforms also seems relevant re. the need in Embedded Swift for # if checks against more complicated environment possibilities.

Not necessarily. There are other restrictions we could possibly place on errors that allow them to be propagated without requiring the full expressivity of general existentials. Typed throws might be a good feature in and of itself, but requiring its use in embedded Swift could be a pretty severe dialectization wedge. Our guidance for long-term stable APIs will likely still be to recommend untyped errors to allow for library evolution, and we'd want libraries that intend to target both desktop and embedded Swift to follow that guidance without having to diverge their APIs.


My 2 cents is that I'm perfectly willing to trade almost any language feature to squeeze onto a smaller chip... something Raspberry Pico / RP2040 size would be wicked. (ARM M0)


RP2040 is relatively powerful - to be honest I don't think many features really would have to be skipped.


That's wonderful but surprising news. Can I hear an ATtiny? (kidding, but honestly can't think of a single language feature I personally wouldn't be willing to give up to make it fit)


If one was really excited and wanted to reproduce the example the minute it was possible is this the board? https://www.st.com/en/evaluation-tools/32f746gdiscovery.html

Yup that's the one! In fact if you really really wanted to, you could build a custom stdlib for arm7em with the hermetic seal at link support @kubamracek mentions above, massage it into a swift sdk bundle and use swift package manager to recreate/build that demo.

swift build \
--configuration release \
-Xswiftc -target -Xswiftc armv7em-apple-none-macho \
-Xswiftc -experimental-hermetic-seal-at-link \
-Xswiftc -Xfrontend -Xswiftc -experimental-platform-c-calling-convention=arm_aapcs_vfp \
--experimental-swift-sdk stm32f746 \
--experimental-lto-mode full \

Note: this would be the 500kb version of the demo firmware mentioned above.


I wanted to draw some attention to the significant efforts already made over at Swift for Arduino: https://www.swiftforarduino.com

They've already got some great progress in compiling small code. I believe the implementation is more the subset of the language idea mentioned earlier, but I've used it a little myself and was thoroughly impressed.

It would be great to have their efforts mainstreamed, for sure!


RP2040 is my favorite maker chip too. It is really fast, just need to keep the binary sizes and memory use small. I have a few of them sitting on my desk.


To clarify - this should work with which branch(s) of Swift? I'm getting error: Unknown option '--experimental-lto-mode' when I tried to build an empty package (just to see). Do I need a enableExperimentalFeature setting somewhere?

FWIW I also tried a little mini project and swiftc main.swift -o hello_swift_blink -lto=llvm-full -experimental-hermetic-seal-at-link works fine, but the target, xfrontend, and -static-stdlib all seem dependent on getting the sdk linked first (as would be expected).

swift-driver version: 1.87.1 Apple Swift version 5.9 (swiftlang- clang-1500.0.40.1)
Target: x86_64-apple-macosx14.0

This is all going to be really nice with the C++ interop...

1 Like

Oops! I added the flag in this pr: BuildDescription: Set output path for bc files by rauhul · Pull Request #6611 · apple/swift-package-manager · GitHub but it has not been cherry picked into 5.9 so you will need to use a nightly toolchain until the spm change makes it into a release.


This is amazing! Thank you

We already have ATTiny working with Swift for Arduino. https://www.swiftforarduino.com. You can do it today. :slight_smile:


this is huge! my dreams from 2016 are coming true


You can't fathom the immense joy this brings me.

I have been dreaming about this for quite some time. Next to my iOS and Linux work, I'm doing my development on the ESP (Tensilica + RISCV) family with C(++) ­– being able to use Swift (and possibly share libraries) there would be heaven.

But not only that, I would imagine that this work would also lead to performance improvements on the desktop systems, so I'm all for it!