Re: -mcpu vs. binutils 2.13.90.0.18

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux