Re: C versus Ada (once again :-)), was: Re: F-22 ADA Programming

[Florian Weimer <fw@deneb.enyo.de>]

* Shark8:

>> If you are trying to parallelize your programs for performance
>> reasons, Ada (as standardized) is not such a nice language anymore
>> because it lacks a modern memory model (which reflects the variations
>> of existing hardware) and access to various forms of atomic
>> instructions with well-defined properties.
>>
>
> Isn't the atomic instruction thing properly recognized as platform
> dependent?

The actual implementation is platform-dependent, but the C11 memory
model abstracts over it.  You use the <stdatomic.h> functionality
which you need to implement your parallel algorithm, and the C
implementation will select something matching for the target
architecture (either an exact match, or a stronger (and slower)
variant).

> If that's the case, then should it be part of Ada, or would
> it be acceptable to have a machine-language (e.g. System.Machine_Code)
> insert for handling it in the implementation part of some package?

It's difficult to get that right because it needs a lot of knowledge
of the target architecture and its variations.  If you stick to the
C11 memory model (or C++11 variant, they are supposed to be
compatible), you only need to learn that, and the C implementation
will map it to the hardware.

> (Would such atomic instructions need to be incorporated at the
> Run-time level?)

Some systems need kernel calls for certain barriers, yes.  But Ada
code needs to issue these barriers today, so support already has to be
present.

The main challenge is to expose weaker (and therefore more efficient)
synchronization primitives.