[swift-evolution] Swift for bare-metal programming

Rick Mann rmann at latencyzero.com
Tue Aug 16 15:07:14 CDT 2016

I'm not sure what effort is already underway to support this, but I'd like to be able to take advantage of Swift's inherent robustness to develop code for embedded devices without the benefit of an OS like Linux. I see at least two classes of such development: small and large embedded processors. "Large" ones typically have external DRAM and flash (think Beaglebone Black or Raspberry Pi), small ones have on-board DRAM and flash, and execute directly from flash. The smallest ones don't even have a RAM-based stack, and I'm not considering those. But there are a large number of small MCUs that can be programmed in C++, and it's those I'd like to eventually be able to target.

But to start, I'd like to be able to target the Beaglebone Black (TI Sitara AM335x ARM processor). On the swift-users list we talked about this a bit (Subject: "Swift in bare-metal embedded programming/Swift runtime"). Most of my initial questions centered on the Swift runtime and how bulky that might be, and about how to statically link a set of Swift files and the runtime into a monolithic block of code.

But then I remembered the need for something as basic as a "naked" function, one that could serve as an entry point for an interrupt vector. In GCC (and Clang, presumably), you can prepend "__attribute__ ((naked))" on a function declaration. You can then use those function names in the assembly file you build for the vector table.

There's also the need to be able to name a specific physical (perhaps virtual) memory address and do bit operations on them. In C/C++, this is relatively easy. Not sure how one would do this in Swift.

In a lot of embedded programming, one pre-allocates all memory so that the running program need not allocate and deallocate memory as it goes. This enhances reliability. It would be nice for Swift to support this, in that you'd want to be able to ensure the runtime isn't calling malloc when you don't want it to.

I'd eventually love to be able to write a real-time OS largely in Swift (with perhaps only startup code like the vector table and thread context switch code done in assembly).


Rick Mann
rmann at latencyzero.com

More information about the swift-evolution mailing list