WhatsWrongWithO32N32N64 - Revision history

Mattst88: add to ABI category so people can actually find this page

2010-01-07T03:18:23Z

add to ABI category so people can actually find this page

2008-01-18T13:12:20Z

Make "PIC code" a wiki link

2005-09-29T16:51:10Z

2005-09-28T20:52:55Z

‎What's wrong with o32, n32 and n64?

2005-09-28T16:06:40Z

‎What's wrong with o32, n32 and n64?

2005-09-28T16:05:50Z

‎What's wrong with n32/n64?

2005-09-28T16:04:06Z

‎What's wrong with n32/n64?

2005-09-28T16:02:25Z

‎What's wrong with n32/n64?

2005-09-28T16:01:03Z

‎What's wrong with o32?

2005-09-28T16:00:36Z

‎What's wrong with o32?

← Older revision		Revision as of 03:18, 7 January 2010
Line 48:		Line 48:

	This seems to be a plausible approach. Currently, MIPS Technologies incline to the view that it would be horrible to do this work and end up with wholly incompatible 32- and 64-bit ABIs, so to do this we'd have to make NUBI32 something like "n64 but 32-bit".		This seems to be a plausible approach. Currently, MIPS Technologies incline to the view that it would be horrible to do this work and end up with wholly incompatible 32- and 64-bit ABIs, so to do this we'd have to make NUBI32 something like "n64 but 32-bit".
		+
		+	[[Category:ABI]]

@@ Line 15: / Line 15: @@
 === What's wrong with all of them? ===
-* Inefficient PIC code is resistant to optimisation.
+* Inefficient [[PIC code]] is resistant to optimisation.
 * No general-purpose register available as a thread pointer for efficient thread-local storage.

@@ Line 43: / Line 43: @@
 * n64 as defined by SGI used their own (early, unique) extensions to DWARF debug information.
-* n32/n64 are annoyingly different from each other for reasons which probably made sense at the time, but certainly don't now.
+* n32/n64 are annoyingly different from each other for reasons which probably made sense at the time, but certainly don't now.  That last bullet point has led to some people asking "[[TheCaseForN32|do we need n32 (or equivalent) at all]]?"
-That last bullet point has led to some people asking "[[TheCaseForN32|do we need n32 (or equivalent) at all]]?"
+=== Why not keep n64 but replace o32? ===

← Older revision		Revision as of 20:52, 28 September 2005
Line 10:		Line 10:

	o32 is fairly different from n32/n64, so we'll pull out individual problems in separate sections. But it's certainly true that o32 is much more obviously troublesome than n64...		o32 is fairly different from n32/n64, so we'll pull out individual problems in separate sections. But it's certainly true that o32 is much more obviously troublesome than n64...
		+
		+	These problems motivated us to propose a new ABI, [[NUBI]].

	=== What's wrong with all of them? ===		=== What's wrong with all of them? ===

@@ 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).
-o32 is fairly different from n32/n64, so we'll pull out individual problems in separate sections.
+o32 is fairly different from n32/n64, so we'll pull out individual problems in separate sections.  But it's certainly true that o32 is much more obviously troublesome than n64...
 === What's wrong with all of them? ===

← Older revision		Revision as of 16:05, 28 September 2005
Line 34:		Line 34:

	* The GNU dialect is probably not quite the same as SGI's, but any differences are undocumented. There are dozens of ill-documented object code section types and other magic numbers.		* The GNU dialect is probably not quite the same as SGI's, but any differences are undocumented. There are dozens of ill-documented object code section types and other magic numbers.
		+
		+	* n64's history (and its fate as the product of pioneering by SGI, who were so early with 64-bit work) has made it complicated and very different from other ABIs. That means an awful lot of effort has been put into making it work as well as it does now with GNU tools and Linux - but that probably also means it will be expensive to maintain going forward.

	* n32/n64 have only ever been Irix/Linux standards. There's no established "bare-iron" version of the object code for embedded use.		* n32/n64 have only ever been Irix/Linux standards. There's no established "bare-iron" version of the object code for embedded use.

← Older revision		Revision as of 16:04, 28 September 2005
Line 41:		Line 41:
	* n32/n64 are annoyingly different from each other for reasons which probably made sense at the time, but certainly don't now.		* n32/n64 are annoyingly different from each other for reasons which probably made sense at the time, but certainly don't now.

−	That last bullet point has led to some people asking:	+	That last bullet point has led to some people asking "[[TheCaseForN32\|do we need n32 (or equivalent) at all]]?"

@@ Line 33: / Line 33: @@
 === 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 GNU dialect is undocumented.  There are dozens of ill-documented object code section types and other magic numbers.
+* The GNU dialect is probably not quite the same as SGI's, but any differences are undocumented.  There are dozens of ill-documented object code section types and other magic numbers.
 * n32/n64 have only ever been Irix/Linux standards.  There's no established "bare-iron" version of the object code for embedded use.

@@ Line 29: / Line 29: @@
 * Only four argument registers, which means arguments are too often passed on the stack.
-* Many recent improvements to the o32 standard as used by GNU tools and Linux 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.
+* Many recent improvements to the o32 standard as used by GNU tools and Linux 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.  Historically, many are incompatible even for interlinking object code.
 === What's wrong with n32/n64? ===