Paul Eggert wrote on 1998-10-05 20:44 UTC:
Date: Sun, 04 Oct 1998 12:03:49 +0100 From: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk>
You certainly do not measure the position of your radio telescope with 3 cm precision (0.1 ns) by performing time request calls to your C API! You would use external picosecond hardware phase comparators clocked by caesium time normals, which send you the data as ASCII floating point numbers for further processing in your Fortran tools
It sounds like you're saying that C should not support high-resolution timestamps, and that people who need such things should use Fortran instead.
No, of course not. Please use a bit more common sense (this also addresses some comments made by Dan Bernstein about the need for attoseconds): Fortran does not have a higher resolution time API. For scientific applications, you just use whatever representation of numbers with the required precision your language offers. For these applications, you *anyway* must use handwritten inline assembler timing code in order to access the hardware counter in a strictly deterministic way, taking care of interrupts, caches, TLBs, pipelines, and all the other real-world timing hazards that are completely outside the scope of the C standard and what xtime_get() is intended for! In DSP applications, you do not even convert to seconds but calculate in a clock-dependent time scale and just adjust your constants. DSP applications are also far outside the scope of <time.h>! If you think that an API that does not provide this low-level control over timing hazards can be useful for sub-nanoseconds measurements, then this just indicates that you probably never have tried to use computers yourself for high-precision timing with a 10 GHz oscilloscope next to the machine to verify the results. I would never use a vendor provided compiler library for such applications (and I *have* spent days debugging C compiler timing functions under MS-DOS with oscilloscopes for sub-millisecond hard real-time applications). Of course you can time the position of your radio telescope with nanometer precision in C. There is no reason why you would want to use xtime to represent the quantities in the calculations involved in doing this. You will just use normal floating point variables in whatever time scale your instruments and your application define. The timing variances of your processor (cache flushes, TBL reloads, multi-tasking, bus arbitration, etc.) are at least two orders of magnitude worse than 1 ns, therefore, you will never want to use anything like xtime_get() itself as a source of sub-nanosecond timing information. You will always need special hardware or assembler-level driver design for these things, and if you think that the Pentium's internal bus cycle counter is suitable for such applications, then I suggest you try building a GPS software receiver (100 ns resolution required) on top of it to see the real-life limits of software timing.
Perhaps I'm paraphrasing you incorrectly; still, I am extremely uncomfortable with the idea that the C standard should impose an upper limit on the quality of the clock.
I am not. The limit of 1 ns is *much* smaller (at least two orders of magnitude) than any realistic requirement for this type of a software clock. We are moving *very* far away from the real problems, towards topics that are best described as "academic" in the most negative sense of the word. I hope this does not give some observers the impression that the proposal does indeed need as much discussion as it does get here. I am starting to get concerned that I might have wasted a lot of time while working on this, especially since I didn't get any feedback yet from the only ISO C committee member on this list. To rephrase from a Tony Blair speech a few days ago: Please keep in mind that you do not have the choice between the xtime you have got and the xtime you want. You have the choice between xtime and tmx. :-) Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>