[J3] SYSTEM_CLOCK

John Reid John.Reid at stfc.ac.uk
Fri Jan 29 15:59:14 UTC 2021


Dear all,

Thanks for all your comments. I will attempt to address them all.

Steven Kargl:
Yes, I agree that adding an extra argument would take this away from 
being an interp. I think this is hard to justify. It is needed only for 
the case of  real COUNT_RATE on its own. The user has the easy work 
around of adding an integer argument.
I have already included a limitation that the integers must support at 
least 8 digits. The example in the standard uses 7 digits.

Vipul:
I have now added a note. Let's see if you and others like it.
I agree that we should not be comparing actual kind values.
Your idea of basing everything on a real R for the count rate on an 
image would not work for an old code using default integers on an image 
that has a fast clock.

Bill, Rich, Steve Lionel
If  COUNT_RATE is real, its kind determines the accuracy of its value. 
For a 64-bit clock, the user may be perfectly happy to compute all 
actual times to single-precison accuracy. Each time is an integer 
difference in COUNT values times COUNT_RATE. Therefore, I see its kind 
as having nothing to do with which clock is involved.

Rich:
  I have corrected the "nits".

Steve Lionel:
My draft does address calls with one argument. It says "If an image has 
more than one clock, the clock is determined by the kind of the integer 
arguments or is processor dependent if there are no integer arguments."  
Here "integer arguments" includes the case of a single argument. We use 
this style a lot in the standard. There is even an example for 
SYSTEM_CLOCK on [462:20].

Revised draft attached.

Cheers,

John.



-------------- next part --------------

NUMBER: F18/xxx
TITLE: SYSTEM_CLOCK argument kinds
KEYWORDS: SYSTEM_CLOCK
DEFECT TYPE: Erratum
STATUS: Under consideration

QUESTION:

Clause 16.9.186 SYSTEM_CLOCK ([COUNT, COUNT_RATE, COUNT_MAX]), para, 3 
states that the argument COUNT "is assigned a processor-dependent 
value based on the value of a processor clock, or -HUGE (COUNT) if 
there is no clock for the invoking image."

Was it intended to allow the image to support more than one clock?


ANSWER:

This intrinsic was introduced in Fortran 90 assuming that there was a 
basic system clock that was incremented by one for each clock tick 
until a maximum was reached after which it was reset to zero. All the
arguments were default integers which were adequate for the computers
of the time.  

In Fortran 2003, these arguments were allowed to be of any kind to 
accommodate systems with a clock rate that is too high to be 
represented in a default integer. Also, the argument COUNT_RATE was
permitted to be real to accommodate systems whose clock does not 
tick an integral number of times per second. The model was still of 
data being returned from a single clock. It was intended that on such 
a system all the integer arguments would be long. 

There was no significant change to this in Fortran 2008. It states 
that the argument COUNT "is assigned a processor-dependent 
value based on the value of the processor clock, or -HUGE (COUNT) if 
there is no clock."

The wording for COUNT in Fortran 2018 was quoted in the question. Note 
that "the processor clock" became "a processor clock". This was to 
accommodate each image having its own clock or some or all images 
sharing a clock. There is no mention in the introduction of a change. 
However, the wording does allow vendors to provide different clocks 
for different kinds.

Having two clocks accommodates old programs that use default integers 
and new programs that get more accurate timings by using long integers. 
It was never intended to mix the kinds of the integer arguments or to
use short integers and edits are provided to specify this. 


EDITS to 18-007r1:

[420:5] 16.9.186 SYSTEM_CLOCK ([COUNT, COUNT_RATE, COUNT_MAX]), para 3,
     COUNT. At the end of the first sentence add "with a decimal 
     exponent range of at least eight" and add new sentence "If there
     are other integer arguments they shall all have the same kind
     type parameter values."
          
[420:10] 16.9.186 SYSTEM_CLOCK ([COUNT, COUNT_RATE, COUNT_MAX]), para 3,
     COUNT_RATE. After the first sentence add "If it is integer, it 
     shall have a decimal exponent range of at least eight and if there
     are other integer arguments they shall all have the same kind
     type parameter values."
    
[420:13] 16.9.186 SYSTEM_CLOCK ([COUNT, COUNT_RATE, COUNT_MAX]), para 3,
     COUNT_MAX. At the end of the first sentence add "with a decimal 
     exponent range of at least eight" and add new sentence "If there
     are other integer arguments they shall all have the same kind
     type parameter values."
         
[420:16] 16.9.186 SYSTEM_CLOCK ([COUNT, COUNT_RATE, COUNT_MAX]), para 4.
     At the end of the paragraph add "If an image has more than one 
     clock, the clock is determined by the kind of the integer 
     arguments or is processor dependent if there are no integer 
     arguments." 
     
[420:21+] 16.9.186 SYSTEM_CLOCK ([COUNT, COUNT_RATE, COUNT_MAX]).
     At the end of the section, at this note:
     "NOTE 
     When COUNT_RATE is real, its kind determines its precision and 
     has no bearing on the choice of clock. Differences between values
     of COUNT variables of different kinds might be meaningless 
     because of refering to different clocks."

SUBMITTED BY: John Reid

HISTORY: 


More information about the J3 mailing list