[J-core] Instruction Request: Dedicated CPUID Function

[D. Jeff Dionne]

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.

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.

And I agree that the SuperH way is MMIO... but I also think that pushes getting the CPUID stuff correct to the SoC engineer, and I don't like that.  It is also the reason I've been an advocate of a 'standard' Coprocessor 0 (like MIPS).

Cheers.
J.

> On 10/22/2017 9:20 PM, Ken Phillis Jr wrote:
>> On Thu, Oct 22, 2017 at 7:09 AM, Christopher Friedt <chrisfriedt at gmail.com <http://gmail.com/>> wrote: 
>> I would assume that there RO registers somewhere that contain that
>> information. ARM does that, and I assume that most other arch's do as well
>> (except for, maybe x86*). Why add another instruction for something that
>> would effectively provide zero gain?
>> 
>> 
>> None of the processors based on this instruction has a CPUID style information included. This means that breakage between processor cores cannot be detected in software. This is based on available documentation for the SH-1, SH-2, SH-3, and Sh-4 cores.
>> 
> 
> (breaking silence for now).
> 
> really, from the way SuperH does things, it would make more sense to ask for CPUID as a feature accessed via MMIO.
> 
> say, hypothetically, you have an address range like 1F008000 or something, say:
>     FF008000: Magic1
>     FF008004: Magic2
>     FF008008: Magic3
>     FF00800C: Magic4 / Machine Sub-Arch
>     FF008010: Arch Feature Flags
>     ...
> 
> granted, I am not currently aware of anything like this existing.
> I guess the first real priority would be identifying a good address range and register layout.
> 
> the magic fields would hint how to decode the rest of the information say, if they contained something like:
>     "TrueCoreJ4  "
> the other fields may differ from, say:
>     "DicyDealBJX1"
> or whatever else...
> 
> one might be a mostly vanilla SH4...
> and the other might have all these crazy and questionable extensions glued on but otherwise still be pretty terrible...
> 
> but, then again, might be useful to be able to determine what sort of processor it is. this is, assuming one is not going old-school and detecting the CPU by detecting subtle differences in edge-case behavior between various instructions (because, often times, between vendors/implementations/processor generations/..., there were instructions which would generate subtly different results when executed, or special undocumented "pseudo instructions" which existed only on certain processors but would do something different or generate a fault on others, *, ...).
> 
> *: "back in my day, you would access your memory as 'MOV AX, [ES:BX+SI]' and you would like it!".
>     cough, or in a certain unnamed experimental ISA, stuff like:
>         "MOV #disp24, R0; MOV.L @(PC, R0), R9"
>         "but you need multiple operations and a fixed register to do the load?!"
>         "do you really expect to do much better with ops limited to either 16 or 32 bits?..."
>         ( then other person goes into an argument about why one should be doing M68K instead, ... )
>          ...
> 
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20171023/02ec22dd/attachment.html>