Mechanism to configure default scheduling model on PA

Mechanism to configure default scheduling model on PA

[John David Anglin]

The default scheduling model was changed recently from that for the 7100
processor to that for the 8000 processors.  This change was not particularly
suitable for older hardware.

This patch introduces a mechanism to configure the default scheduling
model.  The 700 model is used for pa1.0 targets, the 7100 model is
used for pa1.1 targets, and the 8000 model is used for all other
targets (ie., it's still the default).  The sophisticated user
can define TARGET_SCHED_DEFAULT in BOOT_CFLAGS if some other default
is desired.

The patch has been tested on hppa1.1-hp-hpux10.20, hppa2.0w-hp-hpux11.11
and hppa-linux.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2002-05-17  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* config.gcc (tm_file): Prefix pa/pa-700.h to tm_file list for PA1.0
	architecture and pa/pa-7100.h for PA1.1 architecture, respectively.
	* pa/pa.c (override_options): Use TARGET_SCHED_DEFAULT to select
	default scheduling model.
	* pa/pa.h (TARGET_SCHED_DEFAULT): Define if not defined to "8000".
	* pa/pa-700.h (TARGET_SCHED_DEFAULT): New file for "700" scheduling.
	* pa/pa-7100.h (TARGET_SCHED_DEFAULT): New file for "7100" scheduling.
	* doc/install.texi (hppa*-*-*): Document default scheduling.

Index: config.gcc
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config.gcc,v
retrieving revision 1.193
diff -u -3 -p -r1.193 config.gcc
--- config.gcc	11 May 2002 16:25:03 -0000	1.193
+++ config.gcc	15 May 2002 15:19:33 -0000
@@ -3597,6 +3597,14 @@ hppa*-*-* | parisc*-*-*)
 	then
 		target_cpu_default2="MASK_GAS|MASK_JUMP_IN_DELAY"
 	fi
+	case $machine in
+		hppa1.0* | parisc1.0*)
+			tm_file="pa/pa-700.h ${tm_file}"
+			;;
+		hppa1.1* | parisc1.1*)
+			tm_file="pa/pa-7100.h ${tm_file}"
+			;;
+	esac
 	;;
 
 mips*-*-ecoff* | mips*-*-elf*)
