[Bug 126] Add support for attribute to mark data as volatile.

[via D.gnu]

http://bugzilla.gdcproject.org/show_bug.cgi?id=126

Johannes Pfau <johannespfau at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johannespfau at gmail.com

--- Comment #2 from Johannes Pfau <johannespfau at gmail.com> ---
Has this been discussed at dconf? I actually began writing a DIP for volatile
but it's not ready yet. However, I feared that Walter/Andrei would oppose it,
but I think this is a big problem for embedded D, probably big enough so
embedded D will never take off.

1) we should have a portable volatile attribute not only gdc specific solutions
or we're worse than C
2) Peek/poke are quite complicated to use on simple embedded systems where you
only access registers. Nobody's going to use D if you have to do this to access
registers:
--------------
auto x = peek!uint(address);
x |= 0b1;
poke(address, x);
--------------

if you can just do
--------------
x |= 0b1;
--------------
in C.

(We have to remember that most embedded programming on small (e.g. 8bit)
processors works just fine with C. D can only provide very few benifits (for
example, ctfe is great, but there's no big usecase on simple programs which
only read some input (e.g temparature) and do some IO communication. Templates
are out cause executable size is very important,...). But what you do on these
systems all the time is accessing volatile memory/registers. If that's more
complicated in D than in C, or not portable, then C is a much better language
for embedded programming)

@volatile in GDC only is also a problem, because it requires significant
changes to the frontend and this is bad for a shared frontend. Two examples
which need extended frontend support:

------------------
struct A
{
    int x;
    int readX() {return x;}
    int correctRead() {return x;} volatile
}

volatile(A)* a;
auto x = a.readX(); //Should not compile! Compiler doesn't know that reading x
in readX needs to be volatile. We need rules as for const: Only methods marked
as volatile should work on volatile structs

auto x = a.correctRead(); //Should work. Also works on non volatile instances
(just like const methods / mutable instances)
------------------

------------------
volatile int x;

void func()
{
   auto x2 = x; //x2 is not volatile anymore cause we made and independent copy
   //volatile should be transitive, so we have to be careful if a type has
references. Again see the anology to const. 
}
------------------

transitivity of volatile is used in few cases only, but it's necessary. One
example is DMA:
------------------
volatile uint** DMASRC, DMADEST;
*DMASRC = address;
doDMA(); //Overwrites *DMADEST
------------------

or, more often in real world, interrupts;
------------------
interrupt()
{
    if(dice)
        data = null;
    else
        *data = 42;
}

volatile(uint*) data;

func doSomething()
{
    uint data1;
    data = &data1;
    //interrupt can modify the pointer itself or the value
}
------------------
(for example you can google how often newbies struggle in C if they have to do
some volatile(volatile uint)* ... stuff)

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20140523/a54b027b/attachment.html>