[swift-evolution] Swift for bare-metal programming

[Anton Zhilin]

2016-08-17 3:27 GMT+03:00 Roderick Mann <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.


> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160817/c66af556/attachment.html>