[Top] [All Lists]

Re: 64-bit and N32 kernel interfaces

To: Hartvig Ekner <>
Subject: Re: 64-bit and N32 kernel interfaces
From: "Maciej W. Rozycki" <>
Date: Thu, 5 Sep 2002 16:54:09 +0200 (MET DST)
Cc: "Kevin D. Kissell" <>, Tor Arntsen <>, Carsten Langgaard <>, Ralf Baechle <>,
In-reply-to: <>
Organization: Technical University of Gdansk
Original-recipient: rfc822;
On Thu, 5 Sep 2002, Hartvig Ekner wrote:

> I don't know the ultimate reasons why SGI choose ILP32 for n32, but one
> could certainly be portability.

 It depends on how you define "portability".  While it might help some
broken software, it will hurt good one.

> As defined, n32 provides all the benefits of 64-bit data (yes, you have
> to use long long to get to it), and 100% backward compatability with 

 So you can't use long to keep a file position pointer (off_t is quite a
new invention) and have to go for long long, for example?  Weird and
definitely doesn't help portability. 

> o32 sources that assume (sizeof(void *)) = sizeof(long), plus binary data

 Thay should be fixed, instead.  Using "void *" as a data container
doesn't work in general and one who does so should be banished.  And the
other way round, there is no problem -- if one keeps 32-bit pointers in
64-bit longs, there is no bit loss. 

> file compatability with o32 as all structures are exactly identical between
> o32 and n32.

 Why don't use o32 as is then, instead of creating a slightly different
ABI?  If some software needs binary data to be identical, then it has to
select fixed-size types, e.g. int32_t, explicitly.  While int32_t and
friends are quite a new standard, other ways were used for years to set up
such aspects, e.g. autoconf, imake, hand-written system-specific
preprocessor macros, etc., etc.

+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

<Prev in Thread] Current Thread [Next in Thread>