Difference between revisions of "WhatsWrongWithO32N32N64"

From LinuxMIPS
Jump to: navigation, search
Line 9: Line 9:
 
* n32/n64 are for 64-bit CPUs only.  n64 has 64-bit pointers and long integers, whereas n32 has 32-bit pointers and long integers.  (Other than that they're pretty much the same and will be considered together).  
 
* n32/n64 are for 64-bit CPUs only.  n64 has 64-bit pointers and long integers, whereas n32 has 32-bit pointers and long integers.  (Other than that they're pretty much the same and will be considered together).  
  
o32 is fairly different from n32/n64, so let's take them separately.
+
o32 is fairly different from n32/n64, so we'll pull out individual problems in separate sections.
 +
 
 +
=== What's wrong with all of them? ===
 +
 
 +
* Inefficient PIC code is resistant to optimisation.
 +
 
 +
* No general-purpose register available as a thread pointer for efficient thread-local storage.
 +
 
 +
* Not enough "saved" ("callee-saved") registers, limiting its ability to keep variables in registers.
 +
 
 +
* The calling and register conventions make it very hard to build gaskets to allow 32-bit code to intercall 64-bit code.  MIPS Technologies thinks such gaskets will be critical in allowing embedded systems builders to make the transition to using real 64-bit code.
  
 
=== What's wrong with o32? ===
 
=== What's wrong with o32? ===
 +
 +
o32 has been an orphan for a long time.  Somewhere in the mid-1990s SGI dropped it completely, because all their systems had been using real 64-bit CPUs for some time.
 +
 +
* Committed to the obsolete [[MIPS1FPU|MIPS I floating point]] model, which hides 16 of the FP registers.
 +
 +
* Only four argument registers, which means arguments are too often passed on the stack.
 +
 +
* Many recent improvements are undocumented: DWARF debug format, for example.  So a great deal of undocumented folklore is required to build a compatible implementation.  In practice, few implementations are compatible at debug level, and many are incompatible even for interlinking object code.
  
 
=== What's wrong with n32/n64? ===
 
=== What's wrong with n32/n64? ===
 +
 +
* Non-SGI use is really an uneasy subset of n64.  The real thing would probably break GNU tools.  The adequate subset is undocumented.  There are dozens of ill-documented object code section types etc.
 +
 +
* n32/n64 have only ever been Irix/Linux standards.  There's no established "bare-iron" version of the object code.
 +
 +
* n32/n64 are annoyingly different from each other for reasons which made sense at the time.
 +
 +
* n64 as defined by SGI used their own (early, unique) extensions to DWARF debug information.

Revision as of 13:15, 28 September 2005

What's wrong with o32, n32 and n64?

Linux/MIPS (up to now, Autumn 2005) has made progress using recognisable dialects of standards defined originally by MIPS Corporation and SGI:

  • o32 is for 32-bit CPUs, or 64-bit CPUs running only a 32-bit subset of the instruction set.
  • n32/n64 are for 64-bit CPUs only. n64 has 64-bit pointers and long integers, whereas n32 has 32-bit pointers and long integers. (Other than that they're pretty much the same and will be considered together).

o32 is fairly different from n32/n64, so we'll pull out individual problems in separate sections.

What's wrong with all of them?

  • Inefficient PIC code is resistant to optimisation.
  • No general-purpose register available as a thread pointer for efficient thread-local storage.
  • Not enough "saved" ("callee-saved") registers, limiting its ability to keep variables in registers.
  • The calling and register conventions make it very hard to build gaskets to allow 32-bit code to intercall 64-bit code. MIPS Technologies thinks such gaskets will be critical in allowing embedded systems builders to make the transition to using real 64-bit code.

What's wrong with o32?

o32 has been an orphan for a long time. Somewhere in the mid-1990s SGI dropped it completely, because all their systems had been using real 64-bit CPUs for some time.

  • Only four argument registers, which means arguments are too often passed on the stack.
  • Many recent improvements are undocumented: DWARF debug format, for example. So a great deal of undocumented folklore is required to build a compatible implementation. In practice, few implementations are compatible at debug level, and many are incompatible even for interlinking object code.

What's wrong with n32/n64?

  • Non-SGI use is really an uneasy subset of n64. The real thing would probably break GNU tools. The adequate subset is undocumented. There are dozens of ill-documented object code section types etc.
  • n32/n64 have only ever been Irix/Linux standards. There's no established "bare-iron" version of the object code.
  • n32/n64 are annoyingly different from each other for reasons which made sense at the time.
  • n64 as defined by SGI used their own (early, unique) extensions to DWARF debug information.