From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: C versus Ada (once again :-)), was: Re: F-22 ADA Programming
Date: Mon, 3 Nov 2014 23:28:24 +0100
Organization: cbb software GmbH
Message-ID: <ejx2izvm8mcp.1hdol5zbtlx8h$.dlg@40tude.net>
References: <a510f410-56ea-46a6-9f3c-021a2389b936@googlegroups.com>
 <m2jvqm$qpc$2@dont-email.me>
 <dfa977d6-1458-4d8a-b226-15a759e321d6@googlegroups.com>
 <220f97ab-9aa2-4961-b140-2b271c3ab99a@googlegroups.com>
 <slrnm4ulto.nrc.lithiumcat@nat.rebma.instinctive.eu>
 <m2on9t$tv6$1@dont-email.me>
 <99759c3f-a35f-4745-a8fd-2fb6ab6fb1aa@googlegroups.com>
 <m2p0g5$4d0$1@dont-email.me>
 <48dc1630-8e7d-4e29-8bdd-53d74932d9d0@googlegroups.com>
 <m2pakq$99g$1@dont-email.me>
 <88a7f98c-55c2-4b5f-8a9d-c8b7512781c8@googlegroups.com>
 <m2ptm9$h8a$2@dont-email.me> <pgdzu6hi3mcu.kx0szqbevtow$.dlg@40tude.net>
 <m2r7k7$2m2$2@dont-email.me>
 <50cacb19-5d0b-4dbe-b91b-0b3b462913d6@googlegroups.com>
 <m2tnoi$j1q$4@speranza.aioe.org>
 <07d0ad94-160b-4873-ba1b-403e8c0bc420@googlegroups.com>
 <m2vlg9$onb$1@dont-email.me> <m31iit$74m$1@dont-email.me>
 <874mugsbhl.fsf@mid.deneb.enyo.de> <STS5w.353302$Hb3.343492@fx03.iad>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: d0wqd+GAbcH4VtAP1Y4AEA.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.1
X-Notice: Filtered by postfilter v. 0.8.2
Xref: news.eternal-september.org comp.lang.ada:23010
Date: 2014-11-03T23:28:24+01:00
List-Id: <comp.lang.ada>

On Mon, 03 Nov 2014 14:58:06 -0700, Shark8 wrote:

> On 03-Nov-14 05:40, Florian Weimer wrote:
>> * Simon Clubley:
>>
>>> As I keep saying in one way or another:
>>>
>>> 	Ada: nice language, lousy compiler situation.
>>
>> 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?

Instruction is a wrong term, should be "atomic primitive" instead.

> 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?

No, that would be practically useless.

Atomic primitives must be machine-independent. That is, the compiler would
select the most appropriate implementation for.

For example, consider the atomic increment primitive (of some package
Interfaces type, e.g. Unsigned_64). When there is a machine instruction the
compiler uses it, otherwise it falls back to a protected operation or OS
calls.
 
> (Would such atomic instructions need to be incorporated at the Run-time 
> level?)

Only if the implementation is based on OS calls. E.g. using Windows API
function InterlockedIncrement.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de