Re: Handling of clock() for RISC-V

Hi Christian:


My understanding of newlib in bare-metal applications is that it provides a
general implementation, but not necessarily the most optimal one. Users are
expected to override these implementations as needed. A clear example of
this is libgloss or libnosys in newlib.


For RISC-V, while the cycle register is accessible, it can only be read in
machine or supervisor mode. This makes it unsuitable for some scenarios,
such as when beginner developers are experimenting with qemu in user mode.
Personally, I expect that if a target system has a more appropriate
implementation, it would override the default one provided by newlib.


Moreover, using the clock function requires the correct definition of
CLOCKS_PER_SEC, which is highly platform-dependent. The current
implementation relies on the existence of a time syscall to work
properly—even though we all know this approach is somewhat indirect and
inefficient.


So ultimately, I think many newlib functions are designed to be generic
implementations rather than the best possible ones. For RISC-V, I don’t
think we necessarily need to implement clock by directly reading the cycle
register. Instead, we should leave it to the BSP or SDK that uses newlib to
provide the appropriate override.



---






Christian Herber (OSS) <[email protected]> 於 2024年10月30日 週三
21:15 寫道：

> Hi all,
>
> I have a question regarding the current implementation libc for RISC-V.
> There is no machine specific implementation of clock(). A call to the
> clock() function will call times() eventually lead to a syscall requesting
> the time, and converting that back to clock cycles.
> I see such a machine specific port has been done for few architectures
> only (in fact, I only see nvptx). I am sure more architectures have
> instructions to obtain cycles, why is this not used more?
>
> RISC-V defines a register called cycle (and cycleh for RV32), which
> provides and easy access to clock cycles.
> It is part of the Zicntr extension, which nearly all implementations
> support, and that should be possible to check through a marco __riscv_zicsr
> (did not test if the compilers actually do that, but they should).
>
> I cannot imagine many benefits for preferring the syscall (which will
> likely involve converting cycles to seconds / ns and back) rather than
> using the register, so I wanted to check if there is something I am missing.
>
> Christian
>
>
>