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