-mcpu vs. binutils 2.13.90.0.18

-mcpu vs. binutils 2.13.90.0.18

[Guido Guenther]

Hi,
it seems newer binutils doen't know about -mcpu anymore. Is it correct
to simply change:
 -mcpu=r5000 -mips2 -Wa,--trap
to
 -mtune=r5000 -mips2 -Wa,--trap
for IP22? -mips2 conflicts with -march=r5000 since this implies -mips4.
Regards,
 -- Guido

Re: -mcpu vs. binutils 2.13.90.0.18

[Thiemo Seufer]

Guido Guenther wrote:
> Hi,
> it seems newer binutils doen't know about -mcpu anymore. Is it correct
> to simply change:
>  -mcpu=r5000 -mips2 -Wa,--trap
> to
>  -mtune=r5000 -mips2 -Wa,--trap

On newer toolchains this will select r6000 opcodes with r5000 scheduling.

Try
   -mabi=o32 -march=r5000 -Wa,--trap
This may fail if the compiler is very old, though.

> for IP22? -mips2 conflicts with -march=r5000 since this implies -mips4.

This was fixed in very recent gcc. -mips2 should be an alias for -march=r6000
and -mips4 one for -march=r8000.


Thiemo

Re: -mcpu vs. binutils 2.13.90.0.18

[Guido Guenther]

On Tue, Mar 18, 2003 at 05:03:03PM +0100, Thiemo Seufer wrote:
> Try
>    -mabi=o32 -march=r5000 -Wa,--trap
> This may fail if the compiler is very old, though.
> 
> > for IP22? -mips2 conflicts with -march=r5000 since this implies -mips4.
> 
> This was fixed in very recent gcc. -mips2 should be an alias for -march=r6000
> and -mips4 one for -march=r8000.
Is it correct that -mipsX in contrast to -march=rXXXX has the difference
of not only selecting a specific CPU instruction set but also an abi
(o32 or n64)? If so wouldn't it be cleaner to remove -mipsX altogether
and use -march=rXXXX and -mabi=o32, etc? The different meanings of these
options in different toolchain versions confuse me a lot. What is the
final intended usage of these options?
 -- Guido

Re: -mcpu vs. binutils 2.13.90.0.18

[Thiemo Seufer]

Guido Guenther wrote:
> On Tue, Mar 18, 2003 at 05:03:03PM +0100, Thiemo Seufer wrote:
> > Try
> >    -mabi=o32 -march=r5000 -Wa,--trap
> > This may fail if the compiler is very old, though.
> > 
> > > for IP22? -mips2 conflicts with -march=r5000 since this implies -mips4.
> > 
> > This was fixed in very recent gcc. -mips2 should be an alias for -march=r6000
> > and -mips4 one for -march=r8000.
> Is it correct that -mipsX in contrast to -march=rXXXX has the difference
> of not only selecting a specific CPU instruction set but also an abi
> (o32 or n64)?

Only for old compilers, an only for some cases. :-/

-mipsX is the old method for selecting both CPU and ABI, resembling the way
SGI did it for their toolchain. Then there was the need to support different
CPUs, which led to -mcpu/-mXXXX. The result was an inconsistent mess,
especially -mips2 has multiple overloaded semantics.

> If so wouldn't it be cleaner to remove -mipsX altogether
> and use -march=rXXXX and -mabi=o32, etc?

This would be nice, but older compilers don't have -march/-mtune.
IIRC gcc 3.0.X is the first one to employ these. Similiar for -mabi.

> The different meanings of these
> options in different toolchain versions confuse me a lot. What is the
> final intended usage of these options?

For usual userland the ABI defines everything needed. This means

No options at all:
Produce, hosted on a single ABI system, a userland binary with the lowest
possible ISA.

-mabi=FOO: 
Produce, hosted on a multi ABI system, a userland binary with the lowest
possible ISA for the selected ABI.

Then there are optimizations for different CPUs.

-march=BAR:
Allow opcodes for CPU BAR in addition to the ISA ones.

-mtune=BAZ:
Optimize opcode scheduling for CPU BAZ.

Some embedded systems don't care much about ABI compatibility, they
use also

-mgp32/-mfp32:
Restrict register width to 32 bits on 64 bit CPUs.

