Re: [gentoo-dev] fhs and multilib question

[Joshua Kinard]

On 09/11/2011 17:47, Michał Górny wrote:

> Looks like n32 is less '32' than o32 so a little weird classification
> but I guess historical reasons.


In a way, yeah.  The gory details are in the N32 ABI guide here, if your
curiosity is morbid enough:
ftp://ftp.linux-mips.org/pub/linux/mips/doc/ABI2/MIPS-N32-ABI-Handbook.pdf

To quote a small excerpt from that:

-------------
Limitations of the 32-bit ABI

The 32-bit ABI was designed essentially for the R3000. It cannot be extended
to use new performance-related features and instructions of the R4400 and
beyond. For example:

   * 16 of the 32 floating point registers cannot be used.
   * 64-bit arithmetic instructions cannot be used.
   * 64-bit data movement instructions cannot be used.
   * MIPS4/R8000 instructions cannot be used.

Because of this, the performance available from the chip is lost. Floating
point intensive programs are especially hurt by these limitations; indeed
some are 50%-100% slower!


Limitations of the 64-bit ABI

Although the 64-bit ABI exploits many performance-related features of the
MIPS architecture, it also has problems. These include the following:
   * Porting code from the 32-bit ABI to the 64-bit ABI typically
     requires some recoding.
   * When ported from the 32-bit ABI to the 64-bit ABI, some C programs
     get significantly larger.


Motivation for the N32 ABI

Many ISVs and customers are finding it difficult to port to the 64-bit ABI.
An ABI was needed with all of the performance advantages of the 64-bit ABI,
but with the same data type sizes as the 32-bit ABI to allow ease of porting.
-------------

And to add to that, "N32 uses 64-bit registers but restricts addresses to 32
bits."

So we sometimes refer to it as a hybrid ABI, because it's in between the
32-bit and 64-bit worlds.  It actually requires a 64-bit compiler (either an
n32 mips64[el]-* OR n64mips64[el]-* toolchain) to even generate the code.

And it drove the glibc developers, especially Ulrich, absolutely insane.
One of the bigger reasons why non-x86 glibc code was spun off into -ports
several years ago, so they could speed up the glibc release cycle.


To give you an idea of the age of the n32 and o32 ABIs, IRIX 5.x (and IRIX
6.0) was the latest IRIX release to use o32.  All releases under IRIX 6.1
and up were n32.  And IRIX 6.1 came out some time after 1994, probably in
1995 (IRIX 6.5, the last branch, didn't start until 1998).  So Linux support
for n32 has been literal eons in the making.  It is seriously old school
stuff here.  I was just starting middle school when n32 became standard.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@g.o
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic