[J-core] Instruction Request: Dedicated CPUID Function

[BGB]

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, ... )
          ...

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