Would be interesting to have a feature to dump info in a binary file then read it from another machine, but then I think it'd only be useful for diagnostics.

I'll have to think this over.

Hi,

I'm seeing only 10 cores listed when running ddcpuid on both Posix and Win32:

$ dub run
Performing "debug" build using C:\Apps\DMD\dmd2\windows\bin64\dmd.exe for x86_64.
ddcpuid 0.21.0: building configuration "application"...
Linking...
Running ddcpuid.exe

Name:        GenuineIntel 12th Gen Intel(R) Core(TM) i7-12700KF
Identifier:  Family 0x6 Model 0x97 Stepping 0x2
Cores:       10 cores, 20 threads
Max. Memory: 512 GiB physical, 256 TiB virtual
Platform:    x86-64
Baseline:    x86-64-v3
Features:    eist turboboost htt
Extensions:  x87/fpu +f16c mmx intel64/x86-64 +lahf64 aes-ni adx sha bmi1 bmi2
SSE:         sse sse2 sse3 ssse3 sse4.1 sse4.2 fma
AVX:         avx avx2
AMX:
Mitigations: ibrs stibp ssbd l1d_flush md_clear cet_ibt cet_ss
ParaVirt.:   Hyper-V
Cache L1-D:   10x   48 KiB,  480 KiB total, si
Cache L1-I:   10x   32 KiB,  320 KiB total, si
Cache L2-U:    2x 1.25 MiB,  2.5 MiB total, si
Cache L3-U:    1x   25 MiB,   25 MiB total, si

Here's a comparison with CPU-Z:

It seems ddcpuid might be missing some of the L2 caches as well.

Here's the raw output if it helps:

| Leaf     | Sub-leaf | EAX      | EBX      | ECX      | EDX      |
|----------|----------|----------|----------|----------|----------|
|        0 |        0 |       1f | 756e6547 | 6c65746e | 49656e69 |
|        1 |        0 |    90672 | 4e800800 | fefaf383 | bfcbfbff |
|        2 |        0 |   feff01 |       f0 |        0 |        0 |
|        3 |        0 |        0 |        0 |        0 |        0 |
|        4 |        0 | fc004121 |  2c0003f |       3f |        0 |
|        5 |        0 |        0 |        0 |        0 |        0 |
|        6 |        0 |   1f8ff3 |        2 |        9 |    90003 |
|        7 |        0 |        1 | 239c27ab |   400784 | bc108410 |
|        8 |        0 |        0 |        0 |        0 |        0 |
|        9 |        0 |        0 |        0 |        0 |        0 |
|        a |        0 |  7300605 |        0 |        0 |      603 |
|        b |        0 |        1 |        2 |      100 |       4c |
|        c |        0 |        0 |        0 |        0 |        0 |
|        d |        0 |        7 |      340 |      340 |        0 |
|        e |        0 |        0 |        0 |        0 |        0 |
|        f |        0 |        0 |        0 |        0 |        0 |
|       10 |        0 |        0 |        0 |        0 |        0 |
|       11 |        0 |        0 |        0 |        0 |        0 |
|       12 |        0 |        0 |        0 |        0 |        0 |
|       13 |        0 |        0 |        0 |        0 |        0 |
|       14 |        0 |        1 |       5f | 80000007 |        0 |
|       15 |        0 |        2 |       bc |  249f000 |        0 |
|       16 |        0 |        0 |        0 |        0 |        0 |
|       17 |        0 |        0 |        0 |        0 |        0 |
|       18 |        0 |        0 |        0 |        0 |        0 |
|       19 |        0 |        0 |        0 |        0 |        0 |
|       1a |        0 | 20000001 |        0 |        0 |        0 |
|       1b |        0 |        0 |        0 |        0 |        0 |
|       1c |        0 |        0 |        0 |        0 |        0 |
|       1d |        0 |        0 |        0 |        0 |        0 |
|       1e |        0 |        0 |        0 |        0 |        0 |
|       1f |        0 |        1 |        2 |      100 |       4e |
| 40000000 |        0 | 4000000b | 7263694d | 666f736f | 76482074 |
| 40000001 |        0 | 31237648 |        0 |        0 |        0 |
| 40000002 |        0 |     4a61 |    a0000 |        2 |      7d6 |
| 40000003 |        0 |     bfff |   2bb9ff |        2 | 31fffbf6 |
| 40000004 |        0 |    60e14 |        0 |       2e |        0 |
| 40000005 |        0 |      400 |      400 |      fb4 |        0 |
| 40000006 |        0 |   8200af |        0 |        0 |        0 |
| 40000007 |        0 | 80000007 |        3 |        0 |        0 |
| 40000008 |        0 |        0 |        0 |        0 |        0 |
| 40000009 |        0 |        0 |        0 |        0 |        0 |
| 4000000a |        0 |        0 |        0 |        0 |        0 |
| 4000000b |        0 |        0 |        0 |        0 |        0 |
| 80000000 |        0 | 80000008 |        0 |        0 |        0 |
| 80000001 |        0 |        0 |        0 |      121 | 2c100800 |
| 80000002 |        0 | 68743231 | 6e654720 | 746e4920 | 52286c65 |
| 80000003 |        0 | 6f432029 | 54286572 | 6920294d | 32312d37 |
| 80000004 |        0 | 4b303037 |       46 |        0 |        0 |
| 80000005 |        0 |        0 |        0 |        0 |        0 |
| 80000006 |        0 |        0 |        0 |  5007040 |        0 |
| 80000007 |        0 |        0 |        0 |        0 |      100 |
| 80000008 |        0 |     3027 |        0 |        0 |        0 |

