[J-core] Instruction Request: Dedicated CPUID Function

[Cedric BAIL]

On Sun, Oct 22, 2017 at 9:11 PM, D. Jeff Dionne
<Jeff at se-instruments.co.jp> wrote:
> On Oct 23, 2017, at 12:57, BGB <cr88192 at gmail.com> wrote:
> This is an ongoing discussion here also.  Right now, the Device Tree is
> always in ROM, and that has basically obviated the need to solve the problem
> more generally.
>
> I am attracted to the core having a sort of CPUID instruction, but as
> pointed out in the thread, this was not done on legacy SH cores.  Accepting
> that legacy SH cores will need to be dealt with separately (this is no
> matter what we choose the case anyway), we should therefore do something
> that covers all the use cases.

I am not sure that anyone else, but the kernel really need to know
about this. On ARM if you want to check that NEON is available you
just do :

   aux = getauxval(AT_HWCAP);

   if (aux & HWCAP_NEON)
       /* Has NEON */

This avoid to have to deal with any kind of inline assembly,
portability issues and can rely on the kernel providing the
information which it should have anyway from the device tree. I don't
think there is a real case where cpuid is in the hot path of anything,
so adding an instruction for it doesn't seems necessary.

> CPUs are separate from SoC components.   Tightly tied things (cache,
> system/interrupt controller) one could make an argument should be in a CPU
> ID register.  And this leads to the conclusion that perhaps that is where it
> lives... the system controller (which I have envisioned being co-processor
> 0).
>
> Separately, there is the question of the SoC components.  I suggest this
> looks like device tree.  We (SEI) have a pile of things that are in our
> implementations that others would not have (measurement stuff, precision
> timing...) and that stuff should be enumerated as 'vendor' cores.  OTOH, if
> the tree is some kb in size, that is not attractive.

The tree is processed by the kernel in all case and valuable
information to user space like this can be exposed via existing Linux
API I think. I guess Rich would have some better insight about my
assumption than myself.

Cedric