Re: egcs and K6

[mrs at wrs dot com (Mike Stump)]

> Date: Thu, 11 Mar 1999 13:57:55 +0100
> From: Philipp Thomas <kthomas@gwdg.de>
> To: egcs@egcs.cygnus.com

> I have a patch ready that I'll send to egcs-patches in a day or two,
> that mostly adds spec entries for the k6 to i386.h.

> What I do in specs is mostly defining k6 as well as i586 and
> pentium. The reasoning being that few if any software tests for k6
> (I intend to change that :). Any objections to this ? This is
> because I discovered to my horror that gcc only defines i386 when
> called with -mcpu=k6. I also added k6/no-k6 together with
> descriptions to TARGET_SWITCHES.

> What I haven't discovered up til now - and the real reason why I'm
> writing to the list - is how is the TARGET_CPU_DEFAULT determined ?
> My guess is its taken from the build host definition ?

> If that is so, could anybody enlighten me how to get the build
> process to set k6 as the default cpu so that I don't have to
> manually change the specs file ? If it really stems from configure,
> I guess I'd have to get the recognition of k6-* accepted by the
> autoconf maintainer.

This is where configure becomes an art.  The config triple contains
some information about a system, but not all information about a
system.  Suppose you have:

	 mycpu-myos

This doesn't mean that one must change it to:

	mycpuv2-myos

just because there is a difference, though one can.  The problem with
doing that are the 1000 packages that would otherwise work and
understand mycpu-myos, but fail to recognize mycpuv2.

It is possible to keep the triplet the same, and autoconf for the
rest. For example, on my system:

lair bash[11] cat /proc/cpuinfo 
processor       : 0
cpu             : 586
model           : 6
vendor_id       : AuthenticAMD
stepping        : 2
fdiv_bug        : no
hlt_bug         : no
fpu             : yes
fpu_exception   : yes
cpuid           : yes
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 mmx

autoconf can figure out that we are on a 586-amd with mmx support by
itself.  gcc can be taught to use this information and to pick the
default.

Now, a problem with this, if it is an often used or a highly desirable
option, cross builds becomes harder, you have to preload the autoconf
tests.

As to which is best.  Even though the worlds want to differentiate,
all the time, we really want to converge all this stuff.  Meaning,
reduce the differences, not amplify them.  I am for leaving the
triplets alone, and just autoconfing.