NUBI - Revision history

Ralf: Fix link to MIPS ABI History page.

2012-07-18T10:52:27Z

Fix link to MIPS ABI History page.

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

2010-01-07T03:17:48Z

add to ABI category so people can actually find this page

Nigel: /* Specific Goals for NUBI */

2005-10-05T17:50:52Z

‎Specific Goals for NUBI

Dom: /* Why does the MIPS Architecture need a new ABI? */

2005-09-28T14:30:25Z

‎Why does the MIPS Architecture need a new ABI?

Dom: /* Why does the MIPS Architecture need a new ABI? */

2005-09-28T14:13:41Z

‎Why does the MIPS Architecture need a new ABI?

Dom at 14:01, 28 September 2005

2005-09-28T14:01:33Z

Dom at 13:58, 28 September 2005

2005-09-28T13:58:57Z

Dom: /* Specific Goals for NUBI */

2005-09-28T13:56:34Z

‎Specific Goals for NUBI

Dom: /* Notes */

2005-09-28T13:54:01Z

‎Notes

Dom: /* Specific Goals for NUBI */

2005-09-28T13:53:31Z

‎Specific Goals for NUBI

@@ Line 2: / Line 2: @@
 An ''ABI'' (''Application Binary Interface'', though that hardly helps) is a set of rules governing compiled programs which - if followed - make the programs able to be linked together (for calling and to share data) and to be comprehensible to various useful bits of software - that includes debuggers, the Linux kernel, and run-time loaders.
-Earlier MIPS ABIs were interpreted as machine-specific extensions to the cross-architecture [SVR4]; but the definition of OS services in a unix-like system now falls to POSIX and (specifically) Linux. This specification does not include the machine-indepedent parts of SVR4 ABI by reference or otherwise.  You might like to brush up on your [[MIPSABIHistory|MIPS ABI History]].
+Earlier MIPS ABIs were interpreted as machine-specific extensions to the cross-architecture [SVR4]; but the definition of OS services in a unix-like system now falls to POSIX and (specifically) Linux. This specification does not include the machine-indepedent parts of SVR4 ABI by reference or otherwise.  You might like to brush up on your [[MIPS ABI History]].
 The existing MIPS ABIs were evolved substantially by Silicon Graphics Inc (''SGI'') for various versions of their ''Irix'' OS; they are fairly typical of ABIs for Linux and other sophisticated operating systems. At least to date most MIPS embedded systems have got by using a subset of SGI's complicated ABIs - o32, n32 and n64.  So [[WhatsWrongWithO32N32N64|What's wrong with o32, n32 and n64?]].

← Older revision		Revision as of 03:17, 7 January 2010
Line 19:		Line 19:

	Want to contribute to the discussion? Join the nubi@linux-mips.org [[Net_Resources#Mailing_lists\|mailing list]].		Want to contribute to the discussion? Join the nubi@linux-mips.org [[Net_Resources#Mailing_lists\|mailing list]].
		+
		+	[[Category:ABI]]

← Older revision		Revision as of 17:50, 5 October 2005
Line 17:		Line 17:

	Want to know more? See [[IntroducingNUBI\|Introducing NUBI]].		Want to know more? See [[IntroducingNUBI\|Introducing NUBI]].
		+
		+	Want to contribute to the discussion? Join the nubi@linux-mips.org [[Net_Resources#Mailing_lists\|mailing list]].

← Older revision		Revision as of 14:30, 28 September 2005
Line 5:		Line 5:

	The existing MIPS ABIs were evolved substantially by Silicon Graphics Inc (''SGI'') for various versions of their ''Irix'' OS; they are fairly typical of ABIs for Linux and other sophisticated operating systems. At least to date most MIPS embedded systems have got by using a subset of SGI's complicated ABIs - o32, n32 and n64. So [[WhatsWrongWithO32N32N64\|What's wrong with o32, n32 and n64?]].		The existing MIPS ABIs were evolved substantially by Silicon Graphics Inc (''SGI'') for various versions of their ''Irix'' OS; they are fairly typical of ABIs for Linux and other sophisticated operating systems. At least to date most MIPS embedded systems have got by using a subset of SGI's complicated ABIs - o32, n32 and n64. So [[WhatsWrongWithO32N32N64\|What's wrong with o32, n32 and n64?]].
		+
		+	And [[TheCaseForN32\|do we need anything like n32 at all?]]

	== Specific Goals for NUBI ==		== Specific Goals for NUBI ==

