This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Any existing routine for CPU-id on Cygwin?


On 5 Mar 2002 at 22:34, Tim Prince wrote:

> On Tuesday 05 March 2002 17:55, soren_andersen@fastmail.fm wrote:
> > Hello,
> >
> > I was just wondering if there is any existing code that's perhaps part of
> > the Cygwin "code base" or else known to some readers, that will allow
> > querying of the CPU type?
> >
> > I'd like to have a pretty simple way to get this. One application would be
> > an enhanced "configure" for zlib-1.1.3 which would place the appropriate
> > assembler source for a 486, a 586 or a 686 -- for example -- into the
> > Makefile build formulae. I need only the "generation" of chip, i.e. what
> > Intel calls the "Family."
> >
> > I am thinking that maybe somebody already worked this out. I am also
> > thinking that instead, maybe the way this is done is in assembler and if so
> > maybe it hasn't been done (specific to Cygwin, that is; I have found a
> > couple of free utilities out there that do this from a  command line). I am
> > just full of semi-educated guesses ;-).
> >
> 
> It's not OS-specific.  Any gcc code which does what you want should work, or 
> you could translate MS-style asm() syntax, as I did here:
> #include <windows.h>
> #define FAMILY_ID        0x0f00   // EAX[11:8] - Bit 11 thru 8 contains family
>         unsigned int reg_eax = 0;
>         unsigned int reg_edx = 0;
>         unsigned int junk, junk1;
>         unsigned int vendor_id[3] = {0, 0, 0};
>         __try {                    // verify cpuid instruction is supported
>             __asm__("cpuid" : "=a" (reg_eax), "=b" (*vendor_id),
>                   "=c" (vendor_id[2]), "=d" (vendor_id[1]) : "a" (0));
>             __asm__("cpuid" : "=a" (reg_eax), "=b"(junk), "=c"(junk1),
>                    "=d" (reg_edx) : "a" (1));
>                           // eax contains cpu family type info
>                         // edx has info whether Hyper-Threading
>   // Technology is available
>         }
>         __except (EXCEPTION_EXECUTE_HANDLER ) {
>                 return NO_CPUID;        // CPUID is not supported and so
>                                        // it is not a recent family CPU
>         }
> return (reg_eax & FAMILY_ID);

==============

That is, uhh, _WAY_COOL_ ;-). Thank you! I very much appreciate this ... and it challenges 
me (because asm makes my head hurt...).

TMTOWTDI: yours is no doubt FAR better, but just to prove that I am telling the truth when 
(in my other recent List msg) I maintain that I am not a C programmer... I cooked up my 
own solution using the ANSI library functions below. And then wrapped it in a autoconf 
macro so it can be included in "aclocal.m4".

Now (having exposed myself this way) maybe "some people" will learn to stop writing 
"submit a patch" back at me... ;-P

------------ watch for bad wrapping and low-flying owls ----------

dnl Copyright (c)2002 by Soren Andersen - written Wednesday, March 06, 2002
dnl Released under FSF GPL.
AC_DEFUN([AM_INTEL_CPU],
[AC_CACHE_CHECK(for the Intel CPU generation, am_cv_localhardware_INTELcpu,
[AC_TRY_RUN([
#include <sys/utsname.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

int
main ()
{
     struct utsname thishost;
     char *intelNum;
     FILE *datout;
 if (uname(&thishost) < 0) {
     exit(1);
 }

 intelNum = strchr(thishost.machine, 'i');
 if( intelNum != NULL && strspn(++intelNum,"23456789") == 3 )
 {
	 if( ( datout = fopen("conftest_cpu.data", "wb") ) != NULL )
	 {
		 fprintf( datout, "%3s", intelNum );
		 fclose( datout );
		 exit(0);
	 }
 }
  else {  exit(1);  }

}
], am_cv_localhardware_INTELcpu=`cat conftest_cpu.data`, 
am_cv_localhardware_INTELcpu=no, am_cv_localhardware_INTELcpu=no)])
test $am_cv_localhardware_INTELcpu = no || CPU=$am_cv_localhardware_INTELcpu
AC_SUBST(CPU)dnl
])

----------- end wrap- and owl- watch -------------------------------

The "only trouble" (ha-ha) with the above is that I know it *must* duplicate some routines 
found as part of the existing `autoconf' package macros. I just do not know, however, how 
to check (in a configure script) for the existence of a "host_cpu" autoconf value in order to 
skip my slow code and use that instead. Yes, I am fishing for autoconf pointers here.

  Best,
     Soren Andersen


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]