2016-08-16 23:07 GMT+03:00 Rick Mann via swift-evolution < [email protected]>:
> 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.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
