I am trying to set up a flexible infrastructure for the assembly code. Basically what I want is configure.in determination of basic machine type (intel/compatible, alpha, ppc), then within that (say intel) the code will detect variants like MMX, SSE, and use the right routines. I know how to do the second, but what is a good way to do the first? Linux/Cygwin/Solaris seem to support the MACHTYPE environment variable. Is uname -m or uname -p more reliable? Is there a simple way than knowing all the uname -m variants that mean intel 386 compatible? (i386, i586, i686, athlon? etc). Josh __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
On Tue, May 22, 2001 at 05:15:36PM -0700, Josh Coalson wrote:> I am trying to set up a flexible infrastructure for the assembly > code. Basically what I want is configure.in determination of > basic machine type (intel/compatible, alpha, ppc), then within > that (say intel) the code will detect variants like MMX, SSE, > and use the right routines. > > I know how to do the second, but what is a good way to do the first? > Linux/Cygwin/Solaris seem to support the MACHTYPE environment variable. > Is uname -m or uname -p more reliable? Is there a simple way than > knowing all the uname -m variants that mean intel 386 compatible? > (i386, i586, i686, athlon? etc).The best way to do this is to let autoconf work its magic for you. Use AC_CANONICAL_TARGET in configure.in, and it will place canonical system type for the target in the shell variable 'target' in the form CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM. Be sure to use the target, not the host, to allow cross-compiling. It will also be broken out into target_cpu, target_vendor and target_os. So you can use $target_cpu for your tests. A simple: case $target_cpu in i*86) blahblah ;; powerpc) blahblah ;; sparc) blahblah ;; esac should do the trick. If you'd rather do the computation in the makefile, you can just AC_SUBST these in (automake might do this automagically; I'm not sure). For example, on this system, it's 'i686-pc-linux-gnu'. On a Solaris system I happened to check, it's 'sparc-sun-solaris2.8' (where kernel and operating system give the same information, the latter is omitted). This is computed by the shell script config.guess, if you want to play around with it. It has evolved over the years to recognize many, many systems. Athlon, AFAIK, is an i686. -- - mdz
Christian Weisgerber
2004-Sep-10 16:45 UTC
[Flac-dev] Re: detecting host machine in configure.in?
Josh Coalson <xflac@yahoo.com> wrote:> Basically what I want is configure.in determination of > basic machine type (intel/compatible, alpha, ppc), then within > that (say intel) the code will detect variants like MMX, SSE, > and use the right routines.Please include a way to disable processor-specific optimizations. Some people need to be able to build (for example) generic i386 packages, no matter whether the build machine happens to support SSE etc.> I know how to do the second, but what is a good way to do the first?Follow Matt's suggestion. Note that target_cpu = i386 doesn't (portably) imply an actual i386 but rather an x86-family processor.> Is uname -m or uname -p more reliable?You don't want to have to deal with those. Their output can vary widely on different platforms, e.g.: Solaris: -m sun4m -p sparc OpenBSD: -m sparc -p SUNW,SPARCstation-20, TMS390Z50 v0 or TMS390Z55 @ 75 MHz, on-chip FPU -- Christian "naddy" Weisgerber naddy@mips.inka.de
Matt Zimmerman
2004-Sep-10 16:45 UTC
[Flac-dev] Re: detecting host machine in configure.in?
On Wed, May 23, 2001 at 11:36:04AM +0000, Christian Weisgerber wrote:> Josh Coalson <xflac@yahoo.com> wrote: > > > Basically what I want is configure.in determination of > > basic machine type (intel/compatible, alpha, ppc), then within > > that (say intel) the code will detect variants like MMX, SSE, > > and use the right routines. > > Please include a way to disable processor-specific optimizations. > Some people need to be able to build (for example) generic i386 > packages, no matter whether the build machine happens to support > SSE etc.If the autoconf macros are used, the target can be overridden on the configure command line (e.g. configure --target=i386-openbsd). -- - mdz
--- Christian Weisgerber <naddy@mips.inka.de> wrote:> Josh Coalson <xflac@yahoo.com> wrote: > > > Basically what I want is configure.in determination of > > basic machine type (intel/compatible, alpha, ppc), then within > > that (say intel) the code will detect variants like MMX, SSE, > > and use the right routines. > > Please include a way to disable processor-specific optimizations. > Some people need to be able to build (for example) generic i386 > packages, no matter whether the build machine happens to support > SSE etc. >ok, all good ideas. I have made the changes to configure.in and various Makefile.am's. I added the cpu checking (based on $host_cpu) and an option to disable all asm optimizations (--disable-asm-optimizations). but since I'm not too saavy with autoconf/automake I'll ask for a little bit more help. I think the only non-functional part left is that automake doesn't support source files that are in subdirectories, relative to Makefile.am(?) the layout in src/libFLAC/ is that all asm sources will go under a 'cputype' directory (e.g. src/libFLAC/i386/ for x86 sources). having to put them all in src/libFLAC/ would be a mess later. can you guys take a look and advise? Josh __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
On Tue, May 22, 2001 at 10:52:59PM -0400, Matt Zimmerman wrote:> The best way to do this is to let autoconf work its magic for you. Use > AC_CANONICAL_TARGET in configure.in, and it will place canonical system type > for the target in the shell variable 'target' in the form > CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM. Be sure to use the target, > not the host, to allow cross-compiling. It will also be broken out into > target_cpu, target_vendor and target_os. So you can use $target_cpu for your > tests. A simple:I seem to have been confused here...what you want is actually AC_CANONICAL_HOST, and the host_* variables. I have seen programs use target_* for this purpose, but now that I look at the definitions in the autoconf documentation, they appear to be doing the wrong thing: `--build=BUILD-TYPE' the type of system on which the package is being configured and compiled. `--host=HOST-TYPE' the type of system on which the package will run. `--target=TARGET-TYPE' the type of system for which any compiler tools in the package will produce code (rarely needed). By default, it is the same as host. -- - mdz