does cc for x86 support asm ?

[crgnz]

Sorry if this is more of a "porting from unix" question rather than a specific DEC C for x86 query but I'll ask anyway:

I'm trying to port this function:

Code: Select all

static void __cpuid(int dst[4], int ax) {
 
	asm volatile("cpuid"
		: "=a" (dst[0]), "=b" (dst[1]), "=c" (dst[2]), "=d" (dst[3])
		: "0" (ax)); 
}

#pragma intrinsic (__cpuid)

I kept getting all sorts of compiler issues. Here is my shortest code as an example of the sort of errors I was getting:

Code: Select all

#include <c_asm.h> 
static void dumbtest() {
 	asm("cpuid;" );
 }
#pragma intrinsic (__cpuid)

but I get the compiler error:

Code: Select all

        asm("cpuid 
........^
%CC-E-ASMNOTAVAIL, In-line assembly code directive asm is not available on this platform.

Its been 15+ years since I did any programming on OpenVMS, let alone try anything on the x86 Community release, so I'm way out of my depth here!

Any suggestions on how I can port the __cpuid() function to OpenVMS x86? Or maybe I should just hardcode the result as a work around for now... (only half joking)

[arne_v]

You need to use clang instead of cc.

Code: Select all

$ type asmtest.c
#include <stdio.h>

int main()
{
    asm("nop");
    printf("all good\n");
    return 0;
}
$ cc asmtest

    asm("nop");
....^
%CC-I-IMPLICITFUNC, In this statement, the identifier "asm" is implicitly declared as a function.
at line number 5 in file DKA0:[arne]asmtest.c;1
$ link asmtest
%ILINK-W-NUDFSYMS, 1 undefined symbol:
%ILINK-I-UDFSYM,        ASM
%ILINK-W-USEUNDEF, undefined symbol ASM referenced
        section: $CODE$
        offset: %X0000000000000010
        module: ASMTEST
        file: DKA0:[arne]asmtest.OBJ;3
$ clang asmtest.c
$ link asmtest
$ run asmtest
all good

[dgordon]

While not an answer to your general question, I can at least help a bit with your specific need, though it might be more complicated than you want.

SYS$LIB_C.TLB contains a header file X86_CPUID_INFO which should give you enough to go on to get the info you need. The macros in there are limited to the data that various parts of the OS require, but you should be able to extrapolate to any particular field you require. Add SYS$LIBRARY:SYS$LIB_C.TLB/LIBRARY to your compilation.

The magic behind this is that the boot sequence stores a complete expansion of the CPUID tree into memory with a pointer stuffed in the Software Restart Parameter Block (Software RPB.) The SWRPB should be user read, IIRC.

Because this is LIB and not STARLET, the interface is not guaranteed, but in practice, this one is likely to stick around.

[hb]

For "porting from unix", you are probably better off with clang. You very likely don't need/want specific VSI C features.

Anyway, if you want to look at the CPU info that is available in memory, you can use SDA and the symbols shown in the mentioned include file.

Code: Select all

SDA> read sysdef
SDA> ex @exe$gpq_swrpb+swrpb$pq_cpuid_info
FFFFFFFF.82001284:  820012C0   "�..."
SDA> ex @.;400                             
00000000 00000000 00000000 00000000 49656E69 6C65746E 756E6547 0000000D  ....GenuntelineI................     FFFFFFFF.820012C0

Zeros suppressed from FFFFFFFF.820012E0 through FFFFFFFF.820016BF

SDA>

shows the first leaf. While in SDA, you can check if the memory in question is user readable. The last time I checked it was not.

[mgdaniel]

While not an answer to your general question, I can at least help a bit with your specific need, though it might be more complicated than you want.

SYS$LIB_C.TLB contains a header file X86_CPUID_INFO which should give you enough to go on to get the info you need. The macros in there are limited to the data that various parts of the OS require, but you should be able to extrapolate to any particular field you require. Add SYS$LIBRARY:SYS$LIB_C.TLB/LIBRARY to your compilation.

The magic behind this is that the boot sequence stores a complete expansion of the CPUID tree into memory with a pointer stuffed in the Software Restart Parameter Block (Software RPB.) The SWRPB should be user read, IIRC.

Because this is LIB and not STARLET, the interface is not guaranteed, but in practice, this one is likely to stick around.

Needs wrapping with at least sys$cmexec(), or sys$cmkrnl() it seems, otherwise

Code: Select all

%SYSTEM-F-ACCVIO, access violation, reason mask=05, virtual address=FFFFFFFF82001284, PC=0000000080000022, PS=0000001B

[jonesd]

Needs wrapping with at least sys$cmexec(), or sys$cmkrnl() it seems, otherwise

Code: Select all

%SYSTEM-F-ACCVIO, access violation, reason mask=05, virtual address=FFFFFFFF82001284, PC=0000000080000022, PS=0000001B

I'd be inclined to put all the inlined functions defined by the x86_cpuid_info header into a UWSS
so the that application itself doesn't need the privilege.

A casual inspection shows that x86_cpuid_get_brand_string() has an incorrect bounds check
on the output buffer (x86_cpuid_get_manufacturer_string() doesn't, though). Another way to
look at it is it is correctly checking for a minimum 49 byte buffer and incorrectly writing to the 50th byte.

[hb]

I'd be inclined to put all the inlined functions defined by the x86_cpuid_info header into a UWSS
so the that application itself doesn't need the privilege.

Please note,
- An application does not need privileges to execute the CPUID instruction.
- There is more CPU information available than what the current functions defined by the x86_cpuid_info header provide.
So a UWSS either has to mimic the function/sub-function interface of the CPUID instruction or provide all the supported functions. How many depends on the CPU and is in the first leaf.

CPUID is known to be an expensive instruction. So avoid it for retrieving information you already have. I have no idea whether it is more expensive than calling a (UW) system service. I suspect it is not. If VMS already has the information in memory, then the memory should be user readable. At least for now it seems much easier and less overhead to either use clang or write a simple assembler module, that just does a CPUID instruction.

[dgordon]

Sorry about that. I'd swear I used that info in the SWRPB from user mode while working on a test program during the Entropy for VMS project, but I might have just casually thrown in a CMKRNL in my test program.

I do know that the suggestion had been made to make the CPUID info U:R, and I thought it had happened.

--D

[jreagan]

And to answer the OP's first question. No, the C compiler does not support an asm() builtin. It isn't on our current roadmap. You can write your request on the back of a $100 bill and send it to us.

[dgordon]

A casual inspection shows that x86_cpuid_get_brand_string() has an incorrect bounds check
on the output buffer (x86_cpuid_get_manufacturer_string() doesn't, though). Another way to
look at it is it is correctly checking for a minimum 49 byte buffer and incorrectly writing to the 50th byte.

I've opened a ticket for this.

I've also prodded the ticket to make the CPUID structures referenced off the SWRPB to be user-readable.

--D