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)

[mgdaniel]

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

Thanks. That would be better. I noticed the bounds issue too and thinking it must be benign (presumably in production for a couple of years plus) allowed for it in the code.

Code: Select all

#ifdef __x86_64

#define exe$gpq_swrpb EXE$GPQ_SWRPB
#pragma message save
#pragma message disable (mayhideloss)
#include <x86_cpuid_info.h>
#pragma message restore

/* +1 due buf[49] = '\0'; */
static char HttpdX86brand [49+1];

static int HttpdKrnlX86CpuInfo (long *arglist)
{
   int  status;
   status = x86_cpuid_get_brand_string (sizeof(HttpdX86brand), HttpdX86brand);
   return (status);
}

static char* HttpdX86CpuInfo ()

{
   int  status;
   status = sys$cmkrnl (&HttpdKrnlX86CpuInfo, 0);
   if (VMSnok (status)) sprintf (HttpdX86brand, " (%%X%08.08X)", status);
   return (HttpdX86brand);
}

#endif

[roberbrooks]

I am considering making the CPUID data available by SYS/LIB/F$GETSYI item codes.

I have no idea how complete our implementation of providing that data is, nor do I know
how possible it is to return potentially-complicated data via that interface. I'm not particularly
fond of incomplete implementations, but it may be that 90% is better than not. I'd like to make it readily available for all languages, not just C/C++/X86_64 assembler.

Thoughts?

[mgdaniel]

+1
It would be useful supplementary information in general and for such tools as @VUPS.COM
WASD's use:

Code: Select all

System: innotek GmbH VirtualBox "Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz" with 3 CPUs and 7GB running VMS V9.2-2

[arne_v]

I am considering making the CPUID data available by SYS/LIB/F$GETSYI item codes.

I have no idea how complete our implementation of providing that data is, nor do I know
how possible it is to return potentially-complicated data via that interface. I'm not particularly
fond of incomplete implementations, but it may be that 90% is better than not. I'd like to make it readily available for all languages, not just C/C++/X86_64 assembler.

Thoughts?

Super idea.

Available to all languages. No need for privs. Taking it from cache => efficient. Documented.

What is not to like.

Traditional VMS style with one itemcode per item returning either integer or string?

(single item code returning a block requires a record definition per language)