* egcs and K6
@ 1999-03-11 4:58 Philipp Thomas
[not found] ` < 36E7BDD3.91BC3829@gwdg.de >
1999-03-31 23:46 ` Philipp Thomas
0 siblings, 2 replies; 6+ messages in thread
From: Philipp Thomas @ 1999-03-11 4:58 UTC (permalink / raw)
To: egcs
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.
--
Philipp
************************************************************
If builders would build houses like many programmers do
their programs, the first woodpecker to come along would
mean the end of all civilization
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: egcs and K6
[not found] ` < 36E7BDD3.91BC3829@gwdg.de >
@ 1999-03-17 21:09 ` Jeffrey A Law
1999-03-31 23:46 ` Jeffrey A Law
0 siblings, 1 reply; 6+ messages in thread
From: Jeffrey A Law @ 1999-03-17 21:09 UTC (permalink / raw)
To: Philipp Thomas; +Cc: egcs
In message < 36E7BDD3.91BC3829@gwdg.de >you write:
> 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 ?
Not really. Though I would recommend against defining i586 or pentium for
the k6.
I'd model the code around the stuff used to define __pentium__ and
__pentiumpro__ in CPP_CPU_DEFAULT_SPEC.
> 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 instructions does the k6 have that are not on the other x86 processors?
(aside from 3dnow!, which should have a switch unto itself).
> 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 ?
See i386.h. That provides the deafult.
Other files (freebsd.h for example) can override the default target cpu.
It can also be overridden by configure.in (search for target_cpu_default).
Note you may need an assignment before we can install the code. Please review
http://www.cygnus.com/egcs/contribute.html and take appropriate action before
submitting your patch.
jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: egcs and K6
1999-03-17 21:09 ` Jeffrey A Law
@ 1999-03-31 23:46 ` Jeffrey A Law
0 siblings, 0 replies; 6+ messages in thread
From: Jeffrey A Law @ 1999-03-31 23:46 UTC (permalink / raw)
To: Philipp Thomas; +Cc: egcs
In message < 36E7BDD3.91BC3829@gwdg.de >you write:
> 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 ?
Not really. Though I would recommend against defining i586 or pentium for
the k6.
I'd model the code around the stuff used to define __pentium__ and
__pentiumpro__ in CPP_CPU_DEFAULT_SPEC.
> 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 instructions does the k6 have that are not on the other x86 processors?
(aside from 3dnow!, which should have a switch unto itself).
> 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 ?
See i386.h. That provides the deafult.
Other files (freebsd.h for example) can override the default target cpu.
It can also be overridden by configure.in (search for target_cpu_default).
Note you may need an assignment before we can install the code. Please review
http://www.cygnus.com/egcs/contribute.html and take appropriate action before
submitting your patch.
jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* egcs and K6
1999-03-11 4:58 egcs and K6 Philipp Thomas
[not found] ` < 36E7BDD3.91BC3829@gwdg.de >
@ 1999-03-31 23:46 ` Philipp Thomas
1 sibling, 0 replies; 6+ messages in thread
From: Philipp Thomas @ 1999-03-31 23:46 UTC (permalink / raw)
To: egcs
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.
--
Philipp
************************************************************
If builders would build houses like many programmers do
their programs, the first woodpecker to come along would
mean the end of all civilization
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: egcs and K6
1999-03-12 16:32 Mike Stump
@ 1999-03-31 23:46 ` Mike Stump
0 siblings, 0 replies; 6+ messages in thread
From: Mike Stump @ 1999-03-31 23:46 UTC (permalink / raw)
To: egcs, kthomas
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: egcs and K6
@ 1999-03-12 16:32 Mike Stump
1999-03-31 23:46 ` Mike Stump
0 siblings, 1 reply; 6+ messages in thread
From: Mike Stump @ 1999-03-12 16:32 UTC (permalink / raw)
To: egcs, kthomas
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-03-31 23:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-03-11 4:58 egcs and K6 Philipp Thomas
[not found] ` < 36E7BDD3.91BC3829@gwdg.de >
1999-03-17 21:09 ` Jeffrey A Law
1999-03-31 23:46 ` Jeffrey A Law
1999-03-31 23:46 ` Philipp Thomas
1999-03-12 16:32 Mike Stump
1999-03-31 23:46 ` Mike Stump
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).