Then, there are the backward compatibility options.

-mipsX:
Is an alias for -march=QUUX, where QUUX is the CPU closest to the respective
ISA. Note that this is only backward compatible for the assembler, not for
the compiler which implied some o32 features for -mips2.

-mcpu=XXX, -mYYYY:
Old CPU selection code, mostly gone now. Superseded by -march/-mtune.


For my private linux kernels, I use a new CONFIG_MIPS_NEW_TOOLCHAIN in the
Makefile. I don't see a better way around it.


Thiemo

Re: -mcpu vs. binutils 2.13.90.0.18

[Guido Guenther]

Hi Thiemo,
thanks a lot for the explanations!

On Tue, Mar 18, 2003 at 08:08:41PM +0100, Thiemo Seufer wrote:
> This would be nice, but older compilers don't have -march/-mtune.
> IIRC gcc 3.0.X is the first one to employ these. Similiar for -mabi.
I don't care about old compilers at the moment ;)

[..snip..] 
> -mabi=FOO: 
> Produce, hosted on a multi ABI system, a userland binary with the lowest
> possible ISA for the selected ABI.
> 
> Then there are optimizations for different CPUs.
> 
> -march=BAR:
> Allow opcodes for CPU BAR in addition to the ISA ones.
> 
> -mtune=BAZ:
> Optimize opcode scheduling for CPU BAZ.
So to build kernels for say IP22 R5k I'd change the current
	GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap
to 
	GCCFLAGS += -mabi=o32 -march=R5000 -mtune=R5000 -Wa,--trap
where as for R4X00 I use
	GCCFLAGS += -mabi=o32 -march=R4600 -mtune=R4600 -Wa,--trap
Correct?
 -- Guido

Re: -mcpu vs. binutils 2.13.90.0.18

[Thiemo Seufer]

Guido Guenther wrote:
[snip]
> > -march=BAR:
> > Allow opcodes for CPU BAR in addition to the ISA ones.
> > 
> > -mtune=BAZ:
> > Optimize opcode scheduling for CPU BAZ.
> So to build kernels for say IP22 R5k I'd change the current
> 	GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap
> to 
> 	GCCFLAGS += -mabi=o32 -march=R5000 -mtune=R5000 -Wa,--trap
> where as for R4X00 I use
> 	GCCFLAGS += -mabi=o32 -march=R4600 -mtune=R4600 -Wa,--trap
> Correct?

Yes, this should work. You can leave the -mtune out, since it defaults
to the value of -march anyway.


Thiemo

Re: -mcpu vs. binutils 2.13.90.0.18

[Guido Guenther]

On Wed, Mar 19, 2003 at 01:16:52AM +0100, Thiemo Seufer wrote:
> Yes, this should work. You can leave the -mtune out, since it defaults
> to the value of -march anyway.
Thanks.
 -- Guido

Re: -mcpu vs. binutils 2.13.90.0.18

[Maciej W. Rozycki]

On Tue, 18 Mar 2003, Thiemo Seufer wrote:

> For my private linux kernels, I use a new CONFIG_MIPS_NEW_TOOLCHAIN in the
> Makefile. I don't see a better way around it.

 An automatic selection between new-style and old-style gcc options is on
my to-do list.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: -mcpu vs. binutils 2.13.90.0.18

[Guido Guenther]

On Wed, Mar 19, 2003 at 01:16:52AM +0100, Thiemo Seufer wrote:
> Guido Guenther wrote:
> [snip]
> > > -march=BAR:
> > > Allow opcodes for CPU BAR in addition to the ISA ones.
> > > 
> > > -mtune=BAZ:
> > > Optimize opcode scheduling for CPU BAZ.
> > So to build kernels for say IP22 R5k I'd change the current
> > 	GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap
> > to 
> > 	GCCFLAGS += -mabi=o32 -march=R5000 -mtune=R5000 -Wa,--trap
> > where as for R4X00 I use
> > 	GCCFLAGS += -mabi=o32 -march=R4600 -mtune=R4600 -Wa,--trap
> > Correct?
> 
> Yes, this should work. You can leave the -mtune out, since it defaults
> to the value of -march anyway.
Just for completeness: I had to use:
	GCCFLAGS += -mabi=32 -march=r4600 -mtune=r4600 -Wa,--trap
