<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 10/22/2017 9:20 PM, Ken Phillis Jr
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACiKS=SLzVBUh5Dj=9RTDTC0Oqdz32s3_n1XQebLoGQdaeSkFA@mail.gmail.com">
<div dir="ltr">
<div>On Thu, Oct 22, 2017 at 7:09 AM, Christopher Friedt
<chrisfriedt at <a href="http://gmail.com" target="_blank"
moz-do-not-send="true">gmail.com</a>> wrote: <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I
would assume that there RO registers somewhere that contain
that<br>
information. ARM does that, and I assume that most other
arch's do as well<br>
(except for, maybe x86*). Why add another instruction for
something that<br>
would effectively provide zero gain?</blockquote>
<div><br>
</div>
<div><br>
</div>
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.<br>
</div>
<br>
</blockquote>
<br>
(breaking silence for now).<br>
<br>
really, from the way SuperH does things, it would make more sense to
ask for CPUID as a feature accessed via MMIO.<br>
<br>
say, hypothetically, you have an address range like 1F008000 or
something, say:<br>
FF008000: Magic1<br>
FF008004: Magic2<br>
FF008008: Magic3<br>
FF00800C: Magic4 / Machine Sub-Arch<br>
FF008010: Arch Feature Flags<br>
...<br>
<br>
granted, I am not currently aware of anything like this existing.<br>
I guess the first real priority would be identifying a good address
range and register layout.<br>
<br>
the magic fields would hint how to decode the rest of the
information say, if they contained something like:<br>
"TrueCoreJ4 "<br>
the other fields may differ from, say:<br>
"DicyDealBJX1"<br>
or whatever else...<br>
<br>
one might be a mostly vanilla SH4...<br>
and the other might have all these crazy and questionable extensions
glued on but otherwise still be pretty terrible...<br>
<br>
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, *, ...).<br>
<br>
*: "back in my day, you would access your memory as 'MOV AX,
[ES:BX+SI]' and you would like it!".<br>
cough, or in a certain unnamed experimental ISA, stuff like:<br>
"MOV #disp24, R0; MOV.L @(PC, R0), R9"<br>
"but you need multiple operations and a fixed register to do
the load?!"<br>
"do you really expect to do much better with ops limited to
either 16 or 32 bits?..."<br>
( then other person goes into an argument about why one
should be doing M68K instead, ... )<br>
...<br>
<br>
</body>
</html>