[J-core] Instruction Request: Dedicated CPUID Function

Christopher Friedt chrisfriedt at gmail.com
Sun Oct 22 08:09:31 EDT 2017


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?

©

Sent from my Android

On Oct 22, 2017 12:20 AM, "Ken Phillis Jr" <kphillisjr at gmail.com> wrote:

> I figured I'd move the discussion of this Instruction out of the
> Kickstarter topic. In general this is an extremely small ROM table
> built into the processor that identifies the available features. This
> instruction is an excellent way to store information about the system
> without taking a lot of information. A few examples of this
> instruction are as follows...
>
> IBM System Z mainframe - This was introduced in 1983 with the IBM 4381
> mainframe as a method to query processor ID.
>
> ARM Processors - To my knowledge, these processors have the
> information divided out into seven different registers, and maybe
> more.
>
> MIPS Processors - This is a feature of MIPS32, and MIPS64.
>
> PowerPC Processors - This is under the Instruction name PVR. On these
> processors, this instruction is a static 32-bit value where the first
> 16 bits are the Version, and the second 16 bits is revision.
>
> x86 Processors - This Instruction was first introduced over 20 years
> ago, and the size of the table in use today is at most 2048 bits.
> Although, realistically, most software and operating systems only
> check about 512 bits of the table at most.
>
> Now the reason for the CPUID Function is for relaying Highly Specific
> Hardware information about the current Processor/SoC in use. As far as
> space is concerned, this Instruction is extremely efficient since a
> lot of information can be conveyed using only 32 bytes ( 256-bits).
> For a comparison, the Smallest Device tree file for the Raspbery Pi is
> 14.7 KB, this is 15,086 bytes. This means that the Device Tree is more
> than 400x bigger than a relatively large CPUID table.
>
> Some of the Information the CPUID Function can relay:
> * J-Core Version: Think J1, J2, J3, J4, etc.
> * CPUID table size
> * Vendor Identifier
> * Ram Controller Type, and Availability
> * Data Cache Size and availability
> * Instruction Cache Size and availability
> * Instruction Pre-fetch Availability
> * Memory Management Unit Availability
> * Symmetric Multiprocessing Availability
> * Number of Processor Cores
> * Floating Point Unit ( FPU ) availability and supported Floating
> point types/sizes
> * Fixed Point Math Unit Type/sizes
> * DSP/Vector Math Functionality
> * Availability of Instructions.
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20171022/713a8660/attachment.html>


More information about the J-core mailing list