to make gcc-3.3 happy (note the 32 instead of o32). gcc-3.2 doesn't seem
to handle these options correctly at all.
 -- Guido

Re: -mcpu vs. binutils 2.13.90.0.18

[Thiemo Seufer]

Guido Guenther wrote:
[snip]
> > > So to build kernels for say IP22 R5k I'd change the current
> > > 	GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap
> > > to 
> > > 	GCCFLAGS += -mabi=o32 -march=R5000 -mtune=R5000 -Wa,--trap
> > > where as for R4X00 I use
> > > 	GCCFLAGS += -mabi=o32 -march=R4600 -mtune=R4600 -Wa,--trap
> > > Correct?
> > 
> > Yes, this should work. You can leave the -mtune out, since it defaults
> > to the value of -march anyway.
> Just for completeness: I had to use:
> 	GCCFLAGS += -mabi=32 -march=r4600 -mtune=r4600 -Wa,--trap
> to make gcc-3.3 happy (note the 32 instead of o32).

Yes, IIRC 64 vs. n64 has the same problem.

> gcc-3.2 doesn't seem
> to handle these options correctly at all.

AFAICS you can still drop the -mtune part.


Thiemo

Re: -mcpu vs. binutils 2.13.90.0.18

[Daniel Jacobowitz]

On Tue, May 13, 2003 at 09:27:35PM +0200, Thiemo Seufer wrote:
> Guido Guenther wrote:
> [snip]
> > > > So to build kernels for say IP22 R5k I'd change the current
> > > > 	GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap
> > > > to 
> > > > 	GCCFLAGS += -mabi=o32 -march=R5000 -mtune=R5000 -Wa,--trap
> > > > where as for R4X00 I use
> > > > 	GCCFLAGS += -mabi=o32 -march=R4600 -mtune=R4600 -Wa,--trap
> > > > Correct?
> > > 
> > > Yes, this should work. You can leave the -mtune out, since it defaults
> > > to the value of -march anyway.
> > Just for completeness: I had to use:
> > 	GCCFLAGS += -mabi=32 -march=r4600 -mtune=r4600 -Wa,--trap
> > to make gcc-3.3 happy (note the 32 instead of o32).
> 
> Yes, IIRC 64 vs. n64 has the same problem.

That's not quite the same: 64 is o64, n64 is n64.  GCC's never called
the 32-bit ABI "o32".

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: -mcpu vs. binutils 2.13.90.0.18

[Thiemo Seufer]

Daniel Jacobowitz wrote:
[snip]
> > > Just for completeness: I had to use:
> > > 	GCCFLAGS += -mabi=32 -march=r4600 -mtune=r4600 -Wa,--trap
> > > to make gcc-3.3 happy (note the 32 instead of o32).
> > 
> > Yes, IIRC 64 vs. n64 has the same problem.
> 
> That's not quite the same: 64 is o64, n64 is n64.

I don't think so (There's -mabi=o64).
Otherwise I would have built all my NewABI 64bit Executables as
o64 without noticing ever. :-)

> GCC's never called the 32-bit ABI "o32".

True, but it might be clearer if it did.


Thiemo

Re: -mcpu vs. binutils 2.13.90.0.18

[Guido Guenther]

On Tue, May 13, 2003 at 09:27:35PM +0200, Thiemo Seufer wrote:
> Guido Guenther wrote:
[..snip..] 
> > to make gcc-3.3 happy (note the 32 instead of o32).
> 
> Yes, IIRC 64 vs. n64 has the same problem.
I think 64 is o64 not n64.

> > gcc-3.2 doesn't seem
> > to handle these options correctly at all.
> 
> AFAICS you can still drop the -mtune part.
Yes, thanks for pointing this out. I'm just leaving this in the Makefile
to know what to change if I want to tune for another cpu.
 -- Guido

Re: -mcpu vs. binutils 2.13.90.0.18

[Thiemo Seufer]

Guido Guenther wrote:
> On Tue, May 13, 2003 at 09:27:35PM +0200, Thiemo Seufer wrote:
> > Guido Guenther wrote:
> [..snip..] 
> > > to make gcc-3.3 happy (note the 32 instead of o32).
> > 
> > Yes, IIRC 64 vs. n64 has the same problem.
> I think 64 is o64 not n64.