Since a certain someone managed to run ddcpuid on Windows NT 3.51 with, I believe, an original Pentium (thankfully baseline for dmd on i386 targets Pentium Pro) only has up to CPUID.01h, the program assumes CPUID.04h and crashes with a division by 0 error.

If CPUID.04h cannot be reached at the make to make out the topology, it's safe to assume 1 core 1 thread.

They serve nothing but to cause confusion for devs including me and wrongful categories.

And it's a waste of time on writing and interpreting these middle structures.

Potentially wasting a few bytes on alignment but that's not worrisome.

Processor families and models typically are tied to a microarchitecture as shown below for Intel processors.

For AMD processors:

This feature should be a function apart from the scanning process but part of the ddcpuid module. Used in the Summary view.

There must be a way to obtain the cache/core topology on 12th Gen Core Intel processors with hybrid configurations (of P/E cores) using CPUID.

The Optimizing Software for x86 Hybrid Architecture manual may have some info, but only finding bits for HARDWARE GUIDED SCHEDULING and INTEL® THREAD DIRECTOR.

It does indicate a leaf of 0x20, higher than the reference manual from June 2021 (latest at the time of writing) of 0x1f, and oddly the manual only references 0x21 and higher as being invalid.

It's in CPUID.1Fh, but I know no one with such processor.

Intel : p371 (May 2018), Vol. 1 15-3 §15.2 (CPUID.07H.EBX[16] = 1)

AMD : Need to check

Variable should be AVX512

Either at the (1) end (simpler), (2) unroll loop (performance but not worth it), or (3) mid-loop with conditional (if).

Opting for (3).

version: v0.18.1-17-gbc40cb7

Output:

Name:        GenuineIntel 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
Identifier:  Family 6 Model 140 Stepping 1
Cores:       4 cores 8 threads
Techs:       x86-64-v4 EIST TurboBoost-3.0 HTT
SSE:         SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2
AVX:         AVX AVX2 AVX512F +CD +DQ +BW +VL +IFMA +VBMI +VBMI2 +GFNI +VAES +VNNI +BITALG +VP2INTERSECT
AMX:         None
Others:      AES-NI ADX SHA BMI1 BMI2
Mitigations: IBRS STIBP SSBD L1D_FLUSH MD_CLEAR CET_IBT CET_SS
Cache L1-D:  4x 48KB    (192KB)
Cache L1-I:  4x 32KB    (128KB)
Cache L2-U:  4x 1MB     (5MB)
Cache L3-U:  1x 8MB     (8MB)