Index: config/pa/pa.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/pa/pa.c,v
retrieving revision 1.158
diff -u -3 -p -r1.158 pa.c
--- config/pa/pa.c	15 May 2002 03:02:23 -0000	1.158
+++ config/pa/pa.c	15 May 2002 15:19:34 -0000
@@ -188,38 +188,39 @@ struct gcc_target targetm = TARGET_INITI
 void
 override_options ()
 {
-  /* Default to 8000 scheduling.  */
-  if (pa_cpu_string && ! strcmp (pa_cpu_string, "7100"))
+  if (pa_cpu_string == NULL)
+    pa_cpu_string = TARGET_SCHED_DEFAULT;
+
+  if (! strcmp (pa_cpu_string, "8000"))
+    {
+      pa_cpu_string = "8000";
+      pa_cpu = PROCESSOR_8000;
+    }
+  else if (! strcmp (pa_cpu_string, "7100"))
     {
       pa_cpu_string = "7100";
       pa_cpu = PROCESSOR_7100;
     }
-  else if (pa_cpu_string && ! strcmp (pa_cpu_string, "700"))
+  else if (! strcmp (pa_cpu_string, "700"))
     {
       pa_cpu_string = "700";
       pa_cpu = PROCESSOR_700;
     }
-  else if (pa_cpu_string && ! strcmp (pa_cpu_string, "7100LC"))
+  else if (! strcmp (pa_cpu_string, "7100LC"))
     {
       pa_cpu_string = "7100LC";
       pa_cpu = PROCESSOR_7100LC;
     }
-  else if (pa_cpu_string && ! strcmp (pa_cpu_string, "7200"))
+  else if (! strcmp (pa_cpu_string, "7200"))
     {
       pa_cpu_string = "7200";
       pa_cpu = PROCESSOR_7200;
     }
-  else if (pa_cpu_string && ! strcmp (pa_cpu_string, "7300"))
+  else if (! strcmp (pa_cpu_string, "7300"))
     {
       pa_cpu_string = "7300";
       pa_cpu = PROCESSOR_7300;
     }
-  else if (pa_cpu_string == NULL
-	   || ! strcmp (pa_cpu_string, "8000"))
-    {
-      pa_cpu_string = "8000";
-      pa_cpu = PROCESSOR_8000;
-    }
   else
     {
       warning ("unknown -mschedule= option (%s).\nValid options are 700, 7100, 7100LC, 7200, 7300, and 8000\n", pa_cpu_string);
Index: config/pa/pa.h
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/pa/pa.h,v
retrieving revision 1.152
diff -u -3 -p -r1.152 pa.h
--- config/pa/pa.h	8 May 2002 23:10:59 -0000	1.152
+++ config/pa/pa.h	15 May 2002 15:19:35 -0000
@@ -208,6 +208,10 @@ extern int target_flags;
 #define TARGET_CPU_DEFAULT 0
 #endif
 
+#ifndef TARGET_SCHED_DEFAULT
+#define TARGET_SCHED_DEFAULT "8000"
+#endif
+
 #define TARGET_OPTIONS			\
 {					\
   { "schedule=",	&pa_cpu_string, "Specify CPU for scheduling purposes" },\
--- /dev/null	Sun Jan  6 15:06:58 2002
+++ config/pa/pa-700.h	Wed May 15 07:28:17 2002
@@ -0,0 +1,24 @@
+/* Definitions of target machine for GNU compiler, for HPs using the
+   PA700 scheduling model.
+   Copyright (C) 2002 Free Software Foundation, Inc.
+
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+#ifndef TARGET_SCHED_DEFAULT
+#define TARGET_SCHED_DEFAULT "700"
+#endif
--- /dev/null	Sun Jan  6 15:06:58 2002
+++ config/pa/pa-7100.h	Wed May 15 07:29:44 2002
@@ -0,0 +1,24 @@
+/* Definitions of target machine for GNU compiler, for HPs using the
+   PA7100 scheduling model.
+   Copyright (C) 2002 Free Software Foundation, Inc.
+
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+#ifndef TARGET_SCHED_DEFAULT
+#define TARGET_SCHED_DEFAULT "7100"
+#endif
Index: doc/install.texi
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.116
diff -u -3 -p -r1.116 install.texi
--- doc/install.texi	14 May 2002 10:38:46 -0000	1.116
+++ doc/install.texi	15 May 2002 17:15:33 -0000
@@ -2131,6 +2131,19 @@ If you wish to use pa-risc 2.0 architect
 the HP assembler, gas/binutils 2.11 or a recent
 @uref{ftp://sources.redhat.com/pub/binutils/snapshots,,snapshot of gas}.
 
+There are three default scheduling models for instructions.  They
+are PROCESSOR_700, PROCESSOR_7100 and PROCESSOR_8000.  They are selected
+based on the the pa-risc architecture specified for the target machine
+when configuring.  PROCESSOR_8000 is the default model.  PROCESSOR_700
+and PROCESSOR_7100 are selected by specifying either @samp{hppa1.0} or
+@samp{hppa1.1}, respectively.
+
+The PROCESSOR_8000 model is not well suited to older processors.  Thus,
+it is important to completely specify the machine architecture when
+configuring if you want a model other than PROCESSOR_8000.  The macro
+TARGET_SCHED_DEFAULT can be defined in BOOT_CFLAGS if a different
+default scheduling model is desired.
+
 More specific information to @samp{hppa*-hp-hpux*} targets follows.
 
 @html

Re: Mechanism to configure default scheduling model on PA

[law]

In message <200205310413.g4V4DEGh004261@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > The default scheduling model was changed recently from that for the 7100
 > processor to that for the 8000 processors.  This change was not particularly
 > suitable for older hardware.
 > 
 > This patch introduces a mechanism to configure the default scheduling
 > model.  The 700 model is used for pa1.0 targets, the 7100 model is
 > used for pa1.1 targets, and the 8000 model is used for all other
 > targets (ie., it's still the default).  The sophisticated user
 > can define TARGET_SCHED_DEFAULT in BOOT_CFLAGS if some other default
 > is desired.
 > 
 > The patch has been tested on hppa1.1-hp-hpux10.20, hppa2.0w-hp-hpux11.11
 > and hppa-linux.
Thanks.  I've always thought about doing this, but figured it wasn't
worth the time.

If you wanted to get more correct, then you'd look at the actual
model # and map that into 700, 7100, 7100lc, 7200, 7300 or 8000.

FWIW, PA700 is actually the first generation PA1.1 machines -- we never
bothered writing descriptions for the original PA1.0 machines.  It's also
the case that the previous default was 7100LC, not 7100.

So what I might recommend would be to use PA8000 for PA2.0 and newer and
PA7100LC for the others.

PA7100LC scheduling works very well on the PA7100LC, PA7200 and PA7300 class
machines (they only differ in their handling of store-load and store-store
penalties).  PA7100LC also works reasonably well for PA7100 and PA700 machines.

jeff

Re: Mechanism to configure default scheduling model on PA

[John David Anglin]

> If you wanted to get more correct, then you'd look at the actual
> model # and map that into 700, 7100, 7100lc, 7200, 7300 or 8000.

I just went with a default based on the specified target architecture
because it's only possible to look at the model number in a native
build.  I didn't think it was worthwhile trying to get more precise
because of this and because it's possible to override the default
in BOOT_CFLAGS.

> 
> FWIW, PA700 is actually the first generation PA1.1 machines -- we never
> bothered writing descriptions for the original PA1.0 machines.  It's also
> the case that the previous default was 7100LC, not 7100.

Thanks for the clarification.

> So what I might recommend would be to use PA8000 for PA2.0 and newer and
> PA7100LC for the others.

It's easier to use PA7100LC for hppa1.0 and hppa1.1 targets, and PA8000 
for the rest.  A target with an unspecified architecture would use
PA8000.  The idea was to force people to specify their target
completely if they want something other than the default, and default
to the newer architecture.  Of course, config.guess generates a complete
specification if no target option is provided.

Does this approach sound ok?  In a similar vein, Stefan Becker was
interested in being able to change the default architecture without
hacking config.gcc.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Mechanism to configure default scheduling model on PA

[Zack Weinberg]

On Fri, May 31, 2002 at 12:13:13AM -0400, John David Anglin wrote:
> The default scheduling model was changed recently from that for the 7100
> processor to that for the 8000 processors.  This change was not particularly
> suitable for older hardware.
> 
> This patch introduces a mechanism to configure the default scheduling
> model.  The 700 model is used for pa1.0 targets, the 7100 model is
> used for pa1.1 targets, and the 8000 model is used for all other
> targets (ie., it's still the default).  The sophisticated user
> can define TARGET_SCHED_DEFAULT in BOOT_CFLAGS if some other default
> is desired.

May I suggest that you create and use a 'tm_defines' variable along
the lines of the existing xm_defines, rather than having lots of tiny
pa-<n>.h headers?

zw

Re: Mechanism to configure default scheduling model on PA

[law]

 In message <200205311754.g4VHs8gF006581@hiauly1.hia.nrc.ca>, "John David 
Anglin" writes:
 > It's easier to use PA7100LC for hppa1.0 and hppa1.1 targets, and PA8000 
 > for the rest.  A target with an unspecified architecture would use
 > PA8000.  The idea was to force people to specify their target
 > completely if they want something other than the default, and default
 > to the newer architecture.  Of course, config.guess generates a complete
 > specification if no target option is provided.
 > 
 > Does this approach sound ok?
Seems reasonable.

 > In a similar vein, Stefan Becker was
 > interested in being able to change the default architecture without
 > hacking config.gcc.
I've been pondering this kind of thing recently as well.  Specifically, I've
been thinking about requesting comments on changing GCC's behavior when
configured/built on a PA2.0 machine.

Right now if config.guess returns hppa1.0*, then you get PA1.0.  If it
returns hppa1.1* or hppa2.0*, then you get PA1.1.  What I've been pondering
is changing the behavior of hppa2.0* so that you'd get PA2.0 code generation.
(note you'd still have to configure hppa64 to get PA64).

Thoughts?

jeff



  

Re: Mechanism to configure default scheduling model on PA

[John David Anglin]

>  > In a similar vein, Stefan Becker was
>  > interested in being able to change the default architecture without
>  > hacking config.gcc.
> I've been pondering this kind of thing recently as well.  Specifically, I've
> been thinking about requesting comments on changing GCC's behavior when
> configured/built on a PA2.0 machine.
> 
> Right now if config.guess returns hppa1.0*, then you get PA1.0.  If it
> returns hppa1.1* or hppa2.0*, then you get PA1.1.  What I've been pondering
> is changing the behavior of hppa2.0* so that you'd get PA2.0 code generation.
> (note you'd still have to configure hppa64 to get PA64).

Yes, it seems reasonable to default to the most advanced architecture
that the target supports.  That should give the best overall performance.
It will also provide a better range of testing for each architecture.
I still like the idea of being able to configure the default in case a
more portable default is desired.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Mechanism to configure default scheduling model on PA

[law]

 In message <200205311843.g4VIhRDk006815@hiauly1.hia.nrc.ca>, "John David 
Anglin" writes:
 > Yes, it seems reasonable to default to the most advanced architecture
 > that the target supports.  That should give the best overall performance.
 > It will also provide a better range of testing for each architecture.
My suggestion was to default to whatever machine you're building the compiler
on.  Not the most modern architecture.

 > I still like the idea of being able to configure the default in case a
 > more portable default is desired.
If we have the model where we default to the architecture you're building
on, then you can change it by explicitly specifying what target you want to
build.

ie, let's pretend we're on an hppa2.0w-hp-hpux11 system and we just
"configure; make bootstrap; make install".  That would default to PA2.0.
However, you could get the default to be PA1.0 by doing the following:
"configure hppa1.0-hp-hpux11; make bootstrap; make install".

Similarly if I was on an "hppa1.1-hp-hpux11", then I'm going to get PA1.1
by default.  However, I could explicitly ask for something different like
"configure hppa2.0w-hp-hpux11".  Of course you couldn't bootstrap as the
compiler would generate PA2.0 instructions which wouldn't work on your
PA1.1 machine :-)


jeff

Re: Mechanism to configure default scheduling model on PA

[John David Anglin]

>  In message <200205311843.g4VIhRDk006815@hiauly1.hia.nrc.ca>, "John David 
> Anglin" writes:
>  > Yes, it seems reasonable to default to the most advanced architecture
>  > that the target supports.  That should give the best overall performance.
>  > It will also provide a better range of testing for each architecture.
> My suggestion was to default to whatever machine you're building the compiler
> on.  Not the most modern architecture.

The compiler itself needs to be built with an architecture that's consistent
with the host machine, not the build machine.  I would argue that the
default output of the compiler should be determined by the architecture
of the target machine.

In cases where build, host and target differ, then we have a cross
compiler scenario and the generated code may not run on the host or
build machine.

As you note, we don't need any new configuration option for architecture
selection.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Mechanism to configure default scheduling model on PA

[law]

 In message <200205311944.g4VJisQr006933@hiauly1.hia.nrc.ca>, "John David 
Anglin
" writes:
 > The compiler itself needs to be built with an architecture that's consistent
 > with the host machine, not the build machine.  I would argue that the
 > default output of the compiler should be determined by the architecture
 > of the target machine.
For 99.9% of PA builds host == target == build, that is the case I'm 
most interested in.

 > In cases where build, host and target differ, then we have a cross
 > compiler scenario and the generated code may not run on the host or
 > build machine.
Yup, but in that case you have to explicitly mention the target anyway and
thus you'd get code for whatever target you explicitly asked for.

jeff

Patch: Use tm_defines to configure default scheduling model on PA

[John David Anglin]

> > This patch introduces a mechanism to configure the default scheduling
> > model.  The 700 model is used for pa1.0 targets, the 7100 model is
> > used for pa1.1 targets, and the 8000 model is used for all other
> > targets (ie., it's still the default).  The sophisticated user
> > can define TARGET_SCHED_DEFAULT in BOOT_CFLAGS if some other default
> > is desired.
> 
> May I suggest that you create and use a 'tm_defines' variable along
> the lines of the existing xm_defines, rather than having lots of tiny
> pa-<n>.h headers?

As per Zack's suggestion, I have created a 'tm_defines' along with the
necessary infrastructure to output target defines in the 'config.h'
files.  This avoids having the pa-700.h and pa-7100.h headers.  Hopefully,
this will be useful on other ports as well.  Tested with a build with
no regressions on hppa1.1-hp-hpux11.11.

OK for the mainline?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2002-06-05  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* Makefile.in (tm_defines): New configuration variable.
	(cs-config.h, cs-hconfig.h, cs-tconfig.h): Rename DEFINES to XM_DEFINES.
	Pass tm_defines in TM_DEFINES.
	(cs-tm_p.h): Rename DEFINES to XM_DEFINES.  Pass TM_DEFINES.
	* config.gcc (tm_defines): New configuration variable.
	(hppa*-*-* | parisc*-*-*): Use tm_defines instead of pa-700.h and
	pa-7100.h headers.  Change hppa1* scheduling default to 7100LC.
	* configure.in: Substitute tm_defines.
	* configure: Rebuilt.
	* mkconfig.sh: Rename DEFINES to XM_DEFINES.  Output TM_DEFINES.
	* pa/pa-700.h: Delete file.
	* pa/pa-7100.h: Delete file.

Index: Makefile.in
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.888
diff -u -3 -p -r1.888 Makefile.in
--- Makefile.in	4 Jun 2002 07:06:51 -0000	1.888
+++ Makefile.in	5 Jun 2002 15:59:56 -0000
@@ -259,6 +259,7 @@ tmake_file=@dep_tmake_file@
 out_file=$(srcdir)/config/@out_file@
 out_object_file=@out_object_file@
 md_file=$(srcdir)/config/@md_file@
+tm_defines=@tm_defines@
 tm_p_file_list=@tm_p_file_list@
 tm_p_file=@tm_p_file@
 build_xm_file_list=@build_xm_file_list@
@@ -845,22 +846,26 @@ tconfig.h: cs-tconfig.h ; @true
 tm_p.h: cs-tm_p.h ; @true
 
 cs-config.h: Makefile
-	HEADERS="$(host_xm_file)" DEFINES="$(host_xm_defines)" \
+	TM_DEFINES="$(tm_defines)" \
+	HEADERS="$(host_xm_file)" XM_DEFINES="$(host_xm_defines)" \
 	TARGET_CPU_DEFAULT="$(target_cpu_default)" \
 	$(SHELL) $(srcdir)/mkconfig.sh config.h
 
 cs-hconfig.h: Makefile
-	HEADERS="$(build_xm_file)" DEFINES="$(build_xm_defines)" \
+	TM_DEFINES="$(tm_defines)" \
+	HEADERS="$(build_xm_file)" XM_DEFINES="$(build_xm_defines)" \
 	TARGET_CPU_DEFAULT="$(target_cpu_default)" \
 	$(SHELL) $(srcdir)/mkconfig.sh hconfig.h
 
 cs-tconfig.h: Makefile
-	HEADERS="$(xm_file)" DEFINES="$(xm_defines)" \
+	TM_DEFINES="$(tm_defines)" \
+	HEADERS="$(xm_file)" XM_DEFINES="$(xm_defines)" \
 	TARGET_CPU_DEFAULT="" \
 	$(SHELL) $(srcdir)/mkconfig.sh tconfig.h
 
 cs-tm_p.h: Makefile
-	HEADERS="$(tm_p_file)" DEFINES="" TARGET_CPU_DEFAULT="" \
+	TM_DEFINES="" \
+	HEADERS="$(tm_p_file)" XM_DEFINES="" TARGET_CPU_DEFAULT="" \
 	$(SHELL) $(srcdir)/mkconfig.sh tm_p.h
 
 # Don't automatically run autoconf, since configure.in might be accidentally
Index: config.gcc
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config.gcc,v
retrieving revision 1.204
diff -u -3 -p -r1.204 config.gcc
--- config.gcc	4 Jun 2002 22:20:37 -0000	1.204
+++ config.gcc	5 Jun 2002 15:59:57 -0000
@@ -45,6 +45,8 @@
 #
 #  cpu_type		The name of the cpu, if different from machine.
 #
+#  tm_defines		List of target macros to define for all compilations.
+#
 #  tm_file		A list of target macro files, if different from
 #			"$cpu_type/$cpu_type.h". Usually it's constructed
 #			per target in a way like this:
@@ -184,6 +186,7 @@ extra_host_objs=
 extra_gcc_objs=
 c_target_objs=
 cxx_target_objs=
+tm_defines=
 xm_defines=
 float_format=
 # Set this to force installation and use of collect2.
@@ -2824,11 +2827,8 @@ hppa*-*-* | parisc*-*-*)
 		target_cpu_default2="MASK_GAS|MASK_JUMP_IN_DELAY"
 	fi
 	case $machine in
-		hppa1.0* | parisc1.0*)
-			tm_file="pa/pa-700.h ${tm_file}"
-			;;
-		hppa1.1* | parisc1.1*)
-			tm_file="pa/pa-7100.h ${tm_file}"
+		hppa1* | parisc1*)
+			tm_defines="TARGET_SCHED_DEFAULT=\\\"7100LC\\\""
 			;;
 	esac
 	;;
Index: configure.in
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/configure.in,v
retrieving revision 1.599
diff -u -3 -p -r1.599 configure.in
--- configure.in	4 Jun 2002 22:20:41 -0000	1.599
+++ configure.in	5 Jun 2002 15:59:58 -0000
@@ -2552,6 +2552,7 @@ AC_SUBST(symbolic_link)
 AC_SUBST(thread_file)
 AC_SUBST(tm_file_list)
 AC_SUBST(tm_file)
+AC_SUBST(tm_defines)
 AC_SUBST(tm_p_file_list)
 AC_SUBST(tm_p_file)
 AC_SUBST(xm_file)
Index: mkconfig.sh
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/mkconfig.sh,v
retrieving revision 1.10
diff -u -3 -p -r1.10 mkconfig.sh
--- mkconfig.sh	4 Jun 2002 07:07:51 -0000	1.10
+++ mkconfig.sh	5 Jun 2002 15:59:58 -0000
@@ -2,11 +2,11 @@
 
 # Generate gcc's config.h, which is not your normal autoconf-generated
 # config.h (that's auto-(host|build).h).  $1 is the file to generate.
-# HEADERS, DEFINES, and possibly TARGET_CPU_DEFAULT are expected to be
-# set in the environment.
+# TM_DEFINES, HEADERS, XM_DEFINES, and possibly TARGET_CPU_DEFAULT are
+# expected to be set in the environment.
 
 if [ -z "$1" ]; then
-    echo "Usage: HEADERS='list' DEFINES='list' mkconfig.sh FILE" >&2
+    echo "Usage: TM_DEFINES='list' HEADERS='list' XM_DEFINES='list' mkconfig.sh FILE" >&2
     exit 1
 fi
 
@@ -19,6 +19,13 @@ if [ "$TARGET_CPU_DEFAULT" != "" ]; then
     echo "#define TARGET_CPU_DEFAULT ($TARGET_CPU_DEFAULT)" >> ${output}T
 fi
 
+# Provide defines for other target machine macros to be used everywhere.
+for def in $TM_DEFINES; do
+    echo "#ifndef $def" | sed 's/=.*//' >> ${output}T
+    echo "# define $def" | sed 's/=/ /' >> ${output}T
+    echo "#endif" >> ${output}T
+done
+
 # The first entry in HEADERS may be auto-host.h or auto-build.h;
 # it wants to be included even when not -DIN_GCC.
 if [ -n "$HEADERS" ]; then
@@ -63,7 +70,7 @@ if [ -n "$HEADERS" ]; then
     echo '#endif' >> ${output}T
 fi
 
-for def in $DEFINES; do
+for def in $XM_DEFINES; do
     echo "#ifndef $def" | sed 's/=.*//' >> ${output}T
     echo "# define $def" | sed 's/=/ /' >> ${output}T
     echo "#endif" >> ${output}T

Re: Patch: Use tm_defines to configure default scheduling model on PA

[Neil Booth]

John David Anglin wrote:-

> As per Zack's suggestion, I have created a 'tm_defines' along with the
> necessary infrastructure to output target defines in the 'config.h'
> files.  This avoids having the pa-700.h and pa-7100.h headers.  Hopefully,
> this will be useful on other ports as well.  Tested with a build with
> no regressions on hppa1.1-hp-hpux11.11.

I don't think it's the same as what you've done, but I'd really like
to see some way of defining a gcc-build-time macro in config.gcc for 
an arbitrary port.  So many of the port-specific files exist solely
to redefine FOO that it would be nicer to get rid of the extra files
(and therefore complexity) and instead have, say,

<in file common.h>
#ifdef SOME_CONFIG_GCC_MACRO_FOR_TARGET_A
# define FOO TARGET_A_FOO
#else
# define FOO OTHER_TARGETS_FOO
#endif

Neil.

Re: Patch: Use tm_defines to configure default scheduling model on PA

[John David Anglin]

> I don't think it's the same as what you've done, but I'd really like
> to see some way of defining a gcc-build-time macro in config.gcc for 
> an arbitrary port.  So many of the port-specific files exist solely
> to redefine FOO that it would be nicer to get rid of the extra files
> (and therefore complexity) and instead have, say,
> 
> <in file common.h>
> #ifdef SOME_CONFIG_GCC_MACRO_FOR_TARGET_A
> # define FOO TARGET_A_FOO
> #else
> # define FOO OTHER_TARGETS_FOO
> #endif

I think effectively what I have done allows the above.  For example,
in the particular case I am trying to deal with, you get the following
additional code in config.h, hconfig.h and tconfig.h

#ifndef TARGET_SCHED_DEFAULT
# define TARGET_SCHED_DEFAULT "7100LC"
#endif

This selects a particular default in pa.c.

These defines are right at the beginning of the config files, before
the inclusion of any of the target machine headers.  The problem with
the xm_defines is that they come after the target mchine headers.  Thus,
the configure process can be used to define or not define
SOME_CONFIG_GCC_MACRO_FOR_TARGET_A, and thereby control defines in
other headers and code.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Patch: Use tm_defines to configure default scheduling model on PA

[Neil Booth]

John David Anglin wrote:-

> I think effectively what I have done allows the above.  For example,
> in the particular case I am trying to deal with, you get the following
> additional code in config.h, hconfig.h and tconfig.h
> 
> #ifndef TARGET_SCHED_DEFAULT
> # define TARGET_SCHED_DEFAULT "7100LC"
> #endif
> 
> This selects a particular default in pa.c.
> 
> These defines are right at the beginning of the config files, before
> the inclusion of any of the target machine headers.  The problem with
> the xm_defines is that they come after the target mchine headers.  Thus,
> the configure process can be used to define or not define
> SOME_CONFIG_GCC_MACRO_FOR_TARGET_A, and thereby control defines in
> other headers and code.

Ah, yes.  But your macros are defined inside some new header, rather
than in config.gcc itself, right?  I'm just trying to reduce the number
of headers.  You look at i386/, and there are so many headers, some
included from config.gcc and some included from the header files
themselves (aarggh!) it takes a lot of time and error-prone research
to figure out what can be included by what, never mind *why* it's
being included.

Neil.

Re: Patch: Use tm_defines to configure default scheduling model on PA

[John David Anglin]

> Ah, yes.  But your macros are defined inside some new header, rather
> than in config.gcc itself, right?  I'm just trying to reduce the number

No.  The macros themselves are defined in config.gcc and they get
inserted into config.h, hconfig.h and tconfig.h by mkconfig.sh.  The
script converts say

  tm_defines="ABC=foo"

config.gcc into

  #ifdef ABC
  #define ABC foo
  #endif

in the *config.h files.  The config files are not new and they include
the target headers when IN_GCC is defined..

> of headers.  You look at i386/, and there are so many headers, some
> included from config.gcc and some included from the header files
> themselves (aarggh!) it takes a lot of time and error-prone research
> to figure out what can be included by what, never mind *why* it's
> being included.

You should be able to control the inclusion of headers in say
i386.h, or eliminate small headers with the new construct.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Patch: Use tm_defines to configure default scheduling model on PA

[Neil Booth]

John David Anglin wrote:-

> > Ah, yes.  But your macros are defined inside some new header, rather
> > than in config.gcc itself, right?  I'm just trying to reduce the number
> 
> No.  The macros themselves are defined in config.gcc and they get
> inserted into config.h, hconfig.h and tconfig.h by mkconfig.sh.  The
> script converts say
> 
>   tm_defines="ABC=foo"
> 
> config.gcc into
> 
>   #ifdef ABC
>   #define ABC foo
>   #endif
> 
> in the *config.h files.  The config files are not new and they include
> the target headers when IN_GCC is defined..

OK, great!  Sorry for the misunderstanding.  This should enable some
cleanup.

Neil.

Re: Patch: Use tm_defines to configure default scheduling model on PA

[John David Anglin]

> Sorry I missed it, but the subject line was a bit misleading.  The
> patch is fine.  However, the PPC already has a way of selecting the
> default CPU (and thus scheduling etc) with a configure option and
> config.gcc.  Did you look at that mechanism before implementing this
> one?

The mechanism involves setting flag bits in TARGET_CPU_DEFAULT.  This could
be done but then there would be no way for a user to fine tune the default
scheduling model selected by configure except by hacking config.gcc. One
of the goals of the patch was to enable the user to set TARGET_SCHED_DEFAULT
in BOOT_CFLAGS.

TARGET_CPU_DEFAULT involves a collection of miscellaneous flag bits that
get merged in a rather complex manner in the configuration process to produce
the define output at the beginning of the various *config.h files.  This
define is not protected by a ifndef so it's not currently possible for
a user to override it in BOOT_CFLAGS.

Setting the PA architecture bits in TARGET_CPU_DEFAULT is currently a problem.
The default is still PA 1.1 even on PA 2.0 machines.  I plan to make some
changes in this area in the near future after a bug in GAS affecting level
2.0 code is fixed for elf32.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Patch: Use tm_defines to configure default scheduling model on PA

[John David Anglin]

> > I still think it better to put the defines first because the headers
> > may contain secondary defines based on the identifier that you want
> > to redefine.
> 
> Consider, for example, this from i386/cygwin.h:
> 
> /* For Win32 ABI compatibility */
> #undef DEFAULT_PCC_STRUCT_RETURN
> #define DEFAULT_PCC_STRUCT_RETURN 0
> 
> To do this with defines before includes, you'd need to put a #ifdef
> around *every single* define in *every* header file, because you won't
> know which will be overridden by targets.

Yes.  However, it's not reasonable to define the entire cygwin configuration
in configure.  If configure checked how to define DEFAULT_PCC_STRUCT_RETURN
then I would say it has a place in configure, and that there should be
a way independent of include files to override the default define.  I
agree that in some cases putting the defines after the headers is simpler
and avoids the ifdef burden, however you loose some flexibility in what
the headers can do.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Patch: Use tm_defines to configure default scheduling model on PA

[DJ Delorie]

> How does that work?  mkconfig.sh doesn't do undef's.

I didn't say it would work, but it's a technique we use elsewhere.

> I still think it better to put the defines first because the headers
> may contain secondary defines based on the identifier that you want
> to redefine.

Consider, for example, this from i386/cygwin.h:

/* For Win32 ABI compatibility */
#undef DEFAULT_PCC_STRUCT_RETURN
#define DEFAULT_PCC_STRUCT_RETURN 0

To do this with defines before includes, you'd need to put a #ifdef
around *every single* define in *every* header file, because you won't
know which will be overridden by targets.

Re: Patch: Use tm_defines to configure default scheduling model on PA

[John David Anglin]

> > that includes the various config files.  Placing the defines first
> > allows defaults in the headers to be overriden.
> 
> Placing defines after allows you to redefine something with a simple
> undef/define, without the main header needing to know that you're
> doing it.  There are cases that argue both ways, though.

How does that work?  mkconfig.sh doesn't do undef's.

Although mkconfig.sh could be modified to undef/define when necessary,
I still think it better to put the defines first because the headers
may contain secondary defines based on the identifier that you want
to redefine.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Patch: Use tm_defines to configure default scheduling model on PA

[DJ Delorie]

> that includes the various config files.  Placing the defines first
> allows defaults in the headers to be overriden.

Placing defines after allows you to redefine something with a simple
undef/define, without the main header needing to know that you're
doing it.  There are cases that argue both ways, though.

> There were a number of comments after I submitted the patch that
> indicated the number of target-specific headers in the i386 config
> was too large and the inclusion process difficult to follow.

The complexity has to go somewhere ;)

Re: Patch: Use tm_defines to configure default scheduling model on PA

[John David Anglin]

> Sorry I missed it, but the subject line was a bit misleading.  The
> patch is fine.  However, the PPC already has a way of selecting the
> default CPU (and thus scheduling etc) with a configure option and
> config.gcc.  Did you look at that mechanism before implementing this
> one?

I did but I will look more closely at what ppc has done.

> And I predict that at some point in the future, there will be a thread
> about how all those defines in config.gcc are cluttering up the
> script, and why can't we put them all in target-specific headers?

The goal here was to eliminate small target-specific headers and provide
a mechanism for selecting target options in the configuration process.
At the moment, mkconfig.sh outputs DEFINES after HEADERS.  I would
argue that we should output DEFINES first so that they can be used
to select build, host and target options in HEADERS and other code
that includes the various config files.  Placing the defines first
allows defaults in the headers to be overriden.

There were a number of comments after I submitted the patch that
indicated the number of target-specific headers in the i386 config
was too large and the inclusion process difficult to follow.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Patch: Use tm_defines to configure default scheduling model on PA

[DJ Delorie]

> > 2002-06-05  John David Anglin  <dave@hiauly1.hia.nrc.ca>
> > 
> > 	* Makefile.in (tm_defines): New configuration variable.
> > 	(cs-config.h, cs-hconfig.h, cs-tconfig.h): Rename DEFINES to XM_DEFINES.
> > 	Pass tm_defines in TM_DEFINES.
> > 	(cs-tm_p.h): Rename DEFINES to XM_DEFINES.  Pass TM_DEFINES.
> > 	* config.gcc (tm_defines): New configuration variable.
> > 	(hppa*-*-* | parisc*-*-*): Use tm_defines instead of pa-700.h and
> > 	pa-7100.h headers.  Change hppa1* scheduling default to 7100LC.
> > 	* configure.in: Substitute tm_defines.
> > 	* configure: Rebuilt.
> > 	* mkconfig.sh: Rename DEFINES to XM_DEFINES.  Output TM_DEFINES.
> > 	* pa/pa-700.h: Delete file.
> > 	* pa/pa-7100.h: Delete file.
> 
> The above patch has not been reviewed.  Could one of the build machinery
> maintainers review it?

Sorry I missed it, but the subject line was a bit misleading.  The
patch is fine.  However, the PPC already has a way of selecting the
default CPU (and thus scheduling etc) with a configure option and
config.gcc.  Did you look at that mechanism before implementing this
one?

And I predict that at some point in the future, there will be a thread
about how all those defines in config.gcc are cluttering up the
script, and why can't we put them all in target-specific headers?

Re: Patch: Use tm_defines to configure default scheduling model on PA

[John David Anglin]

> 2002-06-05  John David Anglin  <dave@hiauly1.hia.nrc.ca>
> 
> 	* Makefile.in (tm_defines): New configuration variable.
> 	(cs-config.h, cs-hconfig.h, cs-tconfig.h): Rename DEFINES to XM_DEFINES.
> 	Pass tm_defines in TM_DEFINES.
> 	(cs-tm_p.h): Rename DEFINES to XM_DEFINES.  Pass TM_DEFINES.
> 	* config.gcc (tm_defines): New configuration variable.
> 	(hppa*-*-* | parisc*-*-*): Use tm_defines instead of pa-700.h and
> 	pa-7100.h headers.  Change hppa1* scheduling default to 7100LC.
> 	* configure.in: Substitute tm_defines.
> 	* configure: Rebuilt.
> 	* mkconfig.sh: Rename DEFINES to XM_DEFINES.  Output TM_DEFINES.
> 	* pa/pa-700.h: Delete file.
> 	* pa/pa-7100.h: Delete file.

The above patch has not been reviewed.  Could one of the build machinery
maintainers review it?

Thanks,
Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Patch: Use tm_defines to configure default scheduling model on PA

[John David Anglin]

> config.gcc into
> 
>   #ifdef ABC
>   #define ABC foo
>   #endif

Oops, typo.

  #ifndef ABC
  #define ABC foo
  #endif

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)