Strange, you are now the second to say so. Where does this idea stem from?

I just had a look at the gcc sources, the mips*-linux config doesn't
support o64 at all.


Thiemo

Re: -mcpu vs. binutils 2.13.90.0.18

[Guido Guenther]

On Tue, May 13, 2003 at 10:50:21PM +0200, Thiemo Seufer wrote:
> I just had a look at the gcc sources, the mips*-linux config doesn't
> support o64 at all.
It seems I was wrong (I got confused by the way the kernel calls gcc).
Looking at gcc-3.3:

#define ABI_32  0
#define ABI_N32 1
#define ABI_64  2
#define ABI_EABI 3
#define ABI_O64  4

The naming is very "unfortunate", though. We have (n32,64) and (32,o64).
Wouldn't it help to at least allow for n64 and o32 commandline options?
-mabi=32 and -mabi=64 will have to be kept for Irix compatibility
though, I think.
 -- Guido

Re: -mcpu vs. binutils 2.13.90.0.18

[Maciej W. Rozycki]

On Wed, 14 May 2003, Guido Guenther wrote:

> Looking at gcc-3.3:
> 
> #define ABI_32  0
> #define ABI_N32 1
> #define ABI_64  2
> #define ABI_EABI 3
> #define ABI_O64  4
> 
> The naming is very "unfortunate", though. We have (n32,64) and (32,o64).
> Wouldn't it help to at least allow for n64 and o32 commandline options?
> -mabi=32 and -mabi=64 will have to be kept for Irix compatibility
> though, I think.

 Why unfortunate?  You use "32" and "64" for normal stuff, and the rest
for special cases ("n32" isn't really 32-bit and "o64" isn't really 64-bit
-- both lie in the middle).  Additional aliases of the "n64" and "o32"
form would make more confusion, IMHO. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: -mcpu vs. binutils 2.13.90.0.18

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Wed, 14 May 2003, Guido Guenther wrote:
> 
> > Looking at gcc-3.3:
> > 
> > #define ABI_32  0
> > #define ABI_N32 1
> > #define ABI_64  2
> > #define ABI_EABI 3
> > #define ABI_O64  4
> > 
> > The naming is very "unfortunate", though. We have (n32,64) and (32,o64).
> > Wouldn't it help to at least allow for n64 and o32 commandline options?
> > -mabi=32 and -mabi=64 will have to be kept for Irix compatibility
> > though, I think.
> 
>  Why unfortunate?  You use "32" and "64" for normal stuff, and the rest
> for special cases ("n32" isn't really 32-bit and "o64" isn't really 64-bit
> -- both lie in the middle).

Exactly this is the sort of confusion which makes the naming unfortunate.
-32 and -64 had never much to do with 32/64 bit but designate ABIs.

> Additional aliases of the "n64" and "o32"
> form would make more confusion, IMHO. 

I disagree.


Thiemo

Re: -mcpu vs. binutils 2.13.90.0.18

[Maciej W. Rozycki]

On Wed, 14 May 2003, Thiemo Seufer wrote:

> >  Why unfortunate?  You use "32" and "64" for normal stuff, and the rest
> > for special cases ("n32" isn't really 32-bit and "o64" isn't really 64-bit
> > -- both lie in the middle).
> 
> Exactly this is the sort of confusion which makes the naming unfortunate.
> -32 and -64 had never much to do with 32/64 bit but designate ABIs.

 Well, "32" is 32-bit address/data and "64" is 64-bit address/data. 
That's essentially pure 32-bit and 64-bit, respectively.  Of course some
data format has to be emitted by tools, so there has to be an ABI
associated with each of these variants. 

 And "n32" and "o64" are 32-bit address/64-bit data -- you can use 64-bit
data, e.g. in gas, but you cannot use 64-bit addressing, e.g. a
section/segment cannot be bigger than 4 GB. 

 The naming isn't consistent, indeed -- there could be, say:

- "32" for 32-bit support -- unambiguous, since there is only one
variation,

- "64" for 64-bit support -- requiring an additional option for selecting
the ABI, bailing out without one (or defaulting to a preconfigured ABI).

 Alternatively, there could be no "32" option -- tools configured for