Table:

$ ddcpuid -r -S 4 -s 4
| Leaf     | Sub-leaf | EAX      | EBX      | ECX      | EDX      |
|----------|----------|----------|----------|----------|----------|
|        4 |        0 | 1c004121 |  2c0003f |       3f |        0 |
|        4 |        1 | 1c004122 |  1c0003f |       3f |        0 |
|        4 |        2 | 1c004143 |  4c0003f |      3ff |        0 |
|        4 |        3 | 1c03c163 |  1c0003f |     3fff |        4 |
|        4 |        4 |        0 |        0 |        0 |        0 |

Someone actually ran ddcpuid on an 80486DX2, and since OMF is still supported (for now), I think it may be worthwhile to:

• Test for FPU (FNINIT, Check SW).
• Test EFLAGS[ID] bit (CPUID instruction).

Low priority because OMF support is about to be kicked out sooner or later, and I have a project in the works to cover processors from 8086 to Pentium III.

Currently, there are only human-readable output, and it would be potentially decent to have something parsable.

segfault at 0 ip 00007fa7d71d3555 sp 00007fffbe0d3a38 error 4 in libgdruntime.so.76.0.3[7fa7d70f5000+117000]

Waiting for a more updated GCC/GDC package.

It's possible to support GDC, with its GAS syntax, with version (GNU).

I just need to learn GAS syntax and I should be fine.

While CPUID.01h.EDX[28], the HTT bit, denotes the HyperThreading Technology bit, the Q6600 returns to support it, while both the Intel's Ark website and Speccy repports otherwise.

So it's making me think if I'm missing something here.

Possible, but just want to avoid parsing text.

Intel: CPUID.16h.EAX[15:0]
AMD: TODO

On top of the processed Family and Model members, there should be the base and extended, family and model IDs.

Refs:

• Intel® Advanced Performance Extensions (Intel® APX) Software Enabling Introduction July 2023 Revision 1.0
• Intel® Advanced Performance Extensions (Intel® APX) Architecture Specification July 2023 Revision 1.0

Consider using bit fields in the CPUINFO structure instead of bytes for every feature. Possibly per sections (e.g. ACPI) and per extension group (e.g. SSE grouping SSE, SSE2, etc., and AVX512 and all its stuff).

This would benefit in a few areas:

• memset area is smaller to deal with
• avoids byte alignment (cache win?)
• saner structure management -- smaller structure size

We wouldn't really lose a whole lot in speed. At worse it's an inlined function/template that performs a single AND (&) operation.

This would be best implemented using uint (u32) fields. The VendorID could also be included in CPUINFO. The memset could be moved in the fetchInfo function. And CHECK could have an extra or two parameters.

TODO:

• Make branch feature-bitfields
• Move VendorID to CPUINFO
• Move memset operation in fetchInfo
• Populate CPUINFO with new fields
• Replace CHECK with something that checks register bit + sets bit on CPUINFO member (with enum value) so: (MEMBER, MEMBERBIT, REGISTER, FEATUREBIT)

if (REGISTER & FEATUREBIT)
    STRUCTURE.MEMBER |= MEMBERBIT;

• Make new member enum feature values (e.g. SSE.SSE2 or EXT_SSE2 or FEATURE_SSE_SSE2)
• Put new (REG & FEATURE) => SECTION |= FEATURE
• Run new CHECK replacement function
  • FUNCTION(MEMBER, FEATUREBIT, FEATURESTRING) => print if true

Description

