[J3] SYSTEM_CLOCK

[Vipul Parekh]

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?

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?

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?

Cheers,
Vipul Parekh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210128/35dd3457/attachment.htm>