"mips" would only emit 32-bit binaries and tools configured for "mips64" 
-- 64-bit and mixed ones, depending on one of the "64", "o64" and "n32"
options. 

 Of course all options could be renamed to avoid confusion.

> > Additional aliases of the "n64" and "o32"
> > form would make more confusion, IMHO. 
> 
> I disagree.

 I won't insist -- if people find this suitable for them, then it's great.
I won't use these additional aliases, so that's irrelevant for me.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: -mcpu vs. binutils 2.13.90.0.18

[Thiemo Seufer]

Maciej W. Rozycki wrote:
[snip]
> On Wed, 14 May 2003, Thiemo Seufer wrote:
> 
> > >  Why unfortunate?  You use "32" and "64" for normal stuff, and the rest
> > > for special cases ("n32" isn't really 32-bit and "o64" isn't really 64-bit
> > > -- both lie in the middle).
> > 
> > Exactly this is the sort of confusion which makes the naming unfortunate.
> > -32 and -64 had never much to do with 32/64 bit but designate ABIs.
> 
>  Well, "32" is 32-bit address/data and "64" is 64-bit address/data. 
> That's essentially pure 32-bit and 64-bit, respectively.  Of course some
> data format has to be emitted by tools, so there has to be an ABI
> associated with each of these variants. 

That's just backwards. An ABI defines much more, e.g. calling
conventions and GOT sizes. The register size is just another
property of the ABI.

> And "n32" and "o64" are 32-bit address/64-bit data -- you can use 64-bit
> data, e.g. in gas, but you cannot use 64-bit addressing, e.g. a
> section/segment cannot be bigger than 4 GB. 
> 
>  The naming isn't consistent, indeed -- there could be, say:
> 
> - "32" for 32-bit support -- unambiguous, since there is only one
> variation,

This assumption fails if there will ever be an improved 32bit ABI with
e.g. NewABI calling conventions, as the MEABI tried some time ago.

> - "64" for 64-bit support -- requiring an additional option for selecting
> the ABI, bailing out without one (or defaulting to a preconfigured ABI).

Argh! Once again, the _ABI_ defines if it supports 64bit. For an
ABI-compliant system, there's no point in having a register-size
selection option.

>  Alternatively, there could be no "32" option -- tools configured for
> "mips" would only emit 32-bit binaries

What is a "32-bit binary"? o32, EABI, MEABI or another
yet-to-be-invented one?

> and tools configured for "mips64" 
> -- 64-bit and mixed ones, depending on one of the "64", "o64" and "n32"
> options. 

What's desireable here depends on the target system. For Linux,
the current way is IMHO the best: o32 only for mips-linux, and
o32, n32 and n64 for mips64-linux, with n32 as default.
o64 isn't useful for Linux, and only interesting for backward
compatibility elsewhere.


Thiemo

Re: -mcpu vs. binutils 2.13.90.0.18

[Maciej W. Rozycki]

On Wed, 14 May 2003, Thiemo Seufer wrote:

> >  Well, "32" is 32-bit address/data and "64" is 64-bit address/data. 
> > That's essentially pure 32-bit and 64-bit, respectively.  Of course some
> > data format has to be emitted by tools, so there has to be an ABI
> > associated with each of these variants. 
> 
> That's just backwards. An ABI defines much more, e.g. calling
> conventions and GOT sizes. The register size is just another
> property of the ABI.

 OK -- maybe I am biased because there is only a single ABI for 32-bit and
64-bit binaries each.  So please just forget it.

> What's desireable here depends on the target system. For Linux,
> the current way is IMHO the best: o32 only for mips-linux, and
> o32, n32 and n64 for mips64-linux, with n32 as default.

 Of course the choice of the default should be configurable (for binutils
it probably already is -- I recall Richard Sandiford making changes in
this area, for gcc -- no idea).

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: -mcpu vs. binutils 2.13.90.0.18

[Thiemo Seufer]

