<div dir="auto">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?<br><br><div data-smartmail="gmail_signature">©<br><br>Sent from my Android</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Oct 22, 2017 12:20 AM, "Ken Phillis Jr" <<a href="mailto:kphillisjr@gmail.com">kphillisjr@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I figured I'd move the discussion of this Instruction out of the<br>
Kickstarter topic. In general this is an extremely small ROM table<br>
built into the processor that identifies the available features. This<br>
instruction is an excellent way to store information about the system<br>
without taking a lot of information. A few examples of this<br>
instruction are as follows...<br>
<br>
IBM System Z mainframe - This was introduced in 1983 with the IBM 4381<br>
mainframe as a method to query processor ID.<br>
<br>
ARM Processors - To my knowledge, these processors have the<br>
information divided out into seven different registers, and maybe<br>
more.<br>
<br>
MIPS Processors - This is a feature of MIPS32, and MIPS64.<br>
<br>
PowerPC Processors - This is under the Instruction name PVR. On these<br>
processors, this instruction is a static 32-bit value where the first<br>
16 bits are the Version, and the second 16 bits is revision.<br>
<br>
x86 Processors - This Instruction was first introduced over 20 years<br>
ago, and the size of the table in use today is at most 2048 bits.<br>
Although, realistically, most software and operating systems only<br>
check about 512 bits of the table at most.<br>
<br>
Now the reason for the CPUID Function is for relaying Highly Specific<br>
Hardware information about the current Processor/SoC in use. As far as<br>
space is concerned, this Instruction is extremely efficient since a<br>
lot of information can be conveyed using only 32 bytes ( 256-bits).<br>
For a comparison, the Smallest Device tree file for the Raspbery Pi is<br>
14.7 KB, this is 15,086 bytes. This means that the Device Tree is more<br>
than 400x bigger than a relatively large CPUID table.<br>
<br>
Some of the Information the CPUID Function can relay:<br>
* J-Core Version: Think J1, J2, J3, J4, etc.<br>
* CPUID table size<br>
* Vendor Identifier<br>
* Ram Controller Type, and Availability<br>
* Data Cache Size and availability<br>
* Instruction Cache Size and availability<br>
* Instruction Pre-fetch Availability<br>
* Memory Management Unit Availability<br>
* Symmetric Multiprocessing Availability<br>
* Number of Processor Cores<br>
* Floating Point Unit ( FPU ) availability and supported Floating<br>
point types/sizes<br>
* Fixed Point Math Unit Type/sizes<br>
* DSP/Vector Math Functionality<br>
* Availability of Instructions.<br>
______________________________<wbr>_________________<br>
J-core mailing list<br>
<a href="mailto:J-core@lists.j-core.org">J-core@lists.j-core.org</a><br>
<a href="http://lists.j-core.org/mailman/listinfo/j-core" rel="noreferrer" target="_blank">http://lists.j-core.org/<wbr>mailman/listinfo/j-core</a><br>
</blockquote></div></div>