New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mirage-clock-freestanding passes through several layers, including floating point #23

hannesm opened this Issue Dec 14, 2016 · 0 comments


None yet
1 participant

hannesm commented Dec 14, 2016

let's take a brief look at how now_d_ps () on solo5 works:

  • calls to unix_gettime (external time : unit -> float)
  • this is implemented by mirage-solo5/lib/bindings/clock_stubs.c, calling to gettimeofday (struct timeval*, NULL) and caml_copy_double((double) tp.tv_sec + (double) tp.tv_usec / 1e6)
  • gettimeofday is implemented by ocaml-freestanding (in nolibc/sysdeps_solo5.c), calling out to int64 solo5_clock_wall (and conversion: tv->tv_sec = now / NSEC_PER_SEC; tv->tv_usec = (now % NSEC_PER_SEC) / 1000ULL;)
  • solo5_clock_wall is provided by ukvm and virtio in time.c, using pvclock or tscclock

My main concern is that our base is nanoseconds since epoch as an unsigned int64 in C, we nevertheless convert them to a struct with two unsigned int64, just to convert them to a OCaml double, to again convert them (in this library) to an int and an int64. We could save several conversions on the way, and just use the solo5_clock_wall directly (or name it differently and provide same implementation with Xen minios).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment