[J3] SYSTEM_CLOCK

[Bill Long]

> On Jan 28, 2021, at 3:37 PM, Richard Bleikamp via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> Just a few minor nits, and a preference for REAL type count_rate:
> 
> In the Edits, change "shall all have the same kind" to "shall all have the same kind type parameter" everywhere it occurs.
> 
> Line 15, change "Was it intend" to "Was it intended".
> 
> Line 48, change "integer argument" to "integer arguments".
> 
> ----------
> 
> For when COUNT_RATE is real, I'd prefer something other than processor dependent.
> 

Agree.

> It seems to me, the main reason for a REAL clock_rate is to accommodate a non-integral clock_rate, such as 200.4 ticks per second, and NOT because we expect clock_rates like 1.0E25.  If we did expect very large clock_rates, we should have allowed REALs for the other arguments also, and we didn’t.

I seems to me that the main benefit of a REAL count_rate is avoiding having to be converting the count rate to type real before doing the usual computation of (i2-i1)/rate.  

> 
> Therefore, I would prefer that the clock selected when only CLOCK_RATE is present and of type REAL to be the clock that would be selected if an integer actual argument of the same "size" were used.  

That seems equivalent to the idea that count_rate should correspond to the rate for the clock associated with integer counts of the same “size”, at least if there is such an integer size.   We do have a concept of “size” that covers both integer and real types: the intrinsic STORAGE_SIZE. 


> So a default REAL would use the same clock a default INTEGER clock_rate argument would use.  Not sure how to describe a size for non-default types though ("unspecified storage unit" is not a helpful concept).  We should probably prohibit REAL kinds that are smaller than a default REAL (in case we add a BFLOAT (16 bit real) type in the future, and when the REAL kind is larger than any available INTEGER kind, use the clock the largest integer kind would use.   Yes, this is all somewhat arbitrary, but also very uncommon, and perhaps not worth worrying about.

I like the idea that arguments smaller than 32-bits should be disallowed.  The are not practical and, in practice, don’t work anyway. 

The idea of allowing a 128-bit REAL count rate for a 64-bit integer count  might make some sense, since REAL values of a particular storage_size tend to have less precision than an integer of the same storage size. OTOH, clock rates above 2**50 seem very unlikely, given the size of atoms.  And, we want to be careful to word something like this to allow for a future with 128-bit hardware integers and clock registers. 

Cheers,
BIll



> 
> Rich
> 
> On 1/28/21 7:30 AM, John Reid via J3 wrote:
>> [CAUTION: External Email]
>> 
>> Dear all,
>> 
>> Here is a draft interp. Comments, please.
>> 
>> John.

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