Re: Target processor detection

[Richard Guenther <richard dot guenther at gmail dot com>]

On 11/22/05, Jim Wilson <wilson@specifix.com> wrote:
> Piotr Wyderski wrote:
> > I am working on a portable low-level library of atomic operations,
>
> Like the existing libatomic-ops package?
>
> > Why does __sparc_v9__ depend on the number of bits instead of the -mcpu?
> > Is this a GCC bug? I've found an e-mail by Jakub Jelinek, which claims, that
>
> Jakub was probably describing how it works on linux.  On Solaris, Sun
> sets the standard, and we have to follow Sun's lead here.  It appears
> that the Sun compiler only defines __sparc_v9 for 64-bit compiles, so
> gcc must do so also.  This is done in the gcc/config/sparc/sol2-bi.h
> file which is only used for solaris2.7 and up.  If this assumption about
> the Sun compiler is wrong, then this is a gcc bug.  Otherwise, no.
>
> >     -mcpu=i386 => __i386 = 300
>
> I think this could get confusing very quickly.  What values do we use
> for AMD parts?  What values do we use for PentiumD parts which have
> 3-digit part numbers that conflict with this scheme?
>
> This info may also not be accurate enough to be useful in the end.
> Different pentium4 cores have different sets of features.  So just
> knowing that something is a P4 isn't good enough to know what
> instructions exist.  You have to have run time checks to read system
> registers that contain info about what hardware features are present.

Like f.i. as I proposed in
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00965.html
maybe you could comment on that approach.  Sofar the feedback was negative,
so I didn't yet work further on it.

Richard.

> --
> Jim Wilson, GNU Tools Support, http://www.specifix.com
>