[libc-commits] [libc] [libc] Baremetal version of clock (PR #146417)

[William Huynh via libc-commits]

================
@@ -0,0 +1,45 @@
+//===-- Baremetal implementation of the clock function --------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "src/time/clock.h"
+#include "hdr/time_macros.h"
+#include "hdr/types/struct_timespec.h"
+#include "src/__support/CPP/limits.h"
+#include "src/__support/common.h"
+#include "src/__support/macros/config.h"
+#include "src/__support/time/units.h"
+
+namespace LIBC_NAMESPACE_DECL {
+
+extern "C" bool __llvm_libc_timespec_get_active(struct timespec *ts);
----------------
saturn691 wrote:

If you were to define this interface like so, downstream, I've have to do this:

```cpp
bool __llvm_libc_timespec_get_active(struct timespec *ts) {
  long retval = semihosting_call(SYS_CLOCK, 0);
  if (retval == -1)
    return false;

  // Semihosting uses centiseconds
  ts->tv_sec = (retval / 100);
  ts->tv_nsec = (retval % 100) * (1'000'000'000 / 100);
  return true;
}
```

Pretty much reverse engineering your code. Perhaps this works better for you downstream, but it seems like some extra unnecessary work is being done (at least for me). 

You could make the argument that:
- "there could be overflow", afaik hardware clocks are implemented as a single (usually unsigned long) value.
- "the performance gains would be minimal", true, but I think in principle we should not unnecessarily throw away performance

https://github.com/llvm/llvm-project/pull/146417