[swift-evolution] Swift for bare-metal programming
charlie at charliemonroe.net
Tue Aug 16 23:35:44 CDT 2016
> On Aug 17, 2016, at 2:47 AM, Anton Zhilin via swift-evolution <swift-evolution at swift.org> wrote:
> 2016-08-17 3:27 GMT+03:00 Roderick Mann <rmann at latencyzero.com <mailto:rmann at latencyzero.com>>:
> >> 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 C on an Atmel MCU, it's done with macros:
> #define _MMIO_BYTE(mem_addr) (*(volatile uint8_t *)(mem_addr))
> #define DIDR1 _MMIO_BYTE(0x7F)
> In code, you can then write:
> DIDR1 = 0xXX;
> And that writes that byte to address 0x7F.
> In more sophisticated MCUs, a hardware peripheral will have several registers in memory, and they'll be defined by a struct in C. The base address of the struct is changed depending on which instance of the hardware peripheral you're talking about (i.e. there can be four USARTS, each with several bytes of configuration registers). Then the client code looks like (in C):
> USART1->BAUD = ...;
> USART1->CFG = ...;
> USART1->TXDATA = ...;
> Importantly, the struct members have no padding, and an instance of the struct is declared to exist at a specific memory address.
> Can that be done in Swift?
> Yes, using UnsafeMutablePointer. But I'm not sure about padding.
AFAICT, there is no way to create a packed struct in Swift. I was thinking about making a proposal for it, but there are fairly easy workarounds:
> > 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.
> It would be a shame to have to lose all that. I can still use classes in C++, even on very small MCUs. Sometimes I disable RTTI and exception handling because they cause a lot of bloat. I avoid the STL in some cases for the same reason. Calling malloc() isn't bad, you just want to know when it's called, and do that in your app's initialization, and not during the run loop (whatever form your run loop takes).
> Ok, you should be able to use classes, etc. You just won't be able to create new instances without heap allocation. Just as in C++. And for "classes on stack", we've got struct types.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution