[J3] SYSTEM_CLOCK

[Steven G. Kargl]

On Thu, Jan 28, 2021 at 02:46:42PM -0500, Vipul Parekh via J3 wrote:
> On Thu, Jan 28, 2021 at 1:23 PM Steven G. Kargl via J3 <
> j3 at mailman.j3-fortran.org> wrote:
> 
> > ..
> > Does it matter that you don't see a justification?  The Fortran
> > standard permits a Fortran processor to select a clock rate based
> > on its actual arguments.  gfortran does
> >
> >    k = min(kind(COUNT), kind(COUNT_RATE), kind(COUNT_MAX))
> >    if (k < 4) no clock
> >    if (k == 4) millisecond time scale
> >    if (k > 4) nanosecond time scale
> >
> 
> This, in a nutshell, is the crux of the problem for the poor persevering
> practitioners of  Fortran.
> 
> The "processor-dependent" clauses in the standard *seemingly* give leeway
> to the implementors to do whatever!
> 
> With the relationship shown above, particularly " k = min(kind(COUNT),
> kind(COUNT_RATE), kind(COUNT_MAX)) " and " if (k == 4) millisecond time
> scale", some imponderables faced by the practitioner who raised the PR will
> be:
> 
> 1) What does the KIND of a real variable have anything to do with the KIND
> of an integer variable?

Nothing, normally.

> 2) Consider ISO_FORTRAN_ENV and its named constants toward INT32 with
> integer that may be KIND=4 in some processor and REAL32 for real which may
> also be KIND=4 under the separate real KINDS list with said processor: how
> are they to be treated equivalently in a relationship such as above given
> the different numerical models for integers and reals?

Default integer kind is 1 numeric storage unit.
Default real kind is 1 numeric storage unit.
That's about it.  See, for example, EQUIVALENCE.

> 3) Considering 2, why would COUNT in INT64 and COUNT_RATE as REAL32 result
> in "millisecond time scale" whereas COUNT only in INT64 leads to
> "nanosecond time scale" for the clock rate?

A choice has to be made.  As you likely know, all arguments
are optional.  If multiple clock rates are available, how do
you choose a COUNT_RATE for

real x
call system_clock(count_rate=x)

gfortran could set x to zero (i.e., no clock), but that 
may be even more confusing for a user.  John's purposed
edit to me at least tries to address the issues for
Fortran processors with mutliple clock rates.  Your
suggestion of adding a NOTE might also be appropriate.

-- 
Steve