To: J3 J3/21-104r2 From: Richard Bleikamp & JoR & John Reid Subject: system_clock() Date: 2021-February-23 Reference: 21-117 This r2 paper changes the last sentence of the edits, replacing "smaller kind type parameter" with "smaller decimal exponent range". It is JOR's intent to move an alternate paper, 21-117, and only consider this paper only if 21-117 is rejected. After reviewing the many comments in email (J3 and JOR subgroup) about the system_clock intrinsic, and after subgroup discussions, a NOTE is proposed to guide users in how to get the "best" functionality from system_clock(), meaning a simple consistently portable usage model that also allows for accessing the "faster" clock when a processor has added an extension to the language to support multiple clocks per image. Since subgroup was divided on how much explanation was appropriate, edits for two different options for the NOTE are proposed, we plan to take a committee straw vote and "move" the more popular option. Quick summary of some of the points from the many emails. My apologies to anyone whose position is mis-represented, or not represented. Not in chronological order. - Malcolm and some others: the standard is clear, consistent, and not broken. An image may have at most one clock, anything else is an extension, defined by the processor. - Many implementations now offer an extension to the language, of several "different" clocks (or a scaled clock rate), in the same image, based on the kind type parameter of one or more of the arguments to system_clock. Which particular argument is used to select which clock, in the presence or absence of other arguments, is not entirely consistent across all processors. - Allowing a better/more precise system clock to be used was the intent of allowing non-default kind integers as arguments to SYSTEM_CLOCK(), but the current normative text only allows one clock per image. A processor could choose to only support "larger kind" arguments, and not support default kind integers, but no processor does that now. Some processors keep the same rate, and adjust the count_max value to fit in the user supplied argument. Other processors scale the count_rate for smaller integer arguments. - It is generally agreed that passing small (1-2 byte) integer arguments to system_clock is inappropriate for most (all?) processors. Such arguments will either cause system_clock to report NO CLOCK EXISTS, or return values that are difficult to use reliably since the COUNT value returned wraps around to zero when COUNT_MAX is reached by the internal clock. Planned STRAW VOTE: should we choose option 1, or option 2 below? a) Option 1 b) Option 2 c) Undecided EDITS: against 21-007, only one of the options below will be moved for a vote. ----- Option 1, a simple suggestion to the user [437,21+], add this NOTE NOTE Many systems have a clock that is too fast to be supported with default integers. It is therefore recommended that in invocations of SYSTEM_CLOCK all integer arguments have decimal exponent range at least 18 and the argument COUNT_RATE be double precision real if it is real. ----- End of option 1 OR Option 2, adds a brief explanation of why the suggested usage model is recommended. [437,21+], add this NOTE NOTE Many systems have a clock that is too fast to be supported with default integers. It is therefore recommended that in all invocations of SYSTEM_CLOCK, all integer arguments have the same decimal exponent range, of at least 18, and if the argument COUNT_RATE is of type real, that it be double precision. Using SYSTEM_CLOCK in this manner may minimize how often the returned COUNT "rolls over" and improve portability for processors that have extended SYSTEM_CLOCK by using a different clock or scaling the clock rate when the arguments passed to SYSTEM_CLOCK have a smaller decimal exponent range. ---- end of Option 2