From owner-sc22wg5@open-std.org Wed Oct 21 18:19:32 2009 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 878ABC178E4; Wed, 21 Oct 2009 18:19:32 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mail1.cray.com (mail1.cray.com [136.162.62.100]) by www2.open-std.org (Postfix) with ESMTP id B4917C178E3 for ; Wed, 21 Oct 2009 18:19:29 +0200 (CET DST) Received: from beaver.us.cray.com (beaver.us.cray.com [172.30.74.51]) by mail1.cray.com (8.13.6/8.13.3/gw-5323) with ESMTP id n9LGJRQt003803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Oct 2009 11:19:27 -0500 (CDT) Received: from cfexcas01.americas.cray.com (cfexcas01-2.us.cray.com [172.30.74.227]) by beaver.us.cray.com (8.13.8/8.13.3/hub-5273) with ESMTP id n9LGJPmV027849; Wed, 21 Oct 2009 11:19:26 -0500 Received: from fortran.us.cray.com (172.31.19.200) by cfexcas01.americas.cray.com (172.30.74.226) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 21 Oct 2009 11:19:24 -0500 Message-ID: <4ADF34A3.50307@cray.com> Date: Wed, 21 Oct 2009 11:19:47 -0500 From: Bill Long Reply-To: Organization: Cray Inc. User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: fortran standards email list for J3 Cc: "sc22wg5@open-std.org" Subject: Re: (j3.2006) (SC22WG5.4094) [ukfortran] Standard intrinsics and coarrays References: <20091020111544.C0F5CC178E3@www2.open-std.org> <4ADDC3E1.4030007@cray.com> <20091020151813.AB917C178E3@www2.open-std.org> <20091020154252.946EAC178E3@www2.open-std.org> In-Reply-To: <20091020154252.946EAC178E3@www2.open-std.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Cray-VirusStatus: clean Sender: owner-sc22wg5@open-std.org Precedence: bulk N.M. Maclaren wrote: > This is a redraft, hopefully fixing all of the mistakes and ambiguities > pointed out by Bill. > > > We seem to have forgotten to specify how the intrinsic procedures may > be used as far as their use in unordered images is concerned - or, at > least, I can't find anything. However, I don't think that there is much > of a problem. 13.5 paragraph 2 and Table 13.1 is the starting point, > and a lot of my proposal is already implied for those of classes E, ES > and PS by other wording. Those of class A are already covered. > > I have drafted the hard line on random numbers; it would be possible to > make the 'shall be' conditional on the processor dependence, but that is > messy. Taking into account recent messages, here are some suggested changes: > > Proposal: > > In 13.5, Standard generic intrinsic procedures, after Table 13.1, add > the new paragraphs: I believe that this first paragraph should also include comments on GET_ENVIRONMENT_VARIABLE, GET_COMMAND, GET_COMMAND_ARGUMENT, and COMMAND_ARGUMENT_COUNT. All of these routines involve communication with the user's shell. Calling any of these from image 1 should produce the expected result, and that the effects on images other than 1 are processor dependent. > > It is processor dependent whether EXECUTE_COMMAND_LINE may be called > on any image other than image 1. > We need to be careful that calling RANDOM_SEED and RANDOM_NUMBER within the same segment is still allowed (i.e. when A and B are the same.) The random number generator is an intrinsic library routine that happens to have internal state, so is a unique case and deserves its own paragraph. > If RANDOM_SEED is called in a segment A, and either RANDOM_SEED or > RANDOM_NUMBER is called in segment B, then segments A and B shall be > ordered. It is processor dependent whether all images use a common > generator or whether each image uses a separate one. I would pare this down to CPU_TIME, DATE_AND_TIME, and SYSTEM_CLOCK. They are closely related and involve direct interaction with the OS or hardware. > > It is processor dependent whether the results returned from CPU_TIME, > DATE_AND_TIME, GET_COMMAND, GET_COMMAND_ARGUMENT, > GET_ENVIRONMENT_VARIABLE and SYSTEM_CLOCK are dependent on which > image calls them. > > NOTE 13.x > It is unspecified whether images use synchronized clocks, whether > CPU_TIME returns a per-image or per-program value, whether all > images run in the same time zone, whether the count rate and > maximum in SYSTEM_CLOCK are the same for all images I would then end the NOTE at this point. Cheers, Bill , and whether all > images run in the same command environment. It is likely that they > will behave differently on shared memory systems and some > distributed memory ones. > > The use of all other standard intrinsic procedures in unordered > segments is subject only to their argument use following the rules > in 8.5.2. > > > Regards, > Nick Maclaren. > > _______________________________________________ > J3 mailing list > J3@j3-fortran.org > http://j3-fortran.org/mailman/listinfo/j3 -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120