[swift-evolution] Swift for bare-metal programming

[Anton Zhilin]

2016-08-16 23:07 GMT+03:00 Rick Mann via swift-evolution <
swift-evolution at swift.org>:

> 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").


This itself is not a question of SE, but rather of implementation for these
platforms. I guess, Apple engineers won't really want to do this work.

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.
>

`swiftc` already generates dependency-free executables.

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.
>

Agreed, something like `@export(demangledName)` would be useful.


> 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.
>

UnsafeBytes, UnsafePointer, UnsafeBufferPointer do this. Suddenly,
interaction with C gets more verbose, but it is also verbose in many other
"safe" languages.

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.


We could create a list of malloc-free standard library entities. Then if
you use only this subset of language, you'll be fine. Plus, no classes,
closures, `indirect`, and existential protocols.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160817/7250e465/attachment.html>