mutex in frame code

mutex in frame code

[Ulrich Drepper]

We've recently adding to the frame installation functions in frame.c
code to protect the installation of the frame element to a global list
by an semaphore.  E.g., the __register_frame_info is

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
void
__register_frame_info (void *begin, struct object *ob)
{
  ob->fde_begin = begin;

  ob->pc_begin = ob->pc_end = 0;
  ob->fde_array = 0;
  ob->count = 0;

  init_object_mutex_once ();
  __gthread_mutex_lock (&object_mutex);

  ob->next = objects;
  objects = ob;

  __gthread_mutex_unlock (&object_mutex);
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There is a major flaw in this code.  It could use the thread functions
before the thread library is initialized.  E.g., a simple program
using pthreads could would use the libraries libpthread.so and
libc.so.  Due to the dependencies the C library is initialized first.
Part of the initialization is registration of a frame.  But now the C
library initialization will use the thread library though it is not
yet initialized.

This so far lead to no problems since in most thread implementations
the mutex functions do not need special initialization but others do.
In fact, I found this problem because the library I'm writing has this
problem.


Looking at the code one can see that the lock is used to insert into a
single-linked list.  This can be done safely without locks with an
compare & exchange instruction:

	do
	  {
	    struct object *last = objects;
	    ob->next = objects;
	  }
	while (compxchg (ob, last, ob) != 0);

with an appropriate compxchg function.  This function would be very
system-specific so Jason proposed to have a __builtin_cmpxchg function
and put the system specific bits into the .md files.


Now there is the problem that not all processors have such an opcode.
This is where the problems start.  E.g., the i386 processor has no
such opcode while i486 and up do.  I think this is the situation for
some other processor families as well.  Using the opcode nevertheless
would mean that there is not anymore full backward compatibility.
I.e., a gcc compiled for i486 will not work on i386 anymore.  I don't
think this is a problem personally.  We already have similar
restrictions (i686 code cannot be used on earlier processors) and i386
are also not anymore the commonly found platform.


One way to work around not having a compare & exchange opcode is using
spinlocks.  This works in most situations so at least one can assume
these processors still be supported.  The only situations where this
fails is with threads of different priority (priority inversion).


What I suggest is to add the __builtin_cmpxchg code.  It will be using
the asm opcode if allowed and fall back to a spinlock implementations
in the case where there is no such opcode.  If compiled without thread
support the opcode even compiles to no code at all.


Comments?

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: mutex in frame code

[Jeffrey A Law]

  In message < r2r9sjas6h.fsf@happy.cygnus.com >you write:
  > Looking at the code one can see that the lock is used to insert into a
  > single-linked list.  This can be done safely without locks with an
  > compare & exchange instruction:
  > 
  > 	do
  > 	  {
  > 	    struct object *last = objects;
  > 	    ob->next = objects;
  > 	  }
  > 	while (compxchg (ob, last, ob) != 0);
  > 
  > with an appropriate compxchg function.  This function would be very
  > system-specific so Jason proposed to have a __builtin_cmpxchg function
  > and put the system specific bits into the .md files.
I think you want two primitives:

initialize a spin lock
spin until you get the lock


  > Now there is the problem that not all processors have such an opcode.
  > This is where the problems start.  E.g., the i386 processor has no
  > such opcode while i486 and up do.  I think this is the situation for
  > some other processor families as well.  Using the opcode nevertheless
  > would mean that there is not anymore full backward compatibility.
  > I.e., a gcc compiled for i486 will not work on i386 anymore.  I don't
  > think this is a problem personally.  We already have similar
  > restrictions (i686 code cannot be used on earlier processors) and i386
  > are also not anymore the commonly found platform.
This is a problem.

While i686 code can not be used on older processors, we do not generate i686
code by default.  ie, for the x86 we generate "common" code which can execute
on any variant of the chip.  To enable i686 specific features one has to use
a flag.


jeff

Re: mutex in frame code

[Ulrich Drepper]

Jeffrey A Law <law@hurl.cygnus.com> writes:

> While i686 code can not be used on older processors, we do not generate i686
> code by default.  ie, for the x86 we generate "common" code which can execute
> on any variant of the chip.  To enable i686 specific features one has to use
> a flag.

Maybe it's the time now to step ahead and generate i486 code by default.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: mutex in frame code

[Ulrich Drepper]

Jeffrey A Law <law@hurl.cygnus.com> writes:

> While i686 code can not be used on older processors, we do not generate i686
> code by default.  ie, for the x86 we generate "common" code which can execute
> on any variant of the chip.  To enable i686 specific features one has to use
> a flag.

Maybe it's the time now to step ahead and generate i486 code by default.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: mutex in frame code

[Joe Buck]

> While i686 code can not be used on older processors, we do not generate i686
> code by default.  ie, for the x86 we generate "common" code which can execute
> on any variant of the chip.  To enable i686 specific features one has to use
> a flag.

That is, the default is -march=i386.  But I just noticed that different
ports (in particular, Sparc and ix86) are using the same -m flag with a
completely different meaning:

Generally, there are two semi-independent flags to be set when dealing
with processor families: one says which processor to optimize for, one
says which processor to assume that we have.

Thus for the sparc port I can write
	-mtune=v9 -mcpu=v8

to get code that is tuned to run best on v9 (Ultrasparcs) but that
will run on v8 machines (but will not run on v7 machines).

But for i386, we have -mcpu=x -march=y, and -mcpu for Intel means
the same as -mtune on Sparc!  -march is used to generate code that
requires a particular processor.

Re: mutex in frame code

[Jeffrey A Law]

  In message < 199901261754.JAA02030@atrus.synopsys.com >you write:
  > That is, the default is -march=i386.  But I just noticed that different
  > ports (in particular, Sparc and ix86) are using the same -m flag with a
  > completely different meaning:
Yes.  There was a great uproar on gcc2 a couple years ago about this.  I didn't
follow it closely at the time.

  > 
  > Generally, there are two semi-independent flags to be set when dealing
  > with processor families: one says which processor to optimize for, one
  > says which processor to assume that we have.
Right.


  > Thus for the sparc port I can write
  > 	-mtune=v9 -mcpu=v8
  > 
  > to get code that is tuned to run best on v9 (Ultrasparcs) but that
  > will run on v8 machines (but will not run on v7 machines).
  > 
  > But for i386, we have -mcpu=x -march=y, and -mcpu for Intel means
  > the same as -mtune on Sparc!  -march is used to generate code that
  > requires a particular processor.
Yup.  Quite inconsistent.

jeff

Re: mutex in frame code

[Joe Buck]

I wrote:

>   > That is, the default is -march=i386.  But I just noticed that different
>   > ports (in particular, Sparc and ix86) are using the same -m flag with a
>   > completely different meaning:

Jeff wrote:

> Yes.  There was a great uproar on gcc2 a couple years ago about this.  I
> didn't follow it closely at the time.

>   > Thus for the sparc port I can write
>   > 	-mtune=v9 -mcpu=v8
>   > 
>   > to get code that is tuned to run best on v9 (Ultrasparcs) but that
>   > will run on v8 machines (but will not run on v7 machines).
>   > 
>   > But for i386, we have -mcpu=x -march=y, and -mcpu for Intel means
>   > the same as -mtune on Sparc!  -march is used to generate code that
>   > requires a particular processor.
> Yup.  Quite inconsistent.

One possibility: add -march to the Sparc port, -mtune to the i386 port,
insist that all ports that target processor families use -march or -mtune
in the future, and deprecate -mcpu.  Leave it in for the time being.

Re: mutex in frame code

[David Edelsohn]

>>>>> Joe Buck writes:

Joe> One possibility: add -march to the Sparc port, -mtune to the i386 port,
Joe> insist that all ports that target processor families use -march or -mtune
Joe> in the future, and deprecate -mcpu.  Leave it in for the time being.

	Well, that does not make sense for all ports, for example rs6000.
POWER and PowerPC have defined architectures that do not change from
processor to processor.  One wants to specify a CPU to set both
architecture and tuning parameters.  Saying -march=604 is incorrect and
-march=powerpc is not specific enough.

David

Re: mutex in frame code

[Joe Buck]

> Joe> One possibility: add -march to the Sparc port, -mtune to the i386 port,
> Joe> insist that all ports that target processor families use -march or -mtune
> Joe> in the future, and deprecate -mcpu.  Leave it in for the time being.

David E. writes:

> 	Well, that does not make sense for all ports, for example rs6000.
> POWER and PowerPC have defined architectures that do not change from
> processor to processor.  One wants to specify a CPU to set both
> architecture and tuning parameters.  Saying -march=604 is incorrect and
> -march=powerpc is not specific enough.

Perhaps you're having a problem with the flag names, but the concepts are
applicable.  There's a common subset that will permit programs to run on
both POWER and PowerPC, right?  I might use -march=common to specify that.
The flag -march=powerpc would generate code that would run on any PowerPC,
but maybe not on POWER.

Generally one would not specify an exact processor in -march, but it would
make sense in -mtune.  -march says what instructions I can assume are
present (and possibly, what restrictions on instruction order for
processors without interlocks, what few that exist).  -mtune says what
I should optimize for.

Re: mutex in frame code

[David Edelsohn]

>>>>> Joe Buck writes:

Joe> Generally one would not specify an exact processor in -march, but it would
Joe> make sense in -mtune.  -march says what instructions I can assume are
Joe> present (and possibly, what restrictions on instruction order for
Joe> processors without interlocks, what few that exist).  -mtune says what
Joe> I should optimize for.

	And -mcpu specifies an architecture / tuning pair instead of
confusing users and forcing uses to type multiple options where one option
is implied by the other.

	POWER and PowerPC do not have evolving architectures.  PPC604 is
not a superset of PPC603 which is not a superset of PPC601.  "common" is a
special mode for AIX which runs on both POWER and PowerPC architectures,
but no one else does because neither is a a superset of the other.

	Will you please try to understand that your clasification does not
apply equally well to all ports and you should not impose it upon everyone?

David

Re: mutex in frame code

[Joe Buck]

David E. writes:

> 	POWER and PowerPC do not have evolving architectures.

And if the PowerPC people feel the need to do something like multimedia
extensions, what will we have?  An evolving architecture, of course.
Some people will want code that exploits these new instructions, and
others will want code that is optimized for these new processors but
that also runs on the old ones.

> 	Will you please try to understand that your clasification does not
> apply equally well to all ports and you should not impose it upon everyone?

I have no power to impose anything on anyone.  My only argument was that,
for ports to processor families where the concept *does* make sense, that
ideally the user would express the information in a consistent way.

Certainly, if it is true that every member of the PowerPC family has
exactly the same instructions, then specifying that the processor to
tune to is, say the 604, gives you the information that the architecture
is powerpc.  This information can be defaulted.

Prediction:  either someone will do a PowerPC-compatible processor with extra
instructions in the next three years, or no one will be making
PowerPC-compatible processors after three years.  You'll then need a way
to specify exactly what I am talking about: separate specification of what
to tune for and what to assume.

Re: mutex in frame code

[David Edelsohn]

>>>>> Joe Buck writes:

Joe> Certainly, if it is true that every member of the PowerPC family has
Joe> exactly the same instructions, then specifying that the processor to
Joe> tune to is, say the 604, gives you the information that the architecture
Joe> is powerpc.  This information can be defaulted.

	Uh, no.  Each processor implementation of the same architecture
has different timing parameters and number of function units.  -mtune
embodies that information.  One can specify "common" architecture yet tune
for 604.  Or specify 32-bit architecture yet tune for 64-bit processor.

	The rs6000 port already has the equivalent of -march flags in
-mpower, -mpower2, -mpowerpc, -mpowerpc64, -mpowerpc-gfxopt, etc. flags.
The rs6000 architectures are not mutually-exclusive or nested: "common"
is none of those flags, ppc601 is -mpower and -mpowerpc flags combined,
etc.  I do not see any benefit in converting those flags to -march as they
cannot be used the same way as -march on other ports where a single option
combines a number of flags.  The "rs6000" architectures already are
described in a more well-defined set of basis options.

David

Re: mutex in frame code

[David Edelsohn]

>>>>> Joe Buck writes:

Joe> Certainly, if it is true that every member of the PowerPC family has
Joe> exactly the same instructions, then specifying that the processor to
Joe> tune to is, say the 604, gives you the information that the architecture
Joe> is powerpc.  This information can be defaulted.

	Uh, no.  Each processor implementation of the same architecture
has different timing parameters and number of function units.  -mtune
embodies that information.  One can specify "common" architecture yet tune
for 604.  Or specify 32-bit architecture yet tune for 64-bit processor.

	The rs6000 port already has the equivalent of -march flags in
-mpower, -mpower2, -mpowerpc, -mpowerpc64, -mpowerpc-gfxopt, etc. flags.
The rs6000 architectures are not mutually-exclusive or nested: "common"
is none of those flags, ppc601 is -mpower and -mpowerpc flags combined,
etc.  I do not see any benefit in converting those flags to -march as they
cannot be used the same way as -march on other ports where a single option
combines a number of flags.  The "rs6000" architectures already are
described in a more well-defined set of basis options.

David

Re: mutex in frame code

[Joe Buck]

David E. writes:

> 	POWER and PowerPC do not have evolving architectures.

And if the PowerPC people feel the need to do something like multimedia
extensions, what will we have?  An evolving architecture, of course.
Some people will want code that exploits these new instructions, and
others will want code that is optimized for these new processors but
that also runs on the old ones.

> 	Will you please try to understand that your clasification does not
> apply equally well to all ports and you should not impose it upon everyone?

I have no power to impose anything on anyone.  My only argument was that,
for ports to processor families where the concept *does* make sense, that
ideally the user would express the information in a consistent way.

Certainly, if it is true that every member of the PowerPC family has
exactly the same instructions, then specifying that the processor to
tune to is, say the 604, gives you the information that the architecture
is powerpc.  This information can be defaulted.

Prediction:  either someone will do a PowerPC-compatible processor with extra
instructions in the next three years, or no one will be making
PowerPC-compatible processors after three years.  You'll then need a way
to specify exactly what I am talking about: separate specification of what
to tune for and what to assume.

Re: mutex in frame code

[David Edelsohn]

>>>>> Joe Buck writes:

Joe> Generally one would not specify an exact processor in -march, but it would
Joe> make sense in -mtune.  -march says what instructions I can assume are
Joe> present (and possibly, what restrictions on instruction order for
Joe> processors without interlocks, what few that exist).  -mtune says what
Joe> I should optimize for.

	And -mcpu specifies an architecture / tuning pair instead of
confusing users and forcing uses to type multiple options where one option
is implied by the other.

	POWER and PowerPC do not have evolving architectures.  PPC604 is
not a superset of PPC603 which is not a superset of PPC601.  "common" is a
special mode for AIX which runs on both POWER and PowerPC architectures,
but no one else does because neither is a a superset of the other.

	Will you please try to understand that your clasification does not
apply equally well to all ports and you should not impose it upon everyone?

David

Re: mutex in frame code

[Nick Ing-Simmons]

Joe Buck <jbuck@Synopsys.COM> writes:
>> Joe> One possibility: add -march to the Sparc port, -mtune to the i386 port,
>> Joe> insist that all ports that target processor families use -march or -mtune
>> Joe> in the future, and deprecate -mcpu.  Leave it in for the time being.
>
>David E. writes:
>
>> 	Well, that does not make sense for all ports, for example rs6000.
>> POWER and PowerPC have defined architectures that do not change from
>> processor to processor.  One wants to specify a CPU to set both
>> architecture and tuning parameters.  Saying -march=604 is incorrect and
>> -march=powerpc is not specific enough.
>
>Perhaps you're having a problem with the flag names, 
...

>-march says what instructions I can assume are
>present 

I suspect that 'arch' carries other expectations - perhaps -minsn would
be better?

>(and possibly, what restrictions on instruction order for
>processors without interlocks, what few that exist). 

There are more such processors than you think - most of TI's DSPs for 
a start - but as GCC does not readily lend itself to processors
without interlocks (need mandatory schedule pass with NOP insertion or
equivalent) you don't see them.

> -mtune says what
>I should optimize for.

-mopt ?


-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: mutex in frame code

[Nick Ing-Simmons]

Joe Buck <jbuck@Synopsys.COM> writes:
>> Joe> One possibility: add -march to the Sparc port, -mtune to the i386 port,
>> Joe> insist that all ports that target processor families use -march or -mtune
>> Joe> in the future, and deprecate -mcpu.  Leave it in for the time being.
>
>David E. writes:
>
>> 	Well, that does not make sense for all ports, for example rs6000.
>> POWER and PowerPC have defined architectures that do not change from
>> processor to processor.  One wants to specify a CPU to set both
>> architecture and tuning parameters.  Saying -march=604 is incorrect and
>> -march=powerpc is not specific enough.
>
>Perhaps you're having a problem with the flag names, 
...

>-march says what instructions I can assume are
>present 

I suspect that 'arch' carries other expectations - perhaps -minsn would
be better?

>(and possibly, what restrictions on instruction order for
>processors without interlocks, what few that exist). 

There are more such processors than you think - most of TI's DSPs for 
a start - but as GCC does not readily lend itself to processors
without interlocks (need mandatory schedule pass with NOP insertion or
equivalent) you don't see them.

> -mtune says what
>I should optimize for.

-mopt ?


-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: mutex in frame code

[Joe Buck]

> Joe> One possibility: add -march to the Sparc port, -mtune to the i386 port,
> Joe> insist that all ports that target processor families use -march or -mtune
> Joe> in the future, and deprecate -mcpu.  Leave it in for the time being.

David E. writes:

> 	Well, that does not make sense for all ports, for example rs6000.
> POWER and PowerPC have defined architectures that do not change from
> processor to processor.  One wants to specify a CPU to set both
> architecture and tuning parameters.  Saying -march=604 is incorrect and
> -march=powerpc is not specific enough.

Perhaps you're having a problem with the flag names, but the concepts are
applicable.  There's a common subset that will permit programs to run on
both POWER and PowerPC, right?  I might use -march=common to specify that.
The flag -march=powerpc would generate code that would run on any PowerPC,
but maybe not on POWER.

Generally one would not specify an exact processor in -march, but it would
make sense in -mtune.  -march says what instructions I can assume are
present (and possibly, what restrictions on instruction order for
processors without interlocks, what few that exist).  -mtune says what
I should optimize for.

Re: mutex in frame code

[David Edelsohn]

>>>>> Joe Buck writes:

Joe> One possibility: add -march to the Sparc port, -mtune to the i386 port,
Joe> insist that all ports that target processor families use -march or -mtune
Joe> in the future, and deprecate -mcpu.  Leave it in for the time being.

	Well, that does not make sense for all ports, for example rs6000.
POWER and PowerPC have defined architectures that do not change from
processor to processor.  One wants to specify a CPU to set both
architecture and tuning parameters.  Saying -march=604 is incorrect and
-march=powerpc is not specific enough.

David

Re: mutex in frame code

[Gabriel Dos Reis]

>>>>> Joe Buck <jbuck@Synopsys.COM> wrote:

[...]

> One possibility: add -march to the Sparc port, -mtune to the i386 port,
> insist that all ports that target processor families use -march or -mtune
> in the future, and deprecate -mcpu.  Leave it in for the time being.

Huh? It seems to me that -mcpu=v8 has been strongly promoted as an
alternative for -mv8. Sigh.

-- Gaby

Re: mutex in frame code

[Gabriel Dos Reis]

>>>>> Joe Buck <jbuck@Synopsys.COM> wrote:

[...]

> One possibility: add -march to the Sparc port, -mtune to the i386 port,
> insist that all ports that target processor families use -march or -mtune
> in the future, and deprecate -mcpu.  Leave it in for the time being.

Huh? It seems to me that -mcpu=v8 has been strongly promoted as an
alternative for -mv8. Sigh.

-- Gaby

Re: mutex in frame code

[Joe Buck]

I wrote:

>   > That is, the default is -march=i386.  But I just noticed that different
>   > ports (in particular, Sparc and ix86) are using the same -m flag with a
>   > completely different meaning:

Jeff wrote:

> Yes.  There was a great uproar on gcc2 a couple years ago about this.  I
> didn't follow it closely at the time.

>   > Thus for the sparc port I can write
>   > 	-mtune=v9 -mcpu=v8
>   > 
>   > to get code that is tuned to run best on v9 (Ultrasparcs) but that
>   > will run on v8 machines (but will not run on v7 machines).
>   > 
>   > But for i386, we have -mcpu=x -march=y, and -mcpu for Intel means
>   > the same as -mtune on Sparc!  -march is used to generate code that
>   > requires a particular processor.
> Yup.  Quite inconsistent.

One possibility: add -march to the Sparc port, -mtune to the i386 port,
insist that all ports that target processor families use -march or -mtune
in the future, and deprecate -mcpu.  Leave it in for the time being.

Re: gperf switch

[Clark Evans]

I just downloaded the current ecgs HEAD? from the cvs tree
using the anonymous access.  Then I tried to compile.  I 
received the following error during make:
 
gperf: invalid option -- F
Usage: gperf
[-cCdDef[num]GhH<hashname>i<init>Ijk<keys>K<keyname>lL<language>nN<function
name>ors<size>S<switches>tTvW<wordlistname>Z<class name>7] [input-file]
Try `gperf --help' for more information.
make[1]: *** [c-gperf.h] Error 1
make: *** [all-gcc] Error 2

I typed "gperf --version" gives me GNU gperf 2.7, I looked and this
seems to be the most updated version (ftp.gnu.org) so I was wondering
what I'm doing wrong?  I'm running Linux (Red Hat 5.2) on a i686

Thank you!

Clark Evans

Re: gperf switch

[Alexandre Oliva]

On Jan 26, 1999, Clark Evans <clark.evans@manhattanproject.com> wrote:

> I just downloaded the current ecgs HEAD? from the cvs tree
> using the anonymous access.

> gperf: invalid option -- F
> I typed "gperf --version" gives me GNU gperf 2.7, I looked and this
> seems to be the most updated version (ftp.gnu.org)

Check for a gperf patch within the infrastructure directory, in the
egcs ftp site, or use contrib/egcs_update to update your CVS tree.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: gperf switch

[Donn Terry]

Alexandre Oliva wrote:

> On Jan 26, 1999, Clark Evans <clark.evans@manhattanproject.com> wrote:
>
> > I just downloaded the current ecgs HEAD? from the cvs tree
> > using the anonymous access.
>
> > gperf: invalid option -- F
> > I typed "gperf --version" gives me GNU gperf 2.7, I looked and this
> > seems to be the most updated version (ftp.gnu.org)
>
> Check for a gperf patch within the infrastructure directory, in the
> egcs ftp site, or use contrib/egcs_update to update your CVS tree.
>

Having just gone through that same pain yesterday, I can sympathise.
There are two (at least) problem links on the egcs.cygnus.com webpage:
1) The link to the ftp site is not marked as a link, and as such when a
    new participant is looking for clues, it's not very obvious.  (And,
    as far as I was able to discover with the search engines I tried,
    none of them provide a reference to that gperf (or, if they do
they're
    swamped by bazillions of academic explanation pages for
    gperf).

2) There doesn't appear to be any link at all to the "install"
discussion,
    which I found via a backdoor thru the cygnus site search engine.

I'll also note that several important topics are buried as press
releases,
rather than having a "look here" entry (both the status and preliminary
performance web pages are that way).

A truly big help would be simply a list of web page titles and links to
them (plus one for the ftp stuff, altho a html index would be great).

Donn Terry

P.S.  Take this as a suggestion to the truly kind and  benevolent
person (whose name I have lost) who volunteered to maintain the web
pages.

Re: gperf switch

[Donn Terry]

Alexandre Oliva wrote:

> On Jan 26, 1999, Clark Evans <clark.evans@manhattanproject.com> wrote:
>
> > I just downloaded the current ecgs HEAD? from the cvs tree
> > using the anonymous access.
>
> > gperf: invalid option -- F
> > I typed "gperf --version" gives me GNU gperf 2.7, I looked and this
> > seems to be the most updated version (ftp.gnu.org)
>
> Check for a gperf patch within the infrastructure directory, in the
> egcs ftp site, or use contrib/egcs_update to update your CVS tree.
>

Having just gone through that same pain yesterday, I can sympathise.
There are two (at least) problem links on the egcs.cygnus.com webpage:
1) The link to the ftp site is not marked as a link, and as such when a
    new participant is looking for clues, it's not very obvious.  (And,
    as far as I was able to discover with the search engines I tried,
    none of them provide a reference to that gperf (or, if they do
they're
    swamped by bazillions of academic explanation pages for
    gperf).

2) There doesn't appear to be any link at all to the "install"
discussion,
    which I found via a backdoor thru the cygnus site search engine.

I'll also note that several important topics are buried as press
releases,
rather than having a "look here" entry (both the status and preliminary
performance web pages are that way).

A truly big help would be simply a list of web page titles and links to
them (plus one for the ftp stuff, altho a html index would be great).

Donn Terry

P.S.  Take this as a suggestion to the truly kind and  benevolent
person (whose name I have lost) who volunteered to maintain the web
pages.

Re: gperf switch

[Alexandre Oliva]

On Jan 26, 1999, Clark Evans <clark.evans@manhattanproject.com> wrote:

> I just downloaded the current ecgs HEAD? from the cvs tree
> using the anonymous access.

> gperf: invalid option -- F
> I typed "gperf --version" gives me GNU gperf 2.7, I looked and this
> seems to be the most updated version (ftp.gnu.org)

Check for a gperf patch within the infrastructure directory, in the
egcs ftp site, or use contrib/egcs_update to update your CVS tree.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil

Re: gperf switch

[Clark Evans]

I just downloaded the current ecgs HEAD? from the cvs tree
using the anonymous access.  Then I tried to compile.  I 
received the following error during make:
 
gperf: invalid option -- F
Usage: gperf
[-cCdDef[num]GhH<hashname>i<init>Ijk<keys>K<keyname>lL<language>nN<function
name>ors<size>S<switches>tTvW<wordlistname>Z<class name>7] [input-file]
Try `gperf --help' for more information.
make[1]: *** [c-gperf.h] Error 1
make: *** [all-gcc] Error 2

I typed "gperf --version" gives me GNU gperf 2.7, I looked and this
seems to be the most updated version (ftp.gnu.org) so I was wondering
what I'm doing wrong?  I'm running Linux (Red Hat 5.2) on a i686

Thank you!

Clark Evans

Re: mutex in frame code

[Jeffrey A Law]

  In message < 199901261754.JAA02030@atrus.synopsys.com >you write:
  > That is, the default is -march=i386.  But I just noticed that different
  > ports (in particular, Sparc and ix86) are using the same -m flag with a
  > completely different meaning:
Yes.  There was a great uproar on gcc2 a couple years ago about this.  I didn't
follow it closely at the time.

  > 
  > Generally, there are two semi-independent flags to be set when dealing
  > with processor families: one says which processor to optimize for, one
  > says which processor to assume that we have.
Right.


  > Thus for the sparc port I can write
  > 	-mtune=v9 -mcpu=v8
  > 
  > to get code that is tuned to run best on v9 (Ultrasparcs) but that
  > will run on v8 machines (but will not run on v7 machines).
  > 
  > But for i386, we have -mcpu=x -march=y, and -mcpu for Intel means
  > the same as -mtune on Sparc!  -march is used to generate code that
  > requires a particular processor.
Yup.  Quite inconsistent.

jeff

Re: mutex in frame code

[Joe Buck]

> While i686 code can not be used on older processors, we do not generate i686
> code by default.  ie, for the x86 we generate "common" code which can execute
> on any variant of the chip.  To enable i686 specific features one has to use
> a flag.

That is, the default is -march=i386.  But I just noticed that different
ports (in particular, Sparc and ix86) are using the same -m flag with a
completely different meaning:

Generally, there are two semi-independent flags to be set when dealing
with processor families: one says which processor to optimize for, one
says which processor to assume that we have.

Thus for the sparc port I can write
	-mtune=v9 -mcpu=v8

to get code that is tuned to run best on v9 (Ultrasparcs) but that
will run on v8 machines (but will not run on v7 machines).

But for i386, we have -mcpu=x -march=y, and -mcpu for Intel means
the same as -mtune on Sparc!  -march is used to generate code that
requires a particular processor.

Re: mutex in frame code

[Jeffrey A Law]

  In message < r2r9sjas6h.fsf@happy.cygnus.com >you write:
  > Looking at the code one can see that the lock is used to insert into a
  > single-linked list.  This can be done safely without locks with an
  > compare & exchange instruction:
  > 
  > 	do
  > 	  {
  > 	    struct object *last = objects;
  > 	    ob->next = objects;
  > 	  }
  > 	while (compxchg (ob, last, ob) != 0);
  > 
  > with an appropriate compxchg function.  This function would be very
  > system-specific so Jason proposed to have a __builtin_cmpxchg function
  > and put the system specific bits into the .md files.
I think you want two primitives:

initialize a spin lock
spin until you get the lock


  > Now there is the problem that not all processors have such an opcode.
  > This is where the problems start.  E.g., the i386 processor has no
  > such opcode while i486 and up do.  I think this is the situation for
  > some other processor families as well.  Using the opcode nevertheless
  > would mean that there is not anymore full backward compatibility.
  > I.e., a gcc compiled for i486 will not work on i386 anymore.  I don't
  > think this is a problem personally.  We already have similar
  > restrictions (i686 code cannot be used on earlier processors) and i386
  > are also not anymore the commonly found platform.
This is a problem.

While i686 code can not be used on older processors, we do not generate i686
code by default.  ie, for the x86 we generate "common" code which can execute
on any variant of the chip.  To enable i686 specific features one has to use
a flag.


jeff

mutex in frame code

[Ulrich Drepper]

We've recently adding to the frame installation functions in frame.c
code to protect the installation of the frame element to a global list
by an semaphore.  E.g., the __register_frame_info is

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
void
__register_frame_info (void *begin, struct object *ob)
{
  ob->fde_begin = begin;

  ob->pc_begin = ob->pc_end = 0;
  ob->fde_array = 0;
  ob->count = 0;

  init_object_mutex_once ();
  __gthread_mutex_lock (&object_mutex);

  ob->next = objects;
  objects = ob;

  __gthread_mutex_unlock (&object_mutex);
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There is a major flaw in this code.  It could use the thread functions
before the thread library is initialized.  E.g., a simple program
using pthreads could would use the libraries libpthread.so and
libc.so.  Due to the dependencies the C library is initialized first.
Part of the initialization is registration of a frame.  But now the C
library initialization will use the thread library though it is not
yet initialized.

This so far lead to no problems since in most thread implementations
the mutex functions do not need special initialization but others do.
In fact, I found this problem because the library I'm writing has this
problem.


Looking at the code one can see that the lock is used to insert into a
single-linked list.  This can be done safely without locks with an
compare & exchange instruction:

	do
	  {
	    struct object *last = objects;
	    ob->next = objects;
	  }
	while (compxchg (ob, last, ob) != 0);

with an appropriate compxchg function.  This function would be very
system-specific so Jason proposed to have a __builtin_cmpxchg function
and put the system specific bits into the .md files.


Now there is the problem that not all processors have such an opcode.
This is where the problems start.  E.g., the i386 processor has no
such opcode while i486 and up do.  I think this is the situation for
some other processor families as well.  Using the opcode nevertheless
would mean that there is not anymore full backward compatibility.
I.e., a gcc compiled for i486 will not work on i386 anymore.  I don't
think this is a problem personally.  We already have similar
restrictions (i686 code cannot be used on earlier processors) and i386
are also not anymore the commonly found platform.


One way to work around not having a compare & exchange opcode is using
spinlocks.  This works in most situations so at least one can assume
these processors still be supported.  The only situations where this
fails is with threads of different priority (priority inversion).


What I suggest is to add the __builtin_cmpxchg code.  It will be using
the asm opcode if allowed and fall back to a spinlock implementations
in the case where there is no such opcode.  If compiled without thread
support the opcode even compiles to no code at all.


Comments?

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: mutex in frame code

[Mike Stump]

> From: Joe Buck <jbuck@Synopsys.COM>
> To: law@cygnus.com
> Date: Tue, 26 Jan 99 9:54:36 PST

> But for i386, we have -mcpu=x -march=y, and -mcpu for Intel means
> the same as -mtune on Sparc!  -march is used to generate code that
> requires a particular processor.

This is unfortunate.  We need a command decision to bit the bullet and
then to make the ports conform to this decision and document it.
:-(  My guess is the SPARC port is wrong and should be fixed.

Re: mutex in frame code

[Mike Stump]

> From: Joe Buck <jbuck@Synopsys.COM>
> To: law@cygnus.com
> Date: Tue, 26 Jan 99 9:54:36 PST

> But for i386, we have -mcpu=x -march=y, and -mcpu for Intel means
> the same as -mtune on Sparc!  -march is used to generate code that
> requires a particular processor.

This is unfortunate.  We need a command decision to bit the bullet and
then to make the ports conform to this decision and document it.
:-(  My guess is the SPARC port is wrong and should be fixed.

Re: mutex in frame code

[Richard Earnshaw]

> > From: Joe Buck <jbuck@Synopsys.COM>
> > To: law@cygnus.com
> > Date: Tue, 26 Jan 99 9:54:36 PST
> 
> > But for i386, we have -mcpu=x -march=y, and -mcpu for Intel means
> > the same as -mtune on Sparc!  -march is used to generate code that
> > requires a particular processor.
> 
> This is unfortunate.  We need a command decision to bit the bullet and
> then to make the ports conform to this decision and document it.
> :-(  My guess is the SPARC port is wrong and should be fixed.

Well on the ARM, -mcpu=<cpu> is short-hand for "-march=<archof(cpu)> 
-mtune=cpu".  It makes life a little more complicated for me, but much 
easier for the user since only one option has to be given instead of two.

Re: mutex in frame code

[Richard Henderson]

On Mon, Feb 01, 1999 at 03:36:10PM +0000, Richard Earnshaw wrote:
> > > From: Joe Buck <jbuck@Synopsys.COM>
> > This is unfortunate.  We need a command decision to bit the bullet and
> > then to make the ports conform to this decision and document it.
> > :-(  My guess is the SPARC port is wrong and should be fixed.
> 
> Well on the ARM, -mcpu=<cpu> is short-hand for "-march=<archof(cpu)> 
> -mtune=cpu".  It makes life a little more complicated for me, but much 
> easier for the user since only one option has to be given instead of two.

If we commonize on anything, I think it should be `arch' and `tune';
`cpu' is too ambiguous.


r~

Re: mutex in frame code

[David Edelsohn]

>>>>> Richard Henderson writes:

Richard> If we commonize on anything, I think it should be `arch' and `tune';
Richard> `cpu' is too ambiguous.

	I repeat again that -march= provides the wrong information for the
PowerPC port.  One wants a simple way to specify both architecture and
scheduler tuning; -mcpu= provides that information.  -march= primarily is
useful for processors in which each chip extended the architecture like
x86 and Alpha, not for processors where an ISA was designed and maintained
like PowerPC.

David

Re: mutex in frame code

[Joe Buck]

> >>>>> Richard Henderson writes:
> 
> Richard> If we commonize on anything, I think it should be `arch' and `tune';
> Richard> `cpu' is too ambiguous.
> 
> 	I repeat again that -march= provides the wrong information for the
> PowerPC port.  One wants a simple way to specify both architecture and
> scheduler tuning; -mcpu= provides that information.

The ability to have two flags is important only when the user is
distributing binaries that must work on multiple variants of the same
architecture.

Consider architectures to be sets (there are multiple implementations of
a given architecture).  With -mtune you specify that you want to tune for
one member of the set, with -march you would specify the set.  If there
is only one possible set that a member can belong to (evidently the case
for the PowerPC port), the user would only need to give the -mtune flag,
and the -mcpu flag can be a synonym.  Consequence: no change for the
PowerPC port, except maybe accepting a synonym for the flag to make things
more consistent.

I was under the impression that there are really three sets for the
Power/PowerPC port: POWER machines, PowerPC machines, and common, where
we want to produce code that runs on either.  You're the expert, if you
say there is no reason for "common" I'll take your word for it.
But at least conceptually it seems I could say to tune for some processor
but generate common code.

>  -march= primarily is
> useful for processors in which each chip extended the architecture like
> x86 and Alpha, not for processors where an ISA was designed and maintained
> like PowerPC.

If so, we can at least discuss how to use it consistently.

Re: mutex in frame code

[David Edelsohn]

	The POWER and PowerPC architecture do not describe a nested set
which is exactly what is assumed by this entire -march= discussion.  You
and Richard and others are relying on the fact that -march=X is a complete
subset of -march=X+1.  On POWER and PowerPC that is not the case.

	The POWER and PowerPC architectures implement a number of features
such as POWER/2 extensions, PowerPC general-purpose extensions, PowerPC
graphics extensions, presence of floating-point, etc.  Specifying which
combinarion of extensions is specified by processor -- CPU -- not by
architecture.  Using the option -march= but specifying CPU is confusing
and incorrect.

	If you want to ask me questions about this, I would be happy to
answer it, but please stop lecturing me about the PowerPC architecture and
port from a lack of knowledge.  And please stop using condescending
phrases like "You're the expert, if you say there is no reason for
"common" I'll take your word for it" to introduce misinterpretations and
misrepresentations.  That is not what I said.

Thanks, David

Re: mutex in frame code

[Zack Weinberg]

On Mon, 01 Feb 1999 13:16:28 -0500, David Edelsohn wrote:
>	The POWER and PowerPC architecture do not describe a nested set
>which is exactly what is assumed by this entire -march= discussion.  You
>and Richard and others are relying on the fact that -march=X is a complete
>subset of -march=X+1.  On POWER and PowerPC that is not the case.
>
>	The POWER and PowerPC architectures implement a number of features
>such as POWER/2 extensions, PowerPC general-purpose extensions, PowerPC
>graphics extensions, presence of floating-point, etc.  Specifying which
>combinarion of extensions is specified by processor -- CPU -- not by
>architecture.  Using the option -march= but specifying CPU is confusing
>and incorrect.

Any number of CPU implementations may implement the same set of
extensions, yesno?  And they might have different cache / scheduling
characteristics?

It seems to me that -march=<list of extensions> would be appropriate,
perhaps with aliases for common sets.  -mtune can specify cache and
scheduling parameters, and -mcpu select both.

zw

Re: mutex in frame code

[David Edelsohn]

>>>>> Zack Weinberg writes:

Zack> Any number of CPU implementations may implement the same set of
Zack> extensions, yesno?  And they might have different cache / scheduling
Zack> characteristics?

Zack> It seems to me that -march=<list of extensions> would be appropriate,
Zack> perhaps with aliases for common sets.  -mtune can specify cache and
Zack> scheduling parameters, and -mcpu select both.

	The list of extensions already is provided through -m flags,
e.g. -mpower, -mpowerpc, -mpowerpc-gfxopt, -mpower2, etc.  The -mcpu=
option provides aliases for common sets associated with each processor.
Again, saying a processor is an architecture is WRONG.  Would all of you
please read the GCC documentation on these options in the rs6000 port
instead of having me explain them one by one?

David

Re: mutex in frame code

[Joe Buck]

> 	The list of extensions already is provided through -m flags,
> e.g. -mpower, -mpowerpc, -mpowerpc-gfxopt, -mpower2, etc.  The -mcpu=
> option provides aliases for common sets associated with each processor.
> Again, saying a processor is an architecture is WRONG.

We agree.  So who are you arguing with?  An architecture is a set of
processors, each of which implement that architecture.

Re: mutex in frame code

[David Edelsohn]

>>>>> Joe Buck writes:

>> The list of extensions already is provided through -m flags,
>> e.g. -mpower, -mpowerpc, -mpowerpc-gfxopt, -mpower2, etc.  The -mcpu=
>> option provides aliases for common sets associated with each processor.
>> Again, saying a processor is an architecture is WRONG.

Joe> We agree.  So who are you arguing with?  An architecture is a set of
Joe> processors, each of which implement that architecture.

	I am arguing with people who are proposing removing -mcpu= in
favor of -march= and specifying archicture/tuning processor aliases to
-march=.  If you only want to move the -mextensions bits to
-march=extension, that is fine with me.  I do not have a problem with
-march=architecture assuming some benign tuning model.  I want -mcpu= to
stay and I DO NOT want -march=cpu to mean anything or to be a synonym for
anything.

	The rs6000 port allows -mno-extension to remove options implicit
in some processor.  -mcpu= and -mextension currently interact correctly in
the port.  If -march=no-extension also works correctly, they should be
equivalent.  -mpowerpc-gfxopt enables both basic PowerPC architecture and
PowerPC graphics options while -mno-powerpc-gfxopt only disables PowerPC
graphics options while leaving the basic PowerPC architecture enabled.  I
think that this is what you want -march=alias to mean anyway.  -march=
should specify architectures or correct combinations of architectures, not
processors.

David

Re: mutex in frame code

[David Edelsohn]

>>>>> Joe Buck writes:

>> The list of extensions already is provided through -m flags,
>> e.g. -mpower, -mpowerpc, -mpowerpc-gfxopt, -mpower2, etc.  The -mcpu=
>> option provides aliases for common sets associated with each processor.
>> Again, saying a processor is an architecture is WRONG.

Joe> We agree.  So who are you arguing with?  An architecture is a set of
Joe> processors, each of which implement that architecture.

	I am arguing with people who are proposing removing -mcpu= in
favor of -march= and specifying archicture/tuning processor aliases to
-march=.  If you only want to move the -mextensions bits to
-march=extension, that is fine with me.  I do not have a problem with
-march=architecture assuming some benign tuning model.  I want -mcpu= to
stay and I DO NOT want -march=cpu to mean anything or to be a synonym for
anything.

	The rs6000 port allows -mno-extension to remove options implicit
in some processor.  -mcpu= and -mextension currently interact correctly in
the port.  If -march=no-extension also works correctly, they should be
equivalent.  -mpowerpc-gfxopt enables both basic PowerPC architecture and
PowerPC graphics options while -mno-powerpc-gfxopt only disables PowerPC
graphics options while leaving the basic PowerPC architecture enabled.  I
think that this is what you want -march=alias to mean anyway.  -march=
should specify architectures or correct combinations of architectures, not
processors.

David

Re: mutex in frame code

[Joe Buck]

> 	The list of extensions already is provided through -m flags,
> e.g. -mpower, -mpowerpc, -mpowerpc-gfxopt, -mpower2, etc.  The -mcpu=
> option provides aliases for common sets associated with each processor.
> Again, saying a processor is an architecture is WRONG.

We agree.  So who are you arguing with?  An architecture is a set of
processors, each of which implement that architecture.

Re: mutex in frame code

[David Edelsohn]

>>>>> Zack Weinberg writes:

Zack> Any number of CPU implementations may implement the same set of
Zack> extensions, yesno?  And they might have different cache / scheduling
Zack> characteristics?

Zack> It seems to me that -march=<list of extensions> would be appropriate,
Zack> perhaps with aliases for common sets.  -mtune can specify cache and
Zack> scheduling parameters, and -mcpu select both.

	The list of extensions already is provided through -m flags,
e.g. -mpower, -mpowerpc, -mpowerpc-gfxopt, -mpower2, etc.  The -mcpu=
option provides aliases for common sets associated with each processor.
Again, saying a processor is an architecture is WRONG.  Would all of you
please read the GCC documentation on these options in the rs6000 port
instead of having me explain them one by one?

David

Re: mutex in frame code

[Zack Weinberg]

On Mon, 01 Feb 1999 13:16:28 -0500, David Edelsohn wrote:
>	The POWER and PowerPC architecture do not describe a nested set
>which is exactly what is assumed by this entire -march= discussion.  You
>and Richard and others are relying on the fact that -march=X is a complete
>subset of -march=X+1.  On POWER and PowerPC that is not the case.
>
>	The POWER and PowerPC architectures implement a number of features
>such as POWER/2 extensions, PowerPC general-purpose extensions, PowerPC
>graphics extensions, presence of floating-point, etc.  Specifying which
>combinarion of extensions is specified by processor -- CPU -- not by
>architecture.  Using the option -march= but specifying CPU is confusing
>and incorrect.

Any number of CPU implementations may implement the same set of
extensions, yesno?  And they might have different cache / scheduling
characteristics?

It seems to me that -march=<list of extensions> would be appropriate,
perhaps with aliases for common sets.  -mtune can specify cache and
scheduling parameters, and -mcpu select both.

zw

Re: mutex in frame code

[Joe Buck]

> 	The POWER and PowerPC architecture do not describe a nested set
> which is exactly what is assumed by this entire -march= discussion.  You
> and Richard and others are relying on the fact that -march=X is a complete
> subset of -march=X+1.  On POWER and PowerPC that is not the case.

I am doing no such thing!  It appears that this is the source of your
misunderstanding (that is, you are not understanding what I am proposing).
Nonoverlapping sets will work fine.

You seem to be assuming that architectures and specific processors would
have the same names.  They don't need to.  Perhaps "architecture" is a
confusing here because you are insisting that all PowerPCs have the same
architecture even though they clearly do not: if some have graphics
extensions and some do not, that is an architectural extension.  Sun
marketing says v7 and v8 are different architectures even though the
differences are quite small; evidently the PowerPC marketing guys want
to use the language in a different way.

As for the rest of it, if you can't discuss this issue without getting
so emotional, you're working too hard.  I'm not going to argue with you any
more.

Re: mutex in frame code

[Joe Buck]

> 	The POWER and PowerPC architecture do not describe a nested set
> which is exactly what is assumed by this entire -march= discussion.  You
> and Richard and others are relying on the fact that -march=X is a complete
> subset of -march=X+1.  On POWER and PowerPC that is not the case.

I am doing no such thing!  It appears that this is the source of your
misunderstanding (that is, you are not understanding what I am proposing).
Nonoverlapping sets will work fine.

You seem to be assuming that architectures and specific processors would
have the same names.  They don't need to.  Perhaps "architecture" is a
confusing here because you are insisting that all PowerPCs have the same
architecture even though they clearly do not: if some have graphics
extensions and some do not, that is an architectural extension.  Sun
marketing says v7 and v8 are different architectures even though the
differences are quite small; evidently the PowerPC marketing guys want
to use the language in a different way.

As for the rest of it, if you can't discuss this issue without getting
so emotional, you're working too hard.  I'm not going to argue with you any
more.

Re: mutex in frame code

[Matthias Urlichs]

Hi,

David Edelsohn:
> 	The POWER and PowerPC architecture do not describe a nested set
> which is exactly what is assumed by this entire -march= discussion.  You
> and Richard and others are relying on the fact that -march=X is a complete
> subset of -march=X+1.  On POWER and PowerPC that is not the case.
> 
But there's an instruction set X such that all Xn with n>0 are superset of
that X, right? (X may not correspond to any existing piece of hardware, but
that's not the point.)

The real question is, though, whether there are scheduler or other
differences between different PowerPC CPUs such that optimizing for any of
them makes sense. (Like the difference between i586 and i686.)
If there are, an -mtune=FOO option makes sense; if not, it doesn't.

> architecture.  Using the option -march= but specifying CPU is confusing
> and incorrect.
> 
We need options for controlling (a) which instruction set to assume, and
(b) which particular CPU to optimize for. Calling (a) -march and (b) -mcpu
may not be 100% optimal or intuitive, but it's there. I'd name them
(a) -mbase and (b) -mtune if I felt the need to make the option tags more
unambiguous.

If the assumption above doesn't hold and there are incompatible sets X and
Y instead, they should have different targets.

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
National security is the chief cause of national insecurity.

Re: mutex in frame code

[David Edelsohn]

>>>>> "Matthias Urlichs" writes:

Matthias> The real question is, though, whether there are scheduler or other
Matthias> differences between different PowerPC CPUs such that optimizing for any of
Matthias> them makes sense. (Like the difference between i586 and i686.)
Matthias> If there are, an -mtune=FOO option makes sense; if not, it doesn't.

	The various PowerPC processors are significantly different in
their scheduling parameters.

Matthias> We need options for controlling (a) which instruction set to assume, and
Matthias> (b) which particular CPU to optimize for. Calling (a) -march and (b) -mcpu
Matthias> may not be 100% optimal or intuitive, but it's there. I'd name them
Matthias> (a) -mbase and (b) -mtune if I felt the need to make the option tags more
Matthias> unambiguous.

	I agree that -mcpu= should not be used to designate a tuning
parameter, but -mcpu= is a useful alias combining both -march= and
-mtune=.  The simplest way to describe the combination is using the
particular processor implementation.  A processor designation is not an
architecture.

	One could say -march=ppc,ppcgfx -mtune=604 or -march=ppcgfx
-mtune=604 (with ppcgfx implying base ppc as well) but why not simply say
-mcpu=604?

	It is useful to say -march=ppc -mtune=750 to utilize the base
PowerPC ISA and tune for PPC604, e.g., be compatible with all consumer
PowerPC chips but tune for latest processor.  Maybe the latter is what GCC
should produce for PowerPC by default (as opposed to tuning for PPC601 as
it still does). 

	Most users know about the chips, not the optional extensions to
the ISA.  They would like to specify a CPU and have the compiler produce
code that is optimal for that processor -- both ISA extensions and
scheduling.  One can argue that such a user should know about the various
ISA options, but why make it more complicated?

	IBM's XLC uses the arch/tune combination, but the compiler
primarily is targeted at the technical workstation users.  GCC handles
embedded processors as well, i.e., processors which might exclude the
floating-point instructions -- maybe -march=ppcnof?

	-march= and -mtune= are useful for the knowledgeable power user.
-mcpu= is useful for the power user (as a short alias) and the common user
(who does not know which processors implement which PowerPC ISA
extensions).  I do not think that all users should be forced into a steep
learning curve to make intuitively optimal use of the compiler nor should
GCC start redefining the terms architecture and processor to allow the
options to be squeezed down to two from three.

	All three are useful.  All three have meaning.  Maybe I have
misunderstood the current state of this discussion, but I still see people
speaking of only two options, which two are necessary, and how the meaning
of the two options should be interpreted.  I am voting that we implement
all three consistently across all ports.

David

Re: mutex in frame code

[David Edelsohn]

>>>>> "Matthias Urlichs" writes:

Matthias> The real question is, though, whether there are scheduler or other
Matthias> differences between different PowerPC CPUs such that optimizing for any of
Matthias> them makes sense. (Like the difference between i586 and i686.)
Matthias> If there are, an -mtune=FOO option makes sense; if not, it doesn't.

	The various PowerPC processors are significantly different in
their scheduling parameters.

Matthias> We need options for controlling (a) which instruction set to assume, and
Matthias> (b) which particular CPU to optimize for. Calling (a) -march and (b) -mcpu
Matthias> may not be 100% optimal or intuitive, but it's there. I'd name them
Matthias> (a) -mbase and (b) -mtune if I felt the need to make the option tags more
Matthias> unambiguous.

	I agree that -mcpu= should not be used to designate a tuning
parameter, but -mcpu= is a useful alias combining both -march= and
-mtune=.  The simplest way to describe the combination is using the
particular processor implementation.  A processor designation is not an
architecture.

	One could say -march=ppc,ppcgfx -mtune=604 or -march=ppcgfx
-mtune=604 (with ppcgfx implying base ppc as well) but why not simply say
-mcpu=604?

	It is useful to say -march=ppc -mtune=750 to utilize the base
PowerPC ISA and tune for PPC604, e.g., be compatible with all consumer
PowerPC chips but tune for latest processor.  Maybe the latter is what GCC
should produce for PowerPC by default (as opposed to tuning for PPC601 as
it still does). 

	Most users know about the chips, not the optional extensions to
the ISA.  They would like to specify a CPU and have the compiler produce
code that is optimal for that processor -- both ISA extensions and
scheduling.  One can argue that such a user should know about the various
ISA options, but why make it more complicated?

	IBM's XLC uses the arch/tune combination, but the compiler
primarily is targeted at the technical workstation users.  GCC handles
embedded processors as well, i.e., processors which might exclude the
floating-point instructions -- maybe -march=ppcnof?

	-march= and -mtune= are useful for the knowledgeable power user.
-mcpu= is useful for the power user (as a short alias) and the common user
(who does not know which processors implement which PowerPC ISA
extensions).  I do not think that all users should be forced into a steep
learning curve to make intuitively optimal use of the compiler nor should
GCC start redefining the terms architecture and processor to allow the
options to be squeezed down to two from three.

	All three are useful.  All three have meaning.  Maybe I have
misunderstood the current state of this discussion, but I still see people
speaking of only two options, which two are necessary, and how the meaning
of the two options should be interpreted.  I am voting that we implement
all three consistently across all ports.

David

Re: mutex in frame code

[Matthias Urlichs]

Hi,

David Edelsohn:
> 	The POWER and PowerPC architecture do not describe a nested set
> which is exactly what is assumed by this entire -march= discussion.  You
> and Richard and others are relying on the fact that -march=X is a complete
> subset of -march=X+1.  On POWER and PowerPC that is not the case.
> 
But there's an instruction set X such that all Xn with n>0 are superset of
that X, right? (X may not correspond to any existing piece of hardware, but
that's not the point.)

The real question is, though, whether there are scheduler or other
differences between different PowerPC CPUs such that optimizing for any of
them makes sense. (Like the difference between i586 and i686.)
If there are, an -mtune=FOO option makes sense; if not, it doesn't.

> architecture.  Using the option -march= but specifying CPU is confusing
> and incorrect.
> 
We need options for controlling (a) which instruction set to assume, and
(b) which particular CPU to optimize for. Calling (a) -march and (b) -mcpu
may not be 100% optimal or intuitive, but it's there. I'd name them
(a) -mbase and (b) -mtune if I felt the need to make the option tags more
unambiguous.

If the assumption above doesn't hold and there are incompatible sets X and
Y instead, they should have different targets.

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
National security is the chief cause of national insecurity.

Re: mutex in frame code

[David Edelsohn]

	The POWER and PowerPC architecture do not describe a nested set
which is exactly what is assumed by this entire -march= discussion.  You
and Richard and others are relying on the fact that -march=X is a complete
subset of -march=X+1.  On POWER and PowerPC that is not the case.

	The POWER and PowerPC architectures implement a number of features
such as POWER/2 extensions, PowerPC general-purpose extensions, PowerPC
graphics extensions, presence of floating-point, etc.  Specifying which
combinarion of extensions is specified by processor -- CPU -- not by
architecture.  Using the option -march= but specifying CPU is confusing
and incorrect.

	If you want to ask me questions about this, I would be happy to
answer it, but please stop lecturing me about the PowerPC architecture and
port from a lack of knowledge.  And please stop using condescending
phrases like "You're the expert, if you say there is no reason for
"common" I'll take your word for it" to introduce misinterpretations and
misrepresentations.  That is not what I said.

Thanks, David

Re: mutex in frame code

[Joe Buck]

> >>>>> Richard Henderson writes:
> 
> Richard> If we commonize on anything, I think it should be `arch' and `tune';
> Richard> `cpu' is too ambiguous.
> 
> 	I repeat again that -march= provides the wrong information for the
> PowerPC port.  One wants a simple way to specify both architecture and
> scheduler tuning; -mcpu= provides that information.

The ability to have two flags is important only when the user is
distributing binaries that must work on multiple variants of the same
architecture.

Consider architectures to be sets (there are multiple implementations of
a given architecture).  With -mtune you specify that you want to tune for
one member of the set, with -march you would specify the set.  If there
is only one possible set that a member can belong to (evidently the case
for the PowerPC port), the user would only need to give the -mtune flag,
and the -mcpu flag can be a synonym.  Consequence: no change for the
PowerPC port, except maybe accepting a synonym for the flag to make things
more consistent.

I was under the impression that there are really three sets for the
Power/PowerPC port: POWER machines, PowerPC machines, and common, where
we want to produce code that runs on either.  You're the expert, if you
say there is no reason for "common" I'll take your word for it.
But at least conceptually it seems I could say to tune for some processor
but generate common code.

>  -march= primarily is
> useful for processors in which each chip extended the architecture like
> x86 and Alpha, not for processors where an ISA was designed and maintained
> like PowerPC.

If so, we can at least discuss how to use it consistently.

Re: mutex in frame code

[Zack Weinberg]

On Mon, 01 Feb 1999 12:52:50 -0500, David Edelsohn wrote:
>>>>>> Richard Henderson writes:
>
>Richard> If we commonize on anything, I think it should be `arch' and `tune';
>Richard> `cpu' is too ambiguous.
>
>	I repeat again that -march= provides the wrong information for the
>PowerPC port.  One wants a simple way to specify both architecture and
>scheduler tuning; -mcpu= provides that information.  -march= primarily is
>useful for processors in which each chip extended the architecture like
>x86 and Alpha, not for processors where an ISA was designed and maintained
>like PowerPC.

What about this Altivec stuff?  That's an ISA extension.

You could provide -mtune=foo, with -mcpu=foo an alias, and not have
any -march= options.

zw

Re: mutex in frame code

[David Edelsohn]

>>>>> Zack Weinberg writes:

Zack> What about this Altivec stuff?  That's an ISA extension.

	Yes, an optional extension like graphics and general purpose
extensions and some embedded chips lacking floating point.  Motorola also
has a number of extensions in their embedded chips for controlling
additional function units and ports.  Also, the Altivec ISA should remain
consistent, not growing like MMX, et al.  I am not even sure if Altivec is
an official optional extension to the PowerPC architecture.

David

Re: mutex in frame code

[David Edelsohn]

>>>>> Zack Weinberg writes:

Zack> What about this Altivec stuff?  That's an ISA extension.

	Yes, an optional extension like graphics and general purpose
extensions and some embedded chips lacking floating point.  Motorola also
has a number of extensions in their embedded chips for controlling
additional function units and ports.  Also, the Altivec ISA should remain
consistent, not growing like MMX, et al.  I am not even sure if Altivec is
an official optional extension to the PowerPC architecture.

David

Re: mutex in frame code

[Zack Weinberg]

On Mon, 01 Feb 1999 12:52:50 -0500, David Edelsohn wrote:
>>>>>> Richard Henderson writes:
>
>Richard> If we commonize on anything, I think it should be `arch' and `tune';
>Richard> `cpu' is too ambiguous.
>
>	I repeat again that -march= provides the wrong information for the
>PowerPC port.  One wants a simple way to specify both architecture and
>scheduler tuning; -mcpu= provides that information.  -march= primarily is
>useful for processors in which each chip extended the architecture like
>x86 and Alpha, not for processors where an ISA was designed and maintained
>like PowerPC.

What about this Altivec stuff?  That's an ISA extension.

You could provide -mtune=foo, with -mcpu=foo an alias, and not have
any -march= options.

zw

Re: mutex in frame code

[David Edelsohn]

>>>>> Richard Henderson writes:

Richard> If we commonize on anything, I think it should be `arch' and `tune';
Richard> `cpu' is too ambiguous.

	I repeat again that -march= provides the wrong information for the
PowerPC port.  One wants a simple way to specify both architecture and
scheduler tuning; -mcpu= provides that information.  -march= primarily is
useful for processors in which each chip extended the architecture like
x86 and Alpha, not for processors where an ISA was designed and maintained
like PowerPC.

David

Re: mutex in frame code

[Richard Earnshaw]

> On Mon, Feb 01, 1999 at 03:36:10PM +0000, Richard Earnshaw wrote:
> > > > From: Joe Buck <jbuck@Synopsys.COM>
> > > This is unfortunate.  We need a command decision to bit the bullet and
> > > then to make the ports conform to this decision and document it.
> > > :-(  My guess is the SPARC port is wrong and should be fixed.
> > 
> > Well on the ARM, -mcpu=<cpu> is short-hand for "-march=<archof(cpu)> 
> > -mtune=cpu".  It makes life a little more complicated for me, but much 
> > easier for the user since only one option has to be given instead of two.
> 
> If we commonize on anything, I think it should be `arch' and `tune';
> `cpu' is too ambiguous.

Don't get me wrong -- I think -march and -mtune should be there, but it is 
a bit of a pain if you always have to specify both with effectively the 
same setting, hence -mcpu as well.  My guess is that most users playing 
with this flag are going to want to set them to produce best code on the 
machine they are currently using.  If you really care you can still use 
the separate flags.

As for documentation, what's wrong with

-march=foo
	...
-mtune=foo
	...
-mcpu=foo
	Synonym for -march=foo -mtune=foo

R.

Re: mutex in frame code

[Richard Earnshaw]

> On Mon, Feb 01, 1999 at 03:36:10PM +0000, Richard Earnshaw wrote:
> > > > From: Joe Buck <jbuck@Synopsys.COM>
> > > This is unfortunate.  We need a command decision to bit the bullet and
> > > then to make the ports conform to this decision and document it.
> > > :-(  My guess is the SPARC port is wrong and should be fixed.
> > 
> > Well on the ARM, -mcpu=<cpu> is short-hand for "-march=<archof(cpu)> 
> > -mtune=cpu".  It makes life a little more complicated for me, but much 
> > easier for the user since only one option has to be given instead of two.
> 
> If we commonize on anything, I think it should be `arch' and `tune';
> `cpu' is too ambiguous.

Don't get me wrong -- I think -march and -mtune should be there, but it is 
a bit of a pain if you always have to specify both with effectively the 
same setting, hence -mcpu as well.  My guess is that most users playing 
with this flag are going to want to set them to produce best code on the 
machine they are currently using.  If you really care you can still use 
the separate flags.

As for documentation, what's wrong with

-march=foo
	...
-mtune=foo
	...
-mcpu=foo
	Synonym for -march=foo -mtune=foo

R.

Re: mutex in frame code

[Richard Henderson]

On Mon, Feb 01, 1999 at 03:36:10PM +0000, Richard Earnshaw wrote:
> > > From: Joe Buck <jbuck@Synopsys.COM>
> > This is unfortunate.  We need a command decision to bit the bullet and
> > then to make the ports conform to this decision and document it.
> > :-(  My guess is the SPARC port is wrong and should be fixed.
> 
> Well on the ARM, -mcpu=<cpu> is short-hand for "-march=<archof(cpu)> 
> -mtune=cpu".  It makes life a little more complicated for me, but much 
> easier for the user since only one option has to be given instead of two.

If we commonize on anything, I think it should be `arch' and `tune';
`cpu' is too ambiguous.


r~

Re: mutex in frame code

[Richard Earnshaw]

> > From: Joe Buck <jbuck@Synopsys.COM>
> > To: law@cygnus.com
> > Date: Tue, 26 Jan 99 9:54:36 PST
> 
> > But for i386, we have -mcpu=x -march=y, and -mcpu for Intel means
> > the same as -mtune on Sparc!  -march is used to generate code that
> > requires a particular processor.
> 
> This is unfortunate.  We need a command decision to bit the bullet and
> then to make the ports conform to this decision and document it.
> :-(  My guess is the SPARC port is wrong and should be fixed.

Well on the ARM, -mcpu=<cpu> is short-hand for "-march=<archof(cpu)> 
-mtune=cpu".  It makes life a little more complicated for me, but much 
easier for the user since only one option has to be given instead of two.

Re: mutex in frame code

[Mike Stump]

> Date: Tue, 02 Feb 1999 13:04:20 -0500
> From: David Edelsohn <dje@watson.ibm.com>

> I am voting that we implement all three consistently across all
> ports.

David and I agree.  Does anyone disagree?  If so, why?  Specifically,
we are talking about changing the x86 and mips ports to fall in line
with _all_ the other ports, and that these three options be documented
machine independently (specific values of course will be machine
dependent).  Did I miss any ports?

-mcpu=486 I propose will be the same as -march=486 -mtune=486, I don't
believe it means that now, but I think it means -march=386 -mtune=486
currently.

Re: mutex in frame code

[Gavin Romig-Koch]

> and that these three options be documented machine independently 
> (specific values of course will be machine dependent).

I agree with the idea of working towards having all the ports
have similar meanings for the -mcpu, -mtune, and -march flags,
but I disagree with the idea of documenting these flags as if
they were machine independent.  There may be good reason for
a particular port to have a different meaning for these options,
either for the time being, or permanantly.  Documenting these
options as machine independent either forces port maintainers
to follow the documented behavior even when it doesnt make sense
for a paticular port, or it means that the doc isn't correct 
for all ports.  Leaving the exact meaning of these options
machine dependent, while encouraging ports to follow the overall
standard, gives port maintainers the freedom to make the right
decision for a paticular port.

If you really want machine independent options for these things,
and I'm not opposed to such a thing, then you should actually 
create some machine independent options (say --tune=, --arch=, 
and --cpu=) in the usual way.

                                          -gavin...

Re: mutex in frame code

[Richard Earnshaw]

> 
> > and that these three options be documented machine independently 
> > (specific values of course will be machine dependent).
> 
> I agree with the idea of working towards having all the ports
> have similar meanings for the -mcpu, -mtune, and -march flags,
> but I disagree with the idea of documenting these flags as if
> they were machine independent.  There may be good reason for
> a particular port to have a different meaning for these options,
> either for the time being, or permanantly.  Documenting these
> options as machine independent either forces port maintainers
> to follow the documented behavior even when it doesnt make sense
> for a paticular port, or it means that the doc isn't correct 
> for all ports.  Leaving the exact meaning of these options
> machine dependent, while encouraging ports to follow the overall
> standard, gives port maintainers the freedom to make the right
> decision for a paticular port.
> 

I can't think of anything worse than -mcpu= meaning one thing when 
compiling on MIPS and a completely different thing when compiling on 
SPARC.  I'm in favour of unifying the definition (and of using the 3 
options proposed).

> If you really want machine independent options for these things,
> and I'm not opposed to such a thing, then you should actually 
> create some machine independent options (say --tune=, --arch=, 
> and --cpu=) in the usual way.
> 

I've no problem with this, but if we go this way, I think we need to 
completely expunge the -m{cpu,tune,arch} options immediately.   Some of 
the ARM ports SPEC flags are complicated enough, without having to support 
two sets of options which mean the same thing.

Richard.

Re: mutex in frame code

[Richard Earnshaw]

> 
> > and that these three options be documented machine independently 
> > (specific values of course will be machine dependent).
> 
> I agree with the idea of working towards having all the ports
> have similar meanings for the -mcpu, -mtune, and -march flags,
> but I disagree with the idea of documenting these flags as if
> they were machine independent.  There may be good reason for
> a particular port to have a different meaning for these options,
> either for the time being, or permanantly.  Documenting these
> options as machine independent either forces port maintainers
> to follow the documented behavior even when it doesnt make sense
> for a paticular port, or it means that the doc isn't correct 
> for all ports.  Leaving the exact meaning of these options
> machine dependent, while encouraging ports to follow the overall
> standard, gives port maintainers the freedom to make the right
> decision for a paticular port.
> 

I can't think of anything worse than -mcpu= meaning one thing when 
compiling on MIPS and a completely different thing when compiling on 
SPARC.  I'm in favour of unifying the definition (and of using the 3 
options proposed).

> If you really want machine independent options for these things,
> and I'm not opposed to such a thing, then you should actually 
> create some machine independent options (say --tune=, --arch=, 
> and --cpu=) in the usual way.
> 

I've no problem with this, but if we go this way, I think we need to 
completely expunge the -m{cpu,tune,arch} options immediately.   Some of 
the ARM ports SPEC flags are complicated enough, without having to support 
two sets of options which mean the same thing.

Richard.

Re: mutex in frame code

[Gavin Romig-Koch]

> and that these three options be documented machine independently 
> (specific values of course will be machine dependent).

I agree with the idea of working towards having all the ports
have similar meanings for the -mcpu, -mtune, and -march flags,
but I disagree with the idea of documenting these flags as if
they were machine independent.  There may be good reason for
a particular port to have a different meaning for these options,
either for the time being, or permanantly.  Documenting these
options as machine independent either forces port maintainers
to follow the documented behavior even when it doesnt make sense
for a paticular port, or it means that the doc isn't correct 
for all ports.  Leaving the exact meaning of these options
machine dependent, while encouraging ports to follow the overall
standard, gives port maintainers the freedom to make the right
decision for a paticular port.

If you really want machine independent options for these things,
and I'm not opposed to such a thing, then you should actually 
create some machine independent options (say --tune=, --arch=, 
and --cpu=) in the usual way.

                                          -gavin...

Re: mutex in frame code

[Mike Stump]

> Date: Tue, 02 Feb 1999 13:04:20 -0500
> From: David Edelsohn <dje@watson.ibm.com>

> I am voting that we implement all three consistently across all
> ports.

David and I agree.  Does anyone disagree?  If so, why?  Specifically,
we are talking about changing the x86 and mips ports to fall in line
with _all_ the other ports, and that these three options be documented
machine independently (specific values of course will be machine
dependent).  Did I miss any ports?

-mcpu=486 I propose will be the same as -march=486 -mtune=486, I don't
believe it means that now, but I think it means -march=386 -mtune=486
currently.