@@ Line 2: / Line 2: @@
 An ''ABI'' (''Application Binary Interface'', though that hardly helps) is a set of rules governing compiled programs which - if followed - make the programs able to be linked together (for calling and to share data) and to be comprehensible to various useful bits of software - that includes debuggers, the Linux kernel, and run-time loaders.
-Earlier MIPS ABIs were interpreted as machine-specific extensions to the cross-architecture [SVR4]; but the definition of OS services in a unix-like system now falls to POSIX and (specifically) Linux. This specification does not include the machine-indepedent parts of SVR4 ABI by reference or otherwise.
+Earlier MIPS ABIs were interpreted as machine-specific extensions to the cross-architecture [SVR4]; but the definition of OS services in a unix-like system now falls to POSIX and (specifically) Linux. This specification does not include the machine-indepedent parts of SVR4 ABI by reference or otherwise.  You might like to brush up on your [[MIPSABIHistory|MIPS ABI History]].
 The existing MIPS ABIs were evolved substantially by Silicon Graphics Inc (''SGI'') for various versions of their ''Irix'' OS; they are fairly typical of ABIs for Linux and other sophisticated operating systems. At least to date most MIPS embedded systems have got by using a subset of SGI's complicated ABIs - o32, n32 and n64.  So [[WhatsWrongWithO32N32N64|What's wrong with o32, n32 and n64?]].
 == Specific Goals for NUBI ==

← Older revision		Revision as of 14:01, 28 September 2005
Line 35:		Line 35:

	Want to know more? See [[IntroducingNUBI\|Introducing NUBI]].		Want to know more? See [[IntroducingNUBI\|Introducing NUBI]].
−	~~== Introducing NUBI ==~~
−	~~We've chosen this name, for now. We intend to improve on o32 with something simpler, but which prefers being trouble-free for the MIPS programming community over ground-breaking innovation.~~
−
−	~~Unfortunately there can't be just one NUBI. We believe there are three basic choices (related to the hardware) which will create NUBI variants, but which it's essential to support:~~
−	* Endianness: big- and little-endian programs are wholly incompatible. However, with some care this document covers both. When we need to distinguish them we'll use a suffix ''L'' or ''B'' for little/big-endian.
−	* Use of 64-bit integer instructions: whether the software is restricted to a MIPS32 instruction set (''NUBI32''), or can use the whole of MIPS64 (''NUBI64''). If you only ever use MIPS32 instructions all general-purpose registers might as well be 32-bits wide. Even NUBI32 software is assumed to have access to double-precision floating point operations,
−	* Size of basic C types: we need to recognise a variant of NUBI64 with 64-bit pointers and long. I'm going to use NUBI64W (''W'' for ''wide'') to denote this for now. Better suggestions welcomed.<br>In the medium term we expect the ''narrow'' 64-bit ABI which uses 32-bit pointers and long type to be more popular.
−
−	That leads to the following list of six main variants: NUBI32L, NUBI32B, NUBI64L, NUBI64B, NUBI64WL and NUBI64WB. We'll use ''NUBI32'' to mean ''NUBI32L and NUBI32B'', and - at a pinch - NUBI-L to mean ''NUBI32L and NUBI64L''.
−
−	~~=== How's NUBI different from o32? ===~~
−	* More argument registers : eight instead of four.
−	* Argument registers shared with return-value registers : helps avoid having too many registers with pre-defined roles.
−	* Adds a thread pointer : for efficient TLS.
−	* o32 was stack based, NUBI is register-based: at bottom o32 used a stack-based calling convention, though it's disguised because the first, notional, 4Ã—32-bit locations of the underlying stack argument structure are left unwritten, with the real data passed in four argument registers.<br> At the time o32 was introduced C programs were frequently written without ''function prototypes'' to describe the types of the arguments expected by an external function. Without any prototypes calls to functions with non-standard arguments or (worse) with a variable number of arguments, like printf(), were difficult to get right. The underlying stack structure helped; a troubled function could save the four registers onto the stack to obtain a completely predictable memory structure for its arguments.<br> The stack-based structure also made it possible to pass data of derived types (structures, principally) by value. This has advantages: sometimes the data types you think are obscure turn out to be common.<br> In o32's generation, the critical example of this was the Fortran complex-number data type (which is a pair of floating point values).<br> However, in NUBI32's time the problem is more likely to be that we'd like to handle long long arguments and return values more efficiently. This might be worth a special case (which would cover complex and double-precision floating point numbers too).
−	* o32 was irredeemably 32-bit, NUBI makes interworking possible: a call between a NUBI64 program and a NUBI32 program will always need ''gasket'' code, but a gasket which is automatically produced would be a useful tool for complicated applications which are migrating from 32-bit to 64-bit, and where not all the components are recompiled together.
−
−	~~== NUBI draft ==~~
−	~~The v0.16 from September , 2005 can be downloaded at ftp://ftp.linux-mips.org//pub/linux/mips/doc/NUBI/MD00438-2C-NUBIDESC-SPC-00.16.pdf.~~
−
−	~~== Notes ==~~
−	~~# Since the normal 32-bit MIPS register set treats pretty much all registers the same, the MIPS16e constraint should be unproblematic.~~

