[fpc-pascal] Very vague gettickcount64 description?
jura at cp-lab.com
Sun Sep 8 12:10:48 CEST 2019
On 08.09.2019 10:09, Michael Van Canneyt wrote:
> On Sat, 7 Sep 2019, Zoe Peterson wrote:
>>> From: Martin Frb <lazarus at mfriebe.de>
>>> But that does not mean, it needs to be changed on existing targets.
>>> And if it is not going to be changed, then it can be documented.
>> I agree with everything Martin has said, though IMO GetTickCount must return values in ms on every single platform and
>> any that can't should have it removed. It's not a precision timer and it should not be an intrinsic for whatever
>> random RDTSC-like instruction the current platform has. It's used for checking (rough) elapsed times. I honestly can't
>> think of a single use for the current function as defined, especially in a cross-platform app. Precision and accuracy
>> can vary, but unspecified units with no way to query them is ridiculous.
> For relative measurements, units are not needed. A ratio has no units, the
> only thing that is required is that the units for both measurements are the
> same (which should be the case on a single platform).
Strictly defined measurement units are important for cross-platform (and Delphi) compatibility. So GetTickCount_2 -
GetTickCount_1 must return how many milliseconds have elapsed between calls of GetTickCount regardless of the platform
where the program is running.
> But I have re-checked the Microsoft documentation, the implementation, and
> have added millisecond units to documentation of gettickcount(64).
> Note that the FPC implementation gives an increasing time, not the number of
> milliseconds elapsed since system boot. Which is what, strictly speaking,
> it should return to comply to the Microsoft implementation.
Yes. Implementing this for every platform would be overkill. GetTickCount in FPC should be documented just as a
millisecond counter without defined starting point and without guaranteed precision.
More information about the fpc-pascal