Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Epoch: 1015456069 X-Sasl-enc: mE17N7AyhbFcP17br+C0Nw From: "Soren Andersen" To: cygwin AT cygwin DOT com Date: Wed, 6 Mar 2002 18:07:53 -0500 MIME-Version: 1.0 Subject: Re: Any existing routine for CPU-id on Cygwin? Reply-To: soren_andersen AT speedymail DOT org Message-ID: <3C865AF9.16806.3E6582E@localhost> In-reply-to: <20020306063437.EEA8E2CD4A@inet1.ywave.com> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body On 5 Mar 2002 at 22:34, Tim Prince wrote: > On Tuesday 05 March 2002 17:55, soren_andersen AT fastmail DOT 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 > #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 #include #include #include 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/