@@ Line 34: / Line 34: @@
 * Reduce 32-/64-bit incompatibility : 64-bit hardware is already with us.  It will be easier for applications to migrate to 64-bit computing if we can offer transition tools which can build applications from a mixture of 32- and 64-bit modules. This will never be seamless, but we believe it's worth making it practicable in controlled circumstances.
 == Introducing NUBI ==
 We've chosen this name, for now. We intend to improve on o32 with something simpler, but which prefers being trouble-free for the MIPS programming community over ground-breaking innovation.

@@ Line 30: / Line 30: @@
 * Make better use of registers : o32's limit of four argument registers causes unnecessary stack shuffling, and programs would run slightly better if we reserved more. Eight argument registers has been tried with success, notably by n64/n32.<br>We will define more ''saved'' registers. Not only is this common for other architectures, but it is evident that the GNU C compiler would quite often generate better code with a few more of these.
 * Add a thread pointer : a per-thread pointer in a reserved register makes for efficient thread-local storage.
-* Avoid unnecessary trouble with MIPS16e: the [[MIPS16]] compact-code standard uses half-size (16-bit) instructions, and one of the trade-offs made means it only has first-class access to eight general-purpose registers. We want to ensure the ABI's register use does not cause avoidable pain to MIPS16e programs (2).
+* Avoid unnecessary trouble with MIPS16e: the [[MIPS16]] compact-code standard uses half-size (16-bit) instructions, and one of the trade-offs made means it only has first-class access to eight general-purpose registers. We want to ensure the ABI's register use does not cause avoidable pain to MIPS16e programs (1).
 * Better position-independent code (''PIC'') : all Linux shared libraries and applications are built PIC, so PIC efficiency matters. The general PIC code sequences for external data access and subroutine linkage are quite slow: we want to permit more optimisations of PIC calling and data referencing sequences.
-* Reduce 32-/64-bit incompatibility : as systems grow to 64-bits we expect there to be some demand to interlink 32- and 64-bit code. This will never be seamless, but we believe it's worth making it practicable in controlled circumstances.
+* Reduce 32-/64-bit incompatibility : 64-bit hardware is already with us.  It will be easier for applications to migrate to 64-bit computing if we can offer transition tools which can build applications from a mixture of 32- and 64-bit modules. This will never be seamless, but we believe it's worth making it practicable in controlled circumstances.
 == Introducing NUBI ==

← Older revision		Revision as of 13:54, 28 September 2005
Line 55:		Line 55:

	== Notes ==		== Notes ==
−	# MIPS16e is the name for the instruction set provided by MIPS32 CPUs in 16-bit-instruction mode, whereas MIPS16 may be used for the name of the mode. MIPS16e adds a few instructions (which noticeably improve code compression) to the instruction set defined for earlier MIPS16 CPUs.
	# Since the normal 32-bit MIPS register set treats pretty much all registers the same, the MIPS16e constraint should be unproblematic.		# Since the normal 32-bit MIPS register set treats pretty much all registers the same, the MIPS16e constraint should be unproblematic.