[J3] SYSTEM_CLOCK

[Bill Long]

> On Jan 30, 2021, at 4:16 AM, John Reid via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> 
> Very interesting! I took it as a fact that some processors have more than one clock and that we needed to address this.

A bit of a complicated situation.  Traditionally, one thinks of a model where the processor has a register that increments once every “clock period (CP)”.  Typically linked to the MHz of GHz rating for the processor. This CP is the interval between issuing instructions and drives all the internal synchronization of operations in the cpu.   Some more recent processors  have a variable CP that gets shorter (clock is “faster”) if heat buildup in the chip is low (so called “turbo boost”).  A clock like that, with a count_rate that varies in time, is not useful for something like SYSTEM_CLOCK.  So, such processors also provide a separate clock with a constant rate for use by programmers.   From the point of view of SYSTEM_CLOCK, only the constant-rate clock is relevant.  To avoid frequent rollover, the register for the constant-rate clock is usually 64 bits on systems in service today. 

Unfortunately, when SYSTEM_CLOCK was introduced into Fortran, there was no requirement of a 64-bit integer KIIND.  So default KIND integers were also allowed, which were 32 (or 36) bits on some systems, and 64 (or 60) bits on others.  A 32-bit clock is “created” by scaling the value from the hardware clock so that the 32-bit clock does not rollover too rapidly.  As has been pointed out elsewhere, using integer kinds corresponding to 16-bit or 8-bit integers are more or less pointless for a usable system_clock, and it is better to declare that “no clock exists” for those cases.  

The true statement is that a COUNT variable, a COUNT_RATE variable , and a COUNT_MAX value of the same size (as measured by numerical storage units, the STORAGE_SIZE intrinsic, or bytes)  form a consistent set so that computations of the form (COUNT2 - COUNT1)/COUNT_RATE (for a REAL COUNT_RATE) make sense for computing a time interval.   You can call SYSTME_CLOCK with any manner of KINDS, but the relevant constraint is which values are compatible for use in a time computation. I would say that most programmers already “know” this and get the usage correct, even with the vague spec we have now.  So, I would recommend an explanatory NOTE rather than trying to create rules relating argument KINDS. 

> 
> The history of SYSTEM_CLOCK is summarized in my draft reply. Until F 2018, the model was of a single clock. I think we made the change to allow for different images having different clocks and still thought of each image having a single clock. Some 20 years ago (F 2003) we recognized that some systems needed long integers and simply assumed that on such
> systems users would use long integers.
> 
> So how about now requiring long integers on such a system?

Unfortunately, the 32-bit integer calls are out there in existing programs (no matter how ill-advised) and we do not want to modify the standard in such a way that causes existing programs that were previously standard-conforming to suddenly no longer be conforming. 

Cheers,
Bill


Bill Long                                                                       longb at hpe.com
Engineer/Master , Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Hewlett Packard Enterprise/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425