Jonathan Stone writes:
> 
> >We need:
> 
> >1) an MI interface to a high speed counter/timer, such as, say, a
> >   macro to access a CPU instruction counter if one exists. If there
> >   isn't such a low cost/high resolution timer available, microtime
> >   could be used (but its best to avoid that if a better timer is
> >   available.)
> 
> Is nanotime() good enough?  We may get cycle times faster than
> nanoseconds in a very few years, but AFAIK we're not qiute there yet.
> And we should be providing nanotime() in any case.
> 
> Or did the nanosecond-time-resolution changes die with JTC's semi-departure?

I believe nanotime may have died for a while, but even so, it isn't
appropriate. Why?

nanotime() gives you the time in nanoseconds, but doesn't actually
have that resolution in most implementations -- it just adds
significant bits to the existing 100Hz clock or what have you. Also,
you don't need the actual time -- just a monotonically increasing
counter. In other words, this is a job made for CPU cycle counters,
which most CPUs have these days. With a CPU cycle counter, you will
maximize the number of bits of entropy you can extract.

An MI CPU cycle counter macro is what we really need.

Perry