[Feature-request/CPU-ID] For x86 CPUs, provide a way to include the processor instruction set capabilities within the platform predicate component

[pavly-gerges]

Problem definition:

A request to build an API that adds the CPU-ID output values to the PlatformPredicate for x86 processors through the NativeVariant propositions.

Solutions:

1. Examine the Electrostatic-Sandbox SDK capabilities and downsides (e.g., mainly ONLY GNU/Linux systems).
2. Examine the OSHI JNA library and its downsides.
3. Examine the capability and the downsides of building a system call sub-library.

See:

• CentralProcessor.

[pavly-gerges]

A good example to start with, might be examining the output of this:
https://github.com/oshi/oshi/blob/master/oshi-demo/src/main/java/oshi/demo/ComputerID.java

[stephengold]

Another library that might be useful:

https://github.com/aecsocket/cpu-features-java

[pavly-gerges]

1. Examine the Electrostatic-Sandbox SDK capabilities and downsides (e.g., mainly ONLY GNU/Linux systems).

There is another interesting approach which is to introduce an API on the Electrostatic SDK, and link it with the Java binding Electrostatic4j....

The idea is to use the inline assembly which is the same on all platforms:

#include <stdio.h>

void cpuid(int level, int *eax, int *ebx, int *ecx, int *edx) {
    __asm__ __volatile__(
        "cpuid"
        : "=a" (*eax), "=b" (*ebx), "=c" (*ecx), "=d" (*edx)
        : "a" (level)
    );
}

int main() {
    int eax, ebx, ecx, edx;

    // Query vendor string and highest CPUID function
    cpuid(0, &eax, &ebx, &ecx, &edx);

    char vendor[13];
    *(int*)&vendor[0] = ebx;  // Copy EBX
    *(int*)&vendor[4] = edx;  // Copy EDX
    *(int*)&vendor[8] = ecx;  // Copy ECX
    vendor[12] = '\0'; 
}

I would prefer this approach to better control the output... And, about building it can be provided in the form of simple native libraries for Mac, Windows, and Linux X86 platforms via GitHub CI/CD which is already up and running on the Electrostatic framework repository. What do you think? Are there any odds that might block us so far?

The complexity of loading this software component would be handled by JSnapLoader internally, so all you have to do is just add the additional dependency of the library that will be only responsible for this feature.

[stephengold]

That should be okay.