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