While the current extensions section displays instructions added apart from extensions, it would be nice to show all added instructions per extensions in -d, which would replace the Extensions section (if -d.

Operation

IF `-d`
    Show all instructions per extensions and instructions not included in extensions
ELSE
    Show extensions only

Example

With -d

MMX
    MOVD, MOVQ, PACKSSDW, PACKSSWB, PACKUSWB, PUNPCKHBW, PUNPCKHDQ, PUNPCKHWD, PUNPCKLBW, PUNPCKLDQ, PUNPCKLWD
SSE
    ...

Without -d

Extensions: MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, Intel64, VT-x, Intel XD (NX), Intel TXT (SMX), AES-NI, AVX,

This is possible with the RDTSC instruction. There's an example set in AP-485.pdf (Intel® Processor Identification and the CPUID Instruction, May 2002).

The idea is to calculate the delta between two time-stamps like so:

Actual frequency = (Ending TSC value – Beginning TSC value) / reference period

However, I have no idea who to actually do this in D ASM. Most deltas I got was 21, and with a reference period of 100 would get me 2100 (MHz), but my processor runs at a supposed 1600 MHz at idle, 3400 MHz as its base clock and up to 3900 MHz with the turbo boost.

So we'll see.

Obviously, it's only a matter of time before OMF from DMD gets dropped, as it was marked deprecated around 2.100.

Currently, the omf (or sometimes labelled dm) builds allow ddcpuid to run on Windows XP and earlier (yes, even on Windows 95). MSCOFF was introduced in Windows Vista, and Vista minimum requirements cite an 800 MHz processor, which seems to be the Pentium III.

Therefore, OMF support will remain for a little while (a few minor versions after?), but at some point features aiming to support anything older than the Pentium III may be removed. I'm currently writing an application to cover processors from 8086 to Pentium II (mixed 16+32 code) and that may take some time.

That's for the application, but how about the library? I may maintain a "long-term" or "legacy" release, because it's likely some may use older compiler releases (or make a compiler to support OMF specifically). I'll keep thinking about it.

Since a certain someone managed to run ddcpuid on Windows NT 3.51 with, I believe, an original Pentium (thankfully baseline for dmd on i386 targets Pentium Pro) only has up to CPUID.01h, so it does not have CPUID.8000_0000h.

Alongside the Family, Model, and Stepping, it'd be nice if we could report the processor revision!

On the Pentium II, with CPUID.8000_0000h(ECX=0h), the value in EAX will be 03020101h which may confuse ddcpuid.

Getting checking against 0x4000_0000 and 0x8000_0000, the minimum and maximum (+0xfff_ffff) should be used to check again the input leaf

Like all the fancy fetch (e.g., neofetch, cpufetch, etc.) utilities, I could:

• print a small logo on top
• maybe make a two-column display with shortened info
  • Identifier: 0x06-0x3a-0x09
  • Cores: 4c8t
  • etc.

Low priority.

Proper binary dump and loading.

This will:

• Help diagnostics instead of reading CPUID tables.
• Help unittesting with specific processor models.

Implementation:

• Internals in main (function pointer setting destination, either table or file)
• Internals in ddcpuid
• View file content from dump. (print values)
• View summary from dump.
• View advanced details from dump.
• View CPUID table from dump.
• Unittest mechanism
  • e.g., expecting n cores with xyz model
  • cpuid register tables writing to temporary file

File layout:

• 4 bytes: "ddcd"
• 2 bytes: file version
• 2 bytes: major ddcpuid version
• 2 bytes: minor ddcpuid version
• 2 bytes: fix ddcpuid version
• foreach leaf:
  • 4 bytes: leaf
  • 4 bytes: sub-leaf
  • 4 bytes: eax
  • 4 bytes: ebx
  • 4 bytes: ecx
  • 4 bytes: edx

I'm currently getting incorrect thread count on my Pentium Silver N5000:

Vendor      : GenuineIntel
Brand       : Intel(R) Pentium(R) Silver N5000 CPU @ 1.10GHz
Identifier  : Family 6 (0x6) [0x6:0x0] Model 122 (0x7a) [0xa:0x7] Stepping 1
Cores       : 32 threads

CPUID dump attached

cpuid_dump.log

2 cores 4 threads isn't right for a processor that doesn't support htt

sadly the htt bit is assumed for the total thread count on intel platforms

L1 cache shared core count is OK (4x)

Input: 0x4
Sub: 0
EAX: 0xc000121
EBX: 0x1c0003f
ECX: 0x3f
EDX: 0x1

...If possible. Some people may be confused that L3 cache is usually shared across all cores and the L1 and L2 amounts is for a single core.

Refs:

• The Converged Vector ISA: Intel® Advanced Vector Extensions 10 Technical Paper July 2023 Revision 1.0
• Intel® Advanced Vector Extensions 10 Architecture Specification July 2023 Revision 1.0

Nasty (compiler?) bugs.

For the time being, try -version=I13, because I don't want to break my DMD/Windows working code

int ebx, ecx;
asm {
    mov EAX, 4;
    xor ECX, ECX;
    cpuid;
    mov ebx, EBX;
    mov ecx, ECX;
}
writefln("L1 Cache: %s",
    ((ebx >> 22) + 1) * (((ebx >> 12) & 0x3ff) + 1)
    * ((ebx & 0xfff) + 1) * (ecx + 1));

just a myself kinda note

Instead of Thing,(space), I think it'd be better to simply go for (space)Thing.

Some extensions may have an extension amount of sub-extensions (e.g. AVX512, AMX, TSX with HLE/RTM/TSXLDTRK, etc.), so it may be very worthwhile to move those.

This is purely a code thing so far. No plans to change the output.

Intel: CPUID.07H.0.ECX[22]

AMD: Not found

Cache detected is affected when running under a virtual guest.

Even cpufetch is affected (i7-3770):

L1i Size:   32KB (64KB Total)
L1d Size:   32KB (64KB Total)
L2 Size:    256KB (512KB Total)
L3 Size:    8MB (16MB Total)

0.18.1:

L1-D: 2x   32 KiB
L1-I: 2x   32 KiB
L2-U: 2x  256 KiB
L3-U: 2x    8 MiB

0.19-master:

Cache L1-D:  2x 32KB    (64KB)
Cache L1-I:  2x 32KB    (64KB)
Cache L2-U:  2x 256KB   (512KB)
Cache L3-U:  2x 8MB     (16MB)

Now I haven't really checked if this is due to the Hyper-V paravirtualization in VirtualBox but this seems to be appearing frequently. I will have to do another post with different virtual platforms (e.g., VMware, VirtualBox, KVM, QEMU, etc.) and paravirtualization platforms.

From the AMD manual:

The processor Family identifies one or more processors as belonging to a group that possesses some common definition for software or hardware purposes. The Model specifies one instance of a
processor family. The Stepping identifies a particular version of a specific model. Therefore, Family, Model and Stepping, when taken together, form a unique identification or signature for a processor.

The Family is an 8-bit value and is defined as: Family[7:0] = ({0000b,BaseFamily[3:0]} +
ExtFamily[7:0]). For example, if BaseFamily[3:0] = Fh and ExtFamily[7:0] = 01h, then Family[7:0] = 10h. If BaseFamily[3:0] is less than Fh, then ExtFamily is reserved and Family is equal to
BaseFamily[3:0].

Model is an 8-bit value and is defined as: Model[7:0] = {ExtModel[3:0],BaseModel[3:0]}. For
example, if ExtModel[3:0] = Eh and BaseModel[3:0] = 8h, then Model[7:0] = E8h. If BaseFamily[3:0]
is less than 0Fh, then ExtModel is reserved and Model is equal to BaseModel[3:0].

From the Intel manual:

The Extended Family ID needs to be examined only when the Family ID is 0FH. Integrate the fields into a display using the following rule:
IF Family_ID  ≠ 0FH
  THEN DisplayFamily = Family_ID;
ELSE DisplayFamily = Extended_Family_ID + Family_ID;
(* Right justify and zero-extend 4-bit field. *)
FI;

The Extended Model ID needs to be examined only when the Family ID is 06H or 0FH. Integrate the field into a display using the following rule:

IF (Family_ID = 06H or Family_ID = 0FH)
  THEN DisplayModel = (Extended_Model_ID « 4) + Model_ID;
(* Right justify and zero-extend 4-bit field; display Model_ID as HEX field.*)
ELSE DisplayModel = Model_ID;
FI;

e.g. doing +M +C will show cache and memory features.

By prettier, I mean grids, either by * or -, | and +:

+--------+
| Hello! |
+--------+

Arguments like -Vo should be interpreted as -V -o, while keeping to use the old format as an option.