* config.guess/config.sub improvements
@ 1997-11-13 5:17 Lassi A. Tuura
0 siblings, 0 replies; 9+ messages in thread
From: Lassi A. Tuura @ 1997-11-13 5:17 UTC (permalink / raw)
To: egcs
[-- I already sent this to gcc2@cygnus.com, but then came to think
that perhaps I should send it to this list, too. Is that true
in general, or is it sufficient to send small patches like this
to gcc2 only? --]
Here is a patch for config.guess (from gcc-2.7.2.3) to correctly
determine processor types on HP's PA-RISC, plus small additions for
PowerPC LynxOS and cygwin32. For the cygwin32 entry I am not sure what
is the desired format; please check it.
The PA-RISC table for 800-series is rather complicated and I am not sure
if I got it right; it is correct for the entries I had in my
/opt/langtools/lib/sched.models. In particular, there are lots of
models missing from that file (probably still unassigned), so the
heuristics below might be incorrect for future models. If my
sched.models does not include all past models, then it might be
incorrect for older computers, too.
Cheers,
//lat
--
Lassi.Tuura@cern.ch There's no sunrise without a night
----------------------------------------------------------------
Thu Nov 6 18:48:03 1997 Lassi Tuura <lat@hpatl20.cern.ch>
* config.guess: more accurate determination of HP PA-RISC
processor types for 9000/[678]?? series machines, add support for
PowerPC on LynxOS and for Windows NT on CYGWIN32.
* config.sub: ditto.
*** /asis/src/GNU.LANG/gcc-2.7.2.3/config.guess Tue Jun 24 20:42:50 1997
--- config.guess Thu Nov 6 18:32:37 1997
***************
*** 219,226 ****
case "${UNAME_MACHINE}" in
9000/31? ) HP_ARCH=m68000 ;;
9000/[34]?? ) HP_ARCH=m68k ;;
! 9000/7?? | 9000/8?[79] ) HP_ARCH=hppa1.1 ;;
! 9000/8?? ) HP_ARCH=hppa1.0 ;;
esac
HPUX_REV=`echo ${UNAME_RELEASE}|sed -e 's/[^.]*.[0B]*//'`
echo ${HP_ARCH}-hp-hpux${HPUX_REV}
--- 219,231 ----
case "${UNAME_MACHINE}" in
9000/31? ) HP_ARCH=m68000 ;;
9000/[34]?? ) HP_ARCH=m68k ;;
! 9000/6?? ) HP_ARCH=hppa1.0 ;;
! 9000/78? ) HP_ARCH=hppa2.0 ;;
! 9000/7?? ) HP_ARCH=hppa1.1 ;;
! 9000/8[67]1 | 9000/80[24] | 9000/8[78]9 | 9000/893 )
! HP_ARCH=hppa2.0 ;;
! 9000/8?[13679] ) HP_ARCH=hppa1.1 ;;
! 9000/8?? ) HP_ARCH=hppa1.0 ;;
esac
HPUX_REV=`echo ${UNAME_RELEASE}|sed -e 's/[^.]*.[0B]*//'`
echo ${HP_ARCH}-hp-hpux${HPUX_REV}
***************
*** 364,369 ****
--- 359,367 ----
i[34]86:DYNIX/ptx:4*:*)
echo i386-sequent-sysv4
exit 0 ;;
+ i[3456]86:CYGWIN32/NT:*:*)
+ echo ${UNAME_MACHINE}-cygwin32-winnt${UNAME_RELEASE}
+ exit 0 ;;
i[34]86:*:4.*:* | i[34]86:SYSTEM_V:4.*:*)
if grep Novell /usr/include/link.h >/dev/null 2>/dev/null; then
echo ${UNAME_MACHINE}-univel-sysv${UNAME_RELEASE}
***************
*** 420,425 ****
--- 418,426 ----
TSUNAMI:LynxOS:2.[23]*:*)
echo sparc-lynx-lynxos${UNAME_RELEASE}
exit 0 ;;
+ PowerPC:LynxOS:2.[23]*:*)
+ echo powerpc-lynx-lynxos${UNAME_RELEASE}
+ exit 0 ;;
rs6000:LynxOS:2.[23]*:*)
echo rs6000-lynx-lynxos${UNAME_RELEASE}
exit 0 ;;
*** /asis/src/GNU.LANG/gcc-2.7.2.3/config.sub Tue Jun 24 20:42:50 1997
--- config.sub Thu Nov 6 19:02:04 1997
***************
*** 307,313 ****
hp9k3[2-9][0-9])
basic_machine=m68k-hp
;;
! hp9k7[0-9][0-9] | hp7[0-9][0-9] | hp9k8[0-9]7 | hp8[0-9]7)
basic_machine=hppa1.1-hp
;;
hp9k8[0-9][0-9] | hp8[0-9][0-9])
--- 307,326 ----
hp9k3[2-9][0-9])
basic_machine=m68k-hp
;;
! hp9k6[0-9][0-9] | hp6[0-9][0-9] )
! basic_machine=hppa1.0-hp
! ;;
! hp9k7[0-79][0-9] | hp7[0-79][0-9] )
! basic_machine=hppa1.1-hp
! ;;
! hp9k78[0-9] | hp78[0-9] )
! basic_machine=hppa2.0-hp
! ;;
! hp9k8[67]1 | hp8[67]1 | hp9k80[24] | hp80[24] | \
! hp9k8[78]9 | hp8[78]9 | hp9k893 | hp893 )
! basic_machine=hppa2.0-hp
! ;;
! hp9k8[0-9][13679] | hp8[0-9][13679] )
basic_machine=hppa1.1-hp
;;
hp9k8[0-9][0-9] | hp8[0-9][0-9])
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.guess/config.sub improvements
1998-01-29 0:41 ` Lassi A. Tuura
@ 1998-01-29 14:41 ` David Edelsohn
0 siblings, 0 replies; 9+ messages in thread
From: David Edelsohn @ 1998-01-29 14:41 UTC (permalink / raw)
To: Lassi A. Tuura; +Cc: law, egcs
>>>>> "Lassi A Tuura" writes:
Lassi> If I understand you correctly, `config.guess' should really return
Lassi> powerpc-lynx-lynxos* on PPC, instead of the current rs6000-*. Anybody
Lassi> object if I send a patch that does this? Would it break anything else?
Lassi> I suppose lynx.h could use some editing at least, but I don't really know
Lassi> what. It seems that it currently assumes rs6000 only.
The config name is not inherently magic for the port; the name
must map to appropriate machine description files via configure. If the
architecture name and port directory and configuration names are all the
same, this happens somewhat automatically. powerpc-* needs to look in
rs6000/ which is not automatic.
Currently the Lynx configuration for the rs6000 port only provides
default support for the POWER architecture because it only includes
rs6000/rs6000.h and not rs6000/powerpc.h when on a PowerPC host system.
If you only return powerpc-lynx-lynox*, it will not work and you will
break LynxOS support.
David
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.guess/config.sub improvements
1998-01-28 15:03 ` David Edelsohn
@ 1998-01-29 0:41 ` Lassi A. Tuura
1998-01-29 14:41 ` David Edelsohn
0 siblings, 1 reply; 9+ messages in thread
From: Lassi A. Tuura @ 1998-01-29 0:41 UTC (permalink / raw)
To: David Edelsohn; +Cc: law, egcs
On Wed, 28 Jan 1998, David Edelsohn wrote:
> This depends on what LynxOS does under the covers. For the
> various non-embedded Unix variants other than AIX (e.g., Linux, NetBSD),
> only PowerPC is supported. Lynx seems to be utilizing much of the AIX
> base and has supported the original POWER architecture. The PowerPC
> version of AIX emulates the trapped POWER instructions; I do not know what
> Lynx does. The architecture is fully configurable at compile time, so the
> builtin defaults are somewhat irrelevant. Using the proper architecture
> is important for performance.
If I understand you correctly, `config.guess' should really return
powerpc-lynx-lynxos* on PPC, instead of the current rs6000-*. Anybody
object if I send a patch that does this? Would it break anything else?
I suppose lynx.h could use some editing at least, but I don't really know
what. It seems that it currently assumes rs6000 only.
//lat
--
Lassi.Tuura@cern.ch There's no sunrise without a night
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.guess/config.sub improvements
1998-01-27 22:20 ` Jeffrey A Law
@ 1998-01-28 15:03 ` David Edelsohn
1998-01-29 0:41 ` Lassi A. Tuura
0 siblings, 1 reply; 9+ messages in thread
From: David Edelsohn @ 1998-01-28 15:03 UTC (permalink / raw)
To: law; +Cc: Lassi A. Tuura, egcs
>>>>> Jeffrey A Law writes:
>> * On LynxOS, both RS6000 and PowerPC variants are folded to rs6000-*.
>> I know the processors are supposedly similar, but are they really
>> that similar? For all that I know, people here are using PPC
>> boards running LynxOS, and so far I have used powerpc-* as the
>> configuration string. I can rename things to rs6000-* if that
>> is known to work. And yes, I have absolutely no clue about this
>> platform otherwise---I just need to support gcc on it.
Jeff> Yes, they are basically the same -- they share a common instrution set
Jeff> which the compiler uses by default. And each rs6000/ppc variant has a
Jeff> few instructions of its own, a different pipeline, etc.
This depends on what LynxOS does under the covers. For the
various non-embedded Unix variants other than AIX (e.g., Linux, NetBSD),
only PowerPC is supported. Lynx seems to be utilizing much of the AIX
base and has supported the original POWER architecture. The PowerPC
version of AIX emulates the trapped POWER instructions; I do not know what
Lynx does. The architecture is fully configurable at compile time, so the
builtin defaults are somewhat irrelevant. Using the proper architecture
is important for performance.
PowerPC made few user-visible changes to the basic POWER
archtecture structure: instructions with implicit output registers were
replaced (e.g., 64-bit multiply output used MQ register), instructions
requiring late decisions in the pipeline were removed (e.g., doz), and a
full-compliment of single-precision floating-point instructions were
added.
The PowerPC architecture defines two groups of optional
instructions. Any implementation can choose to include them, but they are
well-defined sets of instructions, not ad hoc instructions included per
chip.
David
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.guess/config.sub improvements
1998-01-27 16:18 ` Ian Lance Taylor
@ 1998-01-28 0:50 ` Lassi A. Tuura
0 siblings, 0 replies; 9+ messages in thread
From: Lassi A. Tuura @ 1998-01-28 0:50 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: egcs
On Tue, 27 Jan 1998, Ian Lance Taylor wrote:
> I agree that we should return the correct processor type, rather than
> always returning i386, if we can figure it out.
${UNAME_MACHINE} should do; I think cygwin32 reports the value it gets
from the operating system, which in general is correct (although I don't
know how it deals with cyrix or amd).
> However, cygwin32 is an operating system emulation layer. cygwin32
> should, in principle, work the same way on both 95 and NT. I believe
> that cygwin32 should certainly appear in the OS field, and should not
> appear in the manufacturer field.
>
> I think it would be reasonable to use the new fourth field for this
> purpose, if it is important. In that case, we would have something
> like `i686-pc-cygwin32-winnt4.0'.
>
> Alternatively, one could argue that the difference between 95 and NT
> is so fundamental, even when using cygwin32, that it should be part of
> the OS field, in which case we might want `i686-pc-cygwin32nt40' or
> `i686-pc-cygwin3295'.
Either of your proposals would be fine with me. Those more knowledgeable
than I about the subtleties of the differences should argue which one it
shall be :-)
Cheers,
//lat
--
Lassi.Tuura@cern.ch There's no sunrise without a night
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.guess/config.sub improvements
1998-01-27 13:20 ` Lassi A. Tuura
1998-01-27 16:18 ` Ian Lance Taylor
@ 1998-01-27 22:20 ` Jeffrey A Law
1998-01-28 15:03 ` David Edelsohn
1 sibling, 1 reply; 9+ messages in thread
From: Jeffrey A Law @ 1998-01-27 22:20 UTC (permalink / raw)
To: Lassi A. Tuura; +Cc: egcs
In message < Pine.HPP.3.95a.980127191758.25774G-100000@hpatl20.cern.ch >you write:
> OK, here is a new patch; the diffs are against the CVS repository.
>
> Note that this is only for the HP PA-RISC part; I have included a new
> ChangeLog entry to reflect this. Please let me know if there are any
> further problems with the patch.
Thanks. I've installed this patch.
> * On LynxOS, both RS6000 and PowerPC variants are folded to rs6000-*.
> I know the processors are supposedly similar, but are they really
> that similar? For all that I know, people here are using PPC
> boards running LynxOS, and so far I have used powerpc-* as the
> configuration string. I can rename things to rs6000-* if that
> is known to work. And yes, I have absolutely no clue about this
> platform otherwise---I just need to support gcc on it.
Yes, they are basically the same -- they share a common instrution set
which the compiler uses by default. And each rs6000/ppc variant has a
few instructions of its own, a different pipeline, etc.
jeff
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.guess/config.sub improvements
1998-01-27 13:20 ` Lassi A. Tuura
@ 1998-01-27 16:18 ` Ian Lance Taylor
1998-01-28 0:50 ` Lassi A. Tuura
1998-01-27 22:20 ` Jeffrey A Law
1 sibling, 1 reply; 9+ messages in thread
From: Ian Lance Taylor @ 1998-01-27 16:18 UTC (permalink / raw)
To: Lassi.Tuura; +Cc: egcs
Date: Tue, 27 Jan 1998 19:49:53 +0100 (MET)
From: "Lassi A. Tuura" <Lassi.Tuura@cern.ch>
* On cygwin32 (or mingw32) config.guess always returns
`i386-pc-cygwin32'. I see two problems with this: first, it does not
differentiate between different processor types, and second, it does
not differentiate between Windows 95 and Windows NT versions. Since
several other platforms do not force processor type to `i386', why
does that happen on Windows? We would certainly want to optimise the
code to take advantage of pentium instructions (or even ppro).
The second may not be important for GCC itself, but I can imagine it
makes difference for other packages (it certainly does for us). The
root of the problem is that the system API is different on NT and 95,
so applications configured and built for NT will not necessarily run on
95 and vice versa. It would be nice to be able to differentiate
these different binaries.
(My previous patch returned strings such as `i686-cygwin32-winnt4.0'.)
I agree that we should return the correct processor type, rather than
always returning i386, if we can figure it out.
However, cygwin32 is an operating system emulation layer. cygwin32
should, in principle, work the same way on both 95 and NT. I believe
that cygwin32 should certainly appear in the OS field, and should not
appear in the manufacturer field.
I think it would be reasonable to use the new fourth field for this
purpose, if it is important. In that case, we would have something
like `i686-pc-cygwin32-winnt4.0'.
Alternatively, one could argue that the difference between 95 and NT
is so fundamental, even when using cygwin32, that it should be part of
the OS field, in which case we might want `i686-pc-cygwin32nt40' or
`i686-pc-cygwin3295'.
Changing the manufacturer field, as in `i686-cygwin32-winnt4.0' would
not only be wrong, it would break many existing configure scripts.
Ian
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.guess/config.sub improvements
1998-01-23 11:15 ` Jeffrey A Law
@ 1998-01-27 13:20 ` Lassi A. Tuura
1998-01-27 16:18 ` Ian Lance Taylor
1998-01-27 22:20 ` Jeffrey A Law
0 siblings, 2 replies; 9+ messages in thread
From: Lassi A. Tuura @ 1998-01-27 13:20 UTC (permalink / raw)
To: law; +Cc: egcs
On Fri, 23 Jan 1998, Jeffrey A Law wrote:
> > Thu Nov 6 18:48:03 1997 Lassi Tuura <lat@hpatl20.cern.ch>
> >
> > * config.guess: more accurate determination of HP PA-RISC
> > processor types for 9000/[678]?? series machines, add support for
> > PowerPC on LynxOS and for Windows NT on CYGWIN32.
> >
> > * config.sub: ditto.
> I was going to try and add your patch to egcs, but things have changed so
> much recently that none of the hunks correctly applies.
>
> Can you please update and resubmit your patch.
>
> As we discussed earlier, we should return hppa1.1 instead of hppa2.0 for now;
> you should add a comment about this in config.guess.
OK, here is a new patch; the diffs are against the CVS repository.
Note that this is only for the HP PA-RISC part; I have included a new
ChangeLog entry to reflect this. Please let me know if there are any
further problems with the patch.
Now, some other questions regarding the guessed values that my previous
patch solved differently.
* On cygwin32 (or mingw32) config.guess always returns
`i386-pc-cygwin32'. I see two problems with this: first, it does not
differentiate between different processor types, and second, it does
not differentiate between Windows 95 and Windows NT versions. Since
several other platforms do not force processor type to `i386', why
does that happen on Windows? We would certainly want to optimise the
code to take advantage of pentium instructions (or even ppro).
The second may not be important for GCC itself, but I can imagine it
makes difference for other packages (it certainly does for us). The
root of the problem is that the system API is different on NT and 95,
so applications configured and built for NT will not necessarily run on
95 and vice versa. It would be nice to be able to differentiate
these different binaries.
(My previous patch returned strings such as `i686-cygwin32-winnt4.0'.)
* On LynxOS, both RS6000 and PowerPC variants are folded to rs6000-*.
I know the processors are supposedly similar, but are they really
that similar? For all that I know, people here are using PPC
boards running LynxOS, and so far I have used powerpc-* as the
configuration string. I can rename things to rs6000-* if that
is known to work. And yes, I have absolutely no clue about this
platform otherwise---I just need to support gcc on it.
Cheers,
//lat
--
Lassi.Tuura@cern.ch There's no sunrise without a night
-------------------------------------------------------------------
Tue Jan 27 19:21:41 1998 Lassi A. Tuura <lat@iki.fi>
* config.guess: more accurate determination of HP PA-RISC
processor types for 9000/[678]?? series machines.
* config.sub: ditto.
Index: config.guess
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/config.guess,v
retrieving revision 1.8
diff -u -p -r1.8 config.guess
--- config.guess 1998/01/22 23:28:32 1.8
+++ config.guess 1998/01/27 18:26:27
@@ -358,8 +358,13 @@ EOF
case "${UNAME_MACHINE}" in
9000/31? ) HP_ARCH=m68000 ;;
9000/[34]?? ) HP_ARCH=m68k ;;
- 9000/7?? | 9000/8?[13679] ) HP_ARCH=hppa1.1 ;;
- 9000/8?? ) HP_ARCH=hppa1.0 ;;
+ 9000/6?? ) HP_ARCH=hppa1.0 ;;
+ 9000/78? ) HP_ARCH=hppa1.1 ;; # FIXME: really hppa2.0
+ 9000/7?? ) HP_ARCH=hppa1.1 ;;
+ 9000/8[67]1 | 9000/80[24] | 9000/8[78]9 | 9000/893 )
+ HP_ARCH=hppa1.1 ;; # FIXME: really hppa2.0
+ 9000/8?[13679] ) HP_ARCH=hppa1.1 ;;
+ 9000/8?? ) HP_ARCH=hppa1.0 ;;
esac
HPUX_REV=`echo ${UNAME_RELEASE}|sed -e 's/[^.]*.[0B]*//'`
echo ${HP_ARCH}-hp-hpux${HPUX_REV}
Index: config.sub
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/config.sub,v
retrieving revision 1.5
diff -u -p -r1.5 config.sub
--- config.sub 1998/01/04 00:10:30 1.5
+++ config.sub 1998/01/27 18:26:27
@@ -416,7 +416,22 @@ case $basic_machine in
hp9k3[2-9][0-9])
basic_machine=m68k-hp
;;
- hp9k7[0-9][0-9] | hp7[0-9][0-9] | hp9k8[0-9]7 | hp8[0-9]7)
+ hp9k6[0-9][0-9] | hp6[0-9][0-9] )
+ basic_machine=hppa1.0-hp
+ ;;
+ hp9k7[0-79][0-9] | hp7[0-79][0-9] )
+ basic_machine=hppa1.1-hp
+ ;;
+ hp9k78[0-9] | hp78[0-9] )
+ # FIXME: really hppa2.0-hp
+ basic_machine=hppa1.1-hp
+ ;;
+ hp9k8[67]1 | hp8[67]1 | hp9k80[24] | hp80[24] | \
+ hp9k8[78]9 | hp8[78]9 | hp9k893 | hp893 )
+ # FIXME: really hppa2.0-hp
+ basic_machine=hppa1.1-hp
+ ;;
+ hp9k8[0-9][13679] | hp8[0-9][13679] )
basic_machine=hppa1.1-hp
;;
hp9k8[0-9][0-9] | hp8[0-9][0-9])
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: config.guess/config.sub improvements
[not found] <346207C2.74FF2820@cern.ch>
@ 1998-01-23 11:15 ` Jeffrey A Law
1998-01-27 13:20 ` Lassi A. Tuura
0 siblings, 1 reply; 9+ messages in thread
From: Jeffrey A Law @ 1998-01-23 11:15 UTC (permalink / raw)
To: Lassi A. Tuura; +Cc: egcs
In message <346207C2.74FF2820@cern.ch>you write:
> Here is a patch for config.guess (from gcc-2.7.2.3) to correctly
> determine processor types on HP's PA-RISC, plus small additions for
> PowerPC LynxOS and cygwin32. For the cygwin32 entry I am not sure what
> is the desired format; please check it.
>
> The PA-RISC table for 800-series is rather complicated and I am not sure
> if I got it right; it is correct for the entries I had in my
> /opt/langtools/lib/sched.models. In particular, there are lots of
> models missing from that file (probably still unassigned), so the
> heuristics below might be incorrect for future models. If my
> sched.models does not include all past models, then it might be
> incorrect for older computers, too.
>
> Cheers,
> //lat
> --
> Lassi.Tuura@cern.ch There's no sunrise without a night
>
> ----------------------------------------------------------------
> Thu Nov 6 18:48:03 1997 Lassi Tuura <lat@hpatl20.cern.ch>
>
> * config.guess: more accurate determination of HP PA-RISC
> processor types for 9000/[678]?? series machines, add support for
> PowerPC on LynxOS and for Windows NT on CYGWIN32.
>
> * config.sub: ditto.
I was going to try and add your patch to egcs, but things have changed so
much recently that none of the hunks correctly applies.
Can you please update and resubmit your patch.
As we discussed earlier, we should return hppa1.1 instead of hppa2.0 for now;
you should add a comment about this in config.guess.
jeff
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1998-01-29 14:41 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-11-13 5:17 config.guess/config.sub improvements Lassi A. Tuura
[not found] <346207C2.74FF2820@cern.ch>
1998-01-23 11:15 ` Jeffrey A Law
1998-01-27 13:20 ` Lassi A. Tuura
1998-01-27 16:18 ` Ian Lance Taylor
1998-01-28 0:50 ` Lassi A. Tuura
1998-01-27 22:20 ` Jeffrey A Law
1998-01-28 15:03 ` David Edelsohn
1998-01-29 0:41 ` Lassi A. Tuura
1998-01-29 14:41 ` David Edelsohn
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).