DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Fri Jul 18 16:58:41 PDT 2014


On 07/18/2014 08:37 PM, Walter Bright wrote:
> On 7/18/2014 11:06 AM, Timon Gehr wrote:
>> On 07/17/2014 05:58 PM, Andrei Alexandrescu wrote:
>>>
>>> * "volatile" has been one of the most awkward parts of the C and C++
>>> specifications. If we're to learn of anything about it, it's we must
>>> stay away from it. It is extremely heavy for what it provides.
>>> ...
>>>
>>> ==============
>>>
>>> I think an approach based on functions peek/poke is a lot more
>>> promising.
>>
>> I am not saying that we should add volatile as a type qualifier, but
>> it should
>> be noted that programs with volatile type qualifiers can be lowered to
>> programs
>> using peek/poke and possibly other API calls with limited effort. (it is
>> especially limited since the effort could be mostly shared with
>> 'shared', both
>> in specification and implementation, as it is another type qualifier
>> that (will)
>> (presumably) influence(s) the behaviour of loads and stores.)
>
> That doesn't change the heavy effort in the semantic front end

What does this mean in detail? Is it just about the unfortunate AST 
representation chosen or are there more sources of heavy effort in the 
front end?

> and language specification to support volatile.
> ...

The language specification would just state what the rules for lowering 
are. In any case, I think the other points that Andrei raised are 
convincing enough.



More information about the Digitalmars-d mailing list