> On Aug 17, 2016, at 2:47 AM, Anton Zhilin via swift-evolution > <[email protected]> wrote: > > 2016-08-17 3:27 GMT+03:00 Roderick Mann <[email protected] > <mailto:[email protected]>>: > >> 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: http://stackoverflow.com/questions/24139149/how-do-i-create-a-packed-data-structure-in-swift <http://stackoverflow.com/questions/24139149/how-do-i-create-a-packed-data-structure-in-swift> > > > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
