From owner-sc22wg5@open-std.org Wed Dec 3 19:36:34 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 1F419C56CF8; Wed, 3 Dec 2008 19:36:34 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by www2.open-std.org (Postfix) with ESMTP id 31C4FC178DC for ; Wed, 3 Dec 2008 19:36:32 +0100 (CET) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB3Ia2ql023633 for ; Wed, 3 Dec 2008 13:36:02 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB3IaV9N187474 for ; Wed, 3 Dec 2008 13:36:31 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB3IaVkV024261 for ; Wed, 3 Dec 2008 13:36:31 -0500 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB3IaVLn024250 for ; Wed, 3 Dec 2008 13:36:31 -0500 In-Reply-To: <20081203181454.82657C4596D@www2.open-std.org> References: <20081203025222.12F4BC178E0@www2.open-std.org> <20081203174656.5AF23C4596D@www2.open-std.org> <20081203181454.82657C4596D@www2.open-std.org> To: sc22wg5 MIME-Version: 1.0 Subject: Re: (j3.2006) (SC22WG5.3712) [ukfortran] Atomic stuff X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 Message-ID: From: Jim Xia Date: Wed, 3 Dec 2008 13:36:29 -0500 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 12/03/2008 13:36:30, Serialize complete at 12/03/2008 13:36:30 Content-Type: multipart/alternative; boundary="=_alternative 006637D285257514_=" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 006637D285257514_= Content-Type: text/plain; charset="US-ASCII" j3-bounces@j3-fortran.org wrote on 12/03/2008 01:14:52 PM: > >Now I take another look at the atomic stuff we worked out in Tokyo, I > >think there is an issue we didn't address: alignment. Consider on a > >system we have atomic_integer_kind being 4 bytes, and the processor also > >supports 2 byte integers, then the following declarations > > > > integer(2) x(3) > > integer(ATOMIC_INTEGER_KIND) y, z > > > > equivalence (y, x(2)) > > equivalence (z, x) > > > >Now either y or z is out of natural alignment. This will certainly cause > >implementation problems on atomic operations on y and z. We have to > >disallow this to happen. > > Already done for that example - see Note 5.42 in 5.7.1.5. Nick, I don't see how that note (5.42) covers my example. But let's say > that we make the appropriate changes to avoid that. Then it is clobbered by > constraint C589, C590, C591 and 4.5.2.3. > > The problem has been there since time immemorial in the case of systems > where unaligned access is not supported (especially for DOUBLE PRECISION). > Yes, I know that the IBM System/360 (sic) Fortran library trapped the > interrupts and fixed up the alignment, but that was a performance disaster, > not all compilers did and some still don't. But, curiously, I can't find > where that that one is locked out. Atomic loads and stores on mis-aligned variables are nearly impossible on many hardwares (The solution to fix up the mis-alignment by either hardware or OS causes the operation become non-atomic, let along the performance hit). Three places I think will likely cause this mis-alignment: EQUIVELENCE, COMMON BLOCK and structure component level. The one that is relevant to coarrays is structure component. The other two will apply to local objects only. We need to think how to fix that. Cheers, Jim Xia RL Fortran Compiler Test IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7 Phone (905) 413-3444 Tie-line 313-3444 email: jimxia@ca.ibm.com D2/YF7/8200 /MKM --=_alternative 006637D285257514_= Content-Type: text/html; charset="US-ASCII"
j3-bounces@j3-fortran.org wrote on 12/03/2008 01:14:52 PM:

> >Now I take another look at the atomic stuff we worked out in Tokyo, I
> >think there is an issue we didn't address: alignment.  Consider on a
> >system we have atomic_integer_kind being 4 bytes, and the processor also
> >supports 2 byte integers, then the following declarations
> >
> >    integer(2) x(3)
> >    integer(ATOMIC_INTEGER_KIND) y, z
> >
> >    equivalence (y, x(2))
> >    equivalence (z, x)
> >
> >Now either y or z is out of natural alignment.  This will certainly cause
> >implementation problems on atomic operations on y and z.  We have to
> >disallow this to happen.
>
> Already done for that example - see Note 5.42 in 5.7.1.5.

Nick, I don't see how that note (5.42) covers my example.


                                                              But let's say
> that we make the appropriate changes to avoid that. Then it is clobbered by
> constraint C589, C590, C591 and 4.5.2.3.
>
> The problem has been there since time immemorial in the case of systems
> where unaligned access is not supported (especially for DOUBLE PRECISION).
> Yes, I know that the IBM System/360 (sic) Fortran library trapped the
> interrupts and fixed up the alignment, but that was a performance disaster,
> not all compilers did and some still don't. But, curiously, I can't find
> where that that one is locked out.

Atomic loads and stores on mis-aligned variables are nearly impossible on many hardwares (The solution to fix up the mis-alignment by either hardware or OS causes the operation become non-atomic, let along the performance hit).

Three places I think will likely cause this mis-alignment: EQUIVELENCE, COMMON BLOCK and structure component level.  The one that is relevant to coarrays is structure component.  The other two will apply to local objects only.  We need to think how to fix that.

Cheers,

Jim Xia

RL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444  Tie-line 313-3444
email: jimxia@ca.ibm.com
D2/YF7/8200 /MKM
--=_alternative 006637D285257514_=--