(j3.2006) (SC22WG5.4099) [ukfortran] Standard intrinsics and coarrays

[Bill Long]

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 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3

-- 
Bill Long                                   longb at 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