http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #15 from Johannes Pfau <johannesp...@gmail.com> --- > Didn't knew about this proposal It's not yet been announced/discussed, though I'll probably start a discussion on the newsgroup this week. > but it's flawed IMO, because > read-modify-write operations might get interrupted. So you do need atomic > updates for volatile data that is accessed from an interrupt handler. Adding > a > type qualifier for memory mapped I/O is overkill IMO. That's partially true, but in embedded programming you know exactly what the interrupt handler does, as you write it. And if an interrupt handler gets invoked on timer updates and you only rearm the timer and probably write a variable, then there's no need / it's wasteful to use atomic access to other registers (like GPIO control, ADC) in normal code. And if you modify the same registers in interrupt handlers and normal code, atomic access usually won't suffice, you often need critical sections anyway. Some architectures do not even provide atomic instructions (AVR). Instead you globally disable all interrupts if you want to do something atomic, then enable them again. Now think about how wasteful this gets if every register access is causing this. Obviously you want to leave atomic access to the programmer in this case. Also as this DIP tries to explain shared does not provide enough guarantees to replace volatile(4.2.4). Adding these guarantees to shared would prevent possible valid optimizations for real shared data. Whether ASM solutions or peek/poke are acceptable is probably a point of view thing. If the amount of code dealing with volatile/MMIO registers is low you might get away writing ASM. But for small microcontrollers doing only simple tasks you might end up writing ASM or peek/poke all the time and it'd be very hard for D to compete with C then. The classical hello world for these devices is usually blinking a LED (http://www.micahcarrick.com/tutorials/avr-microcontroller-tutorial/getting-started.html). This usually requires accessing two registers. Now if somebody asks us 'How does Hello World look like in D?' and we present a small D main function + 10 lines of ASM they'll laugh at us and will immediately stop considering D. It's the same for peek/poke. For small, embedded devices D hasn't got much to offer. Cleaner syntax, a little bit CTFE but accessing MMIO in a comfortable way is a deal breaker here. So from this point of view I'd say a type qualifier is well justified. I could also say a 'shared' type qualifier is not justified, because I don't even have multiple threads on embedded devices - as you see it's only a point of view thing. -- You are receiving this mail because: You are watching all bug changes.
