From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Aug 6 02:28:00 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id E4121357214; Tue, 6 Aug 2013 02:28:00 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10]) by www.open-std.org (Postfix) with ESMTP id 61BDF356A50 for ; Tue, 6 Aug 2013 02:27:43 +0200 (CEST) Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105]) (authenticated bits=0) by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id r760RdG1083407 for ; Tue, 6 Aug 2013 00:27:41 GMT (envelope-from malcolm@nag-j.co.jp) Message-ID: <3A4796239C8D4284B99290B5A59F6878@Maru6> From: "Malcolm Cohen" To: References: <20130805201609.8DB153571EF@www.open-std.org> In-Reply-To: <20130805201609.8DB153571EF@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.5060) (j3.2006) WG5 vote on draft TSon further coarray features Date: Tue, 6 Aug 2013 09:27:38 +0900 Organization: =?UTF-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0095_01CE9287.31906530" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0095_01CE9287.31906530 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Steve Lionel wrote: <<< Events =E2=80=93 I=E2=80=99d like to see a note or some wording = specifying what happens if more than one image is waiting for an event = to be posted. >>> Cannot happen because we lobotomised events =E2=80=93 only the image on = which the event variable resides is permitted to wait (EVENT WAIT = prohibits event-variable from being coindexed). <<< 7.4.1 (ATOMIC_ADD) =E2=80=93 change =E2=80=9CATOM becomes defined with = the value of ATOM + VALUE.=E2=80=9D To =E2=80=9CATOM becomes defined = with the value of ATOM + INT(VALUE,ATOMIC_INT_KIND).=E2=80=9D Or is = the intent that the normal mixed-mode arithmetic and assignment rules = apply? This seems rather ugly to me, and =E2=80=9Cbecomes defined with = the value=E2=80=9D is not intrinsic assignment. >>> This is a change with little real effect, since if the mathematical = result of adding ATOM and VALUE is not representable the program is not = conforming in precisely the same way for ATOM + VALUE as it would be for = ATOM + INT(VALUE,KIND(ATOM)) or indeed as it would be for = INT(ATOM+VALUE,KIND(ATOM)). Viz, the mathematical value is not = representable. In fact the only effect of the change is to make the case where VALUE is = outside the range of KIND(ATOM) but ATOM+VALUE is not, e.g. = ATOM=3D=3D-HUGE(ATOM) and VALUE=3D=3DHUGE(ATOM)+1_int64. Since the = corresponding assignment statement is valid this would be an unpleasant = surprise to the user at runtime. Given the usual hardware limitations on atomic ops, I would suggest = constaining the kind of VALUE such that RANGE(VALUE)<=3DRANGE(ATOM). Or = even say that all values representable in the kind of VALUE shall be = representable in the kind of ATOM. Then the user will not get an = unpleasant surprise at runtime but will be informed at compile time that = he cannot atomically add a 128-bit value to a 32-bit atom. Cheers, --=20 ................................Malcolm Cohen, Nihon NAG, Tokyo. ------=_NextPart_000_0095_01CE9287.31906530 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Steve Lionel wrote:

<<<

Events=20 =E2=80=93 I=E2=80=99d like to see a note or some wording specifying what = happens if more than=20 one image is waiting for an event to be posted.

>>>

Cannot happen because we = lobotomised events =E2=80=93 only the=20 image on which the event variable resides is permitted to wait (EVENT = WAIT=20 prohibits event-variable from being coindexed).

<<<

7.4.1=20 (ATOMIC_ADD) =E2=80=93 change =E2=80=9CATOM becomes defined with the = value of ATOM + VALUE.=E2=80=9D To=20 =E2=80=9CATOM becomes defined with the value of ATOM +=20 INT(VALUE,ATOMIC_INT_KIND).=E2=80=9D Or is the intent that = the normal=20 mixed-mode arithmetic and assignment rules apply? This seems rather ugly = to me,=20 and =E2=80=9Cbecomes defined with the value=E2=80=9D is not intrinsic = assignment.

>>>

This is a change with little real = effect, since if the=20 mathematical result of adding ATOM and VALUE is not representable the = program is=20 not conforming in precisely the same way for ATOM + VALUE as it would be = for=20 ATOM + INT(VALUE,KIND(ATOM)) or indeed as it would be for=20 INT(ATOM+VALUE,KIND(ATOM)). Viz, the mathematical value is not=20 representable.

In fact the only effect of the = change is to make the case=20 where VALUE is outside the range of KIND(ATOM) but ATOM+VALUE is not, = e.g.=20 ATOM=3D=3D-HUGE(ATOM) and VALUE=3D=3DHUGE(ATOM)+1_int64. Since the = corresponding=20 assignment statement is valid this would be an unpleasant surprise to = the user=20 at runtime.

Given the usual hardware = limitations on atomic ops, I=20 would suggest constaining the kind of VALUE such that=20 RANGE(VALUE)<=3DRANGE(ATOM). Or even say that all values = representable in=20 the kind of VALUE shall be representable in the kind of ATOM. Then = the=20 user will not get an unpleasant surprise at runtime but will be informed = at=20 compile time that he cannot atomically add a 128-bit value to a 32-bit=20 atom.

Cheers,

-- =
................................Malcolm=20 Cohen, Nihon NAG, Tokyo.

------=_NextPart_000_0095_01CE9287.31906530--