Maciej W. Rozycki wrote:
[snip]
> > What's desireable here depends on the target system. For Linux,
> > the current way is IMHO the best: o32 only for mips-linux, and
> > o32, n32 and n64 for mips64-linux, with n32 as default.
> 
>  Of course the choice of the default should be configurable (for binutils
> it probably already is

It isn't, and probably will never be. Of course you could introduce
just another configuration, with the bfd vector of your choice as
default.

> -- I recall Richard Sandiford making changes in
> this area, for gcc -- no idea).

It would also need a different config which defines a different
MIPS_DEFAULT_ABI.


Thiemo

Re: -mcpu vs. binutils 2.13.90.0.18

[Daniel Jacobowitz]

On Tue, May 13, 2003 at 09:59:28PM +0200, Thiemo Seufer wrote:
> Daniel Jacobowitz wrote:
> [snip]
> > > > Just for completeness: I had to use:
> > > > 	GCCFLAGS += -mabi=32 -march=r4600 -mtune=r4600 -Wa,--trap
> > > > to make gcc-3.3 happy (note the 32 instead of o32).
> > > 
> > > Yes, IIRC 64 vs. n64 has the same problem.
> > 
> > That's not quite the same: 64 is o64, n64 is n64.
> 
> I don't think so (There's -mabi=o64).
> Otherwise I would have built all my NewABI 64bit Executables as
> o64 without noticing ever. :-)

You are, of course, right :)

> > GCC's never called the 32-bit ABI "o32".
> 
> True, but it might be clearer if it did.

I suppose... too late now.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: -mcpu vs. binutils 2.13.90.0.18

[Maciej W. Rozycki]

On Wed, 14 May 2003, Thiemo Seufer wrote:

> >  Of course the choice of the default should be configurable (for binutils
> > it probably already is
> 
> It isn't, and probably will never be. Of course you could introduce
> just another configuration, with the bfd vector of your choice as
> default.

 Hmm, I would assume "mipsn32*-linux" defaults to n32 and "mips64*-linux" 
-- to (n)64.  It isn't the case, indeed.

> > -- I recall Richard Sandiford making changes in
> > this area, for gcc -- no idea).
> 
> It would also need a different config which defines a different
> MIPS_DEFAULT_ABI.

 I will do the change as described above when I am working on mips64
glibc.  Also config.guess will probably have to be updated to be capable
to determine which one of these two configurations is used in a given
system, so that one need not specify "--build=" to get what is desired.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: -mcpu vs. binutils 2.13.90.0.18

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Wed, 14 May 2003, Thiemo Seufer wrote:
> 
> > >  Of course the choice of the default should be configurable (for binutils
> > > it probably already is
> > 
> > It isn't, and probably will never be. Of course you could introduce
> > just another configuration, with the bfd vector of your choice as
> > default.
> 
>  Hmm, I would assume "mipsn32*-linux" defaults to n32 and "mips64*-linux" 
> -- to (n)64.  It isn't the case, indeed.

IMHO it's not particularily useful to have both of these. I assume a n64
capable system will always implement n32 also, for better performance
and less memory consumption, and the majority of applications will run
as n32. IOW, there's little need for a n64-defaulting configuration.

But IIRC we disagree about this point.


Thiemo

Re: -mcpu vs. binutils 2.13.90.0.18

[Maciej W. Rozycki]

On Thu, 15 May 2003, Thiemo Seufer wrote:

> >  Hmm, I would assume "mipsn32*-linux" defaults to n32 and "mips64*-linux" 
> > -- to (n)64.  It isn't the case, indeed.
> 
> IMHO it's not particularily useful to have both of these. I assume a n64
> capable system will always implement n32 also, for better performance
> and less memory consumption, and the majority of applications will run
> as n32. IOW, there's little need for a n64-defaulting configuration.
> 
> But IIRC we disagree about this point.

 It's not about whether we agree or not -- it's about letting a user make
a choice what suits him better.  We need not force anyone to accept our
points of view -- it's one of the main advantages of free software. 

 Also I would like to allow glibc to be configured without n32 and won't
object disallowing (n)64 alternatively.  I already run kernels that
support o32 and (n)64 only (o32 is temporary, of course, until glibc
supports (n)64), so it's not true an (n)64-capable system always supports
n32. 

 BTW, you may want a program to be built as (n)64 whenever it uses mmap() 
and can operate on the so called "large files".  So there may be
significantly more programs requiring the (n)64 format than it may seem at
the first thought. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +