Scott Cheloha <scottchel...@gmail.com> wrote:
> > - __asm volatile("rd %%sys_tick, %0" : "=r" (tick) :);
> > + __asm volatile("rd %%sys_tick, %0" : "=r" (tick));
> >
> > return (tick & ~0u);
> > }
>
> The only thing that gives me pause is the inline assembly.
>
> I know it isn't a lot of assembly, but would it be a layer violation to
> put, e.g.
>
> uint64_t
> rd_systick(void)
> {
> uint64_t val;
>
> __asm volatile("rd %%sys_tick, %0" : "=r" (val));
>
> return val;
> }
>
> into something like sys/arch/sparc64/include/cpufunc.h and use it
> in both the kernel and libc?
I don't see anything which precludes libc doing __asm calls, itself,
and I don't think we need to use cpp or inline declarations to cheat.
It is not impossible for userland and kernel use of such "macros" to
change, and would it be OK for libc to "abi change" (note little abi)
because an include file changed? I don't think that's nice.
> In general isn't it nicer to write it once?
In general yes. But in the specific, I don't think so.
> We could do the same thing on other platforms too for select
> instructions that are useful in both libc and the kernel.
Until the general rule breaks down, in a variety of ways. At which
point, why replace a simple thing with a spread out abstraction?
It is already impossible for the abstraction to MI and invisible, it
must be MD (because some architectures have more than 1 counter to look
at)
