Submitted by Gabriël Konat on 31 May 2013 at 12:09

“It simply forces the compiler to explicitly read a variable whose type is volatile from the variable’s storage location (wherever that may be) rather than assuming that some previously read value in a register for example remains valid.” on stack overflow.

There seem to be direct drawbacks to this modifier.

Plan:

1. add modifier to syntax
2. add modifier to mapping

Volatile variables are required for embedded/low-level programming where you want to access registers on the hardware that are not controllable by the compiler. Without volatile, the first read of that variable will read the hardware register, but subsequent reads may used a cached value, which is incorrect behaviour. I think it is also used in multi-threaded environments. Syntax and generation wise this should be simple, but it may have some implications on the type system.

How are we going to test if this works on a normal computer? Is this possible?

Not sure, but you can trust the C compiler?

syntax updated

If the syntax is updated, do the programs still build? (because the ASTs are changed as well then)

@dario, the way you added to these to the syntax does not provide a good AST.

Declaration.StaticDec = < <Static> <Declaration> >
Declaration.Const = < <Const> <Declaration> >
Declaration.Volatile = < <Volatile> <Declaration> >

The resulting ast of static const int8 will be StaticDec(Const(BasicType("int8"))).

The target is to have an AST of the form Type([Static(), Const()], BasicType("int8")).

Can you please change this?

Also, because the ASTs changes stuff (like desugaring to c) will not work anymore. So please discuss before pushing your commits.

Implemented and mapping to base-c implemented. Type-checking and mapping from Statemachine pending (other issues).