<html>
<head>
<base href="http://bugzilla.gdcproject.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Add support for attribute to mark data as volatile."
href="http://bugzilla.gdcproject.org/show_bug.cgi?id=126#c15">Comment # 15</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Add support for attribute to mark data as volatile."
href="http://bugzilla.gdcproject.org/show_bug.cgi?id=126">bug 126</a>
from <span class="vcard"><a class="email" href="mailto:johannespfau@gmail.com" title="Johannes Pfau <johannespfau@gmail.com>"> <span class="fn">Johannes Pfau</span></a>
</span></b>
<pre><span class="quote">> Didn't knew about this proposal</span >
It's not yet been announced/discussed, though I'll probably start a discussion
on the newsgroup this week.
<span class="quote">> 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.</span >
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
(<a href="http://www.micahcarrick.com/tutorials/avr-microcontroller-tutorial/getting-started.html">http://www.micahcarrick.com/tutorials/avr-microcontroller-tutorial/getting-started.html</a>).
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>