[J-core] Instruction Request: Dedicated CPUID Function
cr88192 at gmail.com
Sun Oct 22 23:57:46 EDT 2017
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
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:
the other fields may differ from, say:
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
"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...
More information about the J-core