Hans =?iso-8859-1?Q?J=F8rgen?= Jakobsen <[EMAIL PROTECTED]> writes: |> >> http://www.cl.cam.ac.uk/~mgk25/time/leap/timelog.c |> >> |> > But what about non X86 arch? |> Some hack needed on Solaris sparc: |> bash-2.03$ gcc timelog.c |> timelog.c: In function `read_tsc': |> timelog.c:44: unknown register name `edx' in `asm' |> timelog.c:44: unknown register name `eax' in `asm'
You obviously need to undef HAVE_PENTIUM_TSC if you don't have one. Can't think of an easy portable compile-time test for that one. |> timelog.c: In function `main': |> timelog.c:113: `CLOCK_MONOTONIC' undeclared (first use in this function) |> timelog.c:113: (Each undeclared identifier is reported only once |> timelog.c:113: for each function it appears in.) |> timelog.c:114: `CLOCK_PROCESS_CPUTIME_ID' undeclared (first use in this function) |> timelog.c:115: `CLOCK_THREAD_CPUTIME_ID' undeclared (first use in this function) OK, fixed. I've added lots of #ifdef's using the POSIX macros _POSIX_MONOTONIC_CLOCK, _POSIX_CPUTIME, _POSIX_THREAD_CPUTIME. Even this little test routine has now ended up as the sort of #ifdef spaghetti junction that makes every POSIX committee proud ... :-( In principle, clock_gettime() is a far more sensible API function than gettimeofday(). But the sad state of support of clock_gettime() does not yet make it a very attractive substitute for the ubiquitously available gettimeofday(). I see some homework for glibc and kernel developers here! Actually, I see no reason whatsoever for why clock_gettime() should be implemented in the kernel as a system call. All the kernel needs to provide is to map into user space the conversion parameters between the hardware clock and the various different POSIX clock types. It also must grant user space direct read access to the clock hardware. Then, API calls for querying the time will no longer add the entire kernel context switch overhead as noise to their measurements. The implementation of clock_gettime() and gettimeofday() should be as fast and predictable as possible; both of these requirements speak strongly against involving the kernel directly. Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
