[dmd-internals] Regarding deprecation of volatile statements

[Alex Rønne Petersen]

On Wed, Aug 1, 2012 at 7:32 PM, Walter Bright <walter at digitalmars.com> wrote:
>
> On 8/1/2012 9:52 AM, Alex Rønne Petersen wrote:
>>
>> On Wed, Aug 1, 2012 at 6:46 PM, Walter Bright <walter at digitalmars.com>
>> wrote:
>>>
>>> On 7/31/2012 10:02 AM, Alex Rønne Petersen wrote:
>>>>
>>>>
>>>> Not so. It would make it worse (read: less portable and less
>>>> performant) than writing C.
>>>>
>>> I think this is a bit unfair - the C semantics you're talking about are
>>> specific to one compiler. They are not standard, and such has been a
>>> source
>>> of non-portable trouble in the C community.
>>
>> Strictly speaking, yes, you can only rely on GCC implementing the GCC
>> semantics. But in practice, LLVM/Clang does too (since they want to be
>> a GCC drop-in replacement). I'd expect other compilers in the wild to
>> also follow this definition since GCC is the major compiler in the
>> Unix world.
>
>
> While you're right, I am just taking exception to your stance on C being
> better for this because it has a guarantee, because it has no guarantee, and
> that lack of a guarantee has indeed caused many problems. It is not
> irrelevant.

C as a language, from a purely standard (and theoretical) standpoint,
no, definitely not. But C with any sane compiler out there is. And
right now, this is mostly a matter of practicality than anything else.

And exactly because this is a matter of practicality, I'd rewrite my C
code in D the moment we solve this problem, be it with intrinsics or a
volatile statement, or a volatile storage class, or whatever. :)

>
>
>
>>
>> But writing kernel space code in purely standard C is a pipe dream.
>> I've always liked to think of D as a more pragmatic version of C/C++
>> that recognizes that supporting obscure platforms from 40 years ago
>> might not be so important anymore.
>>
>
> There's a bit of irony in that. C++ purports to support 16 bit platforms,
> and many C++ proponents will point this out. But, in practice, it cannot.
> The same goes for the silliness about C++ supporting any character encoding
> - it cannot support Radix50 encoding. And worse for the C silliness that it
> supports 32 bit 'char' sizes (yes, there are such CPUs). I don't know of
> single, supposedly standard-conforming non-trivial C app that will work if
> chars are 32 bits in size.

I'd actually be interested to know if such architectures are in active
use today... the only 16-bit architecture I can think of that's still
in use is MSP430, but that has char = 8 bits.

Regards,
Alex