 |
lua-l archive |
|
|
||
|
On 08-Nov-19 18:00, Egor Skriptunoff wrote:
In the epoch of single-task environments, in 1988 (before ISO C standard was published), internal help of Borland's Turbo C for DOS already claimed that it's the CPU time that is returned by clock() The screenshot: https://i.imgur.com/6AF00J8.png But this is Borland, not MS. I don't have old Microsoft's C compiler's manual at my disposal to see how clock() was described there.
I seem to have misplaced the library volume of Microsoft Quick C, assuming there was one. But, if I remember correctly, in both Microsoft and Borland compilers clock() returned a system-wide tick count value, a value that was incremented by the real-time clock interrupt routine (INT 08H). I wrote portable C code and I don't remember handling clock() differently for each system.
Of course, in plain MS-DOS, the sole CPU was almost fully owned by the sole running program, so no subtle differences were made.
A curiosity: date/time were read from the hardware clock chip only at startup, then maintained by counting clock ticks (i.e. the aforementioned interrupts). If the user changed date/time, the tick count did not change, so remaining monotonic (up to the next wrap-around...).
Date/time shown could be different from those stored into the (battery-backed) real-time clock chip. For example, when I hijacked the timer generating INT 08H to play recorded sounds with the internal speaker, date/time paused while a sound was played, because ticks were lost.
-- Enrico