<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-08-16 23:07 GMT+03:00 Rick Mann via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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").</blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>`swiftc` already generates dependency-free executables.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>Agreed, something like `@export(demangledName)` would be useful.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>UnsafeBytes, UnsafePointer, UnsafeBufferPointer do this. Suddenly, interaction with C gets more verbose, but it is also verbose in many other "safe" languages.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.</blockquote><div><br></div><div>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. </div></div></div></div>