From: Hartvig Ekner <hartvige@mips.com>
To: macro@ds2.pg.gda.pl (Maciej W. Rozycki)
Cc: kevink@mips.com (Kevin D. Kissell), tor@spacetec.no (Tor Arntsen),
carstenl@mips.com (Carsten Langgaard),
ralf@linux-mips.org (Ralf Baechle),
linux-mips@linux-mips.org
Subject: Re: 64-bit and N32 kernel interfaces
Date: Thu, 5 Sep 2002 16:20:55 +0200 (MET DST) [thread overview]
Message-ID: <200209051420.QAA26367@copcs01.mips.com> (raw)
In-Reply-To: <Pine.GSO.3.96.1020905155411.7444A-100000@delta.ds2.pg.gda.pl> from "Maciej W. Rozycki" at Sep 05, 2002 04:09:11 PM
I don't know the ultimate reasons why SGI choose ILP32 for n32, but one
could certainly be portability.
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
o32 sources that assume (sizeof(void *)) = sizeof(long), plus binary data
file compatability with o32 as all structures are exactly identical between
o32 and n32.
/Hartvig
Maciej W. Rozycki writes:
>
> On Thu, 5 Sep 2002, Kevin D. Kissell wrote:
>
> > n32 has the same data types as o32, an "ILP32" C integer
> > model. n64 is a pretty normal "LP64" C integer model.
> >
> > What do you consider to be broken, and how would you
> > have preferred it to have been done?
>
> For n32 it would be natural to have:
>
> - sizeof(int) = 32
>
> - sizeof(long) = 64
>
> - sizeof(void *) = 32
>
> as the underlying hardware directly supports 64-bit operations (n32
> requires at least MIPS III). Thus there is no penalty for 64-bit
> arithmetics and if one uses longs one normally wants the largest native
> integer type -- using long long typically (i.e. on most platforms) implies
> double-precision arithmetics with all the drawbacks, especially for the
> division and multiplication operations.
>
> With 32-bit long on 64-bit hardware software has no easy way to figure
> using 64-bit operations is still optimal performance-wise. I can't see
> any technical benefit from such a setup -- is there any? I doubt it.
>
> --
> + Maciej W. Rozycki, Technical University of Gdansk, Poland +
> +--------------------------------------------------------------+
> + e-mail: macro@ds2.pg.gda.pl, PGP key available +
>
>
>
--
_ _ _____ ____ Hartvig Ekner Mailto:hartvige@mips.com
|\ /| | |____)(____ Direct: +45 4486 5503
| \/ | | | _____) MIPS Denmark Switch: +45 4486 5555
T E C H N O L O G I E S http://www.mips.com Fax...: +45 4486 5556
WARNING: multiple messages have this Message-ID (diff)
From: Hartvig Ekner <hartvige@mips.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: "Kevin D. Kissell" <kevink@mips.com>,
Tor Arntsen <tor@spacetec.no>,
Carsten Langgaard <carstenl@mips.com>,
Ralf Baechle <ralf@linux-mips.org>,
linux-mips@linux-mips.org
Subject: Re: 64-bit and N32 kernel interfaces
Date: Thu, 5 Sep 2002 16:20:55 +0200 (MET DST) [thread overview]
Message-ID: <200209051420.QAA26367@copcs01.mips.com> (raw)
Message-ID: <20020905142055.iq3gRFGYsq6gtS6jX_1PuSIIBF83nLhmBMD4XZlmR2I@z> (raw)
In-Reply-To: <Pine.GSO.3.96.1020905155411.7444A-100000@delta.ds2.pg.gda.pl> from "Maciej W. Rozycki" at Sep 05, 2002 04:09:11 PM
I don't know the ultimate reasons why SGI choose ILP32 for n32, but one
could certainly be portability.
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
o32 sources that assume (sizeof(void *)) = sizeof(long), plus binary data
file compatability with o32 as all structures are exactly identical between
o32 and n32.
/Hartvig
Maciej W. Rozycki writes:
>
> On Thu, 5 Sep 2002, Kevin D. Kissell wrote:
>
> > n32 has the same data types as o32, an "ILP32" C integer
> > model. n64 is a pretty normal "LP64" C integer model.
> >
> > What do you consider to be broken, and how would you
> > have preferred it to have been done?
>
> For n32 it would be natural to have:
>
> - sizeof(int) = 32
>
> - sizeof(long) = 64
>
> - sizeof(void *) = 32
>
> as the underlying hardware directly supports 64-bit operations (n32
> requires at least MIPS III). Thus there is no penalty for 64-bit
> arithmetics and if one uses longs one normally wants the largest native
> integer type -- using long long typically (i.e. on most platforms) implies
> double-precision arithmetics with all the drawbacks, especially for the
> division and multiplication operations.
>
> With 32-bit long on 64-bit hardware software has no easy way to figure
> using 64-bit operations is still optimal performance-wise. I can't see
> any technical benefit from such a setup -- is there any? I doubt it.
>
> --
> + Maciej W. Rozycki, Technical University of Gdansk, Poland +
> +--------------------------------------------------------------+
> + e-mail: macro@ds2.pg.gda.pl, PGP key available +
>
>
>
--
_ _ _____ ____ Hartvig Ekner Mailto:hartvige@mips.com
|\ /| | |____)(____ Direct: +45 4486 5503
| \/ | | | _____) MIPS Denmark Switch: +45 4486 5555
T E C H N O L O G I E S http://www.mips.com Fax...: +45 4486 5556
next prev parent reply other threads:[~2002-09-05 14:21 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-05 9:30 64-bit and N32 kernel interfaces Tor Arntsen
2002-09-05 11:47 ` Maciej W. Rozycki
2002-09-05 12:48 ` Kevin D. Kissell
2002-09-05 12:48 ` Kevin D. Kissell
2002-09-05 14:09 ` Maciej W. Rozycki
2002-09-05 14:20 ` Hartvig Ekner [this message]
2002-09-05 14:20 ` Hartvig Ekner
2002-09-05 14:54 ` Maciej W. Rozycki
2002-09-05 14:59 ` Daniel Jacobowitz
2002-09-05 15:10 ` Maciej W. Rozycki
2002-09-05 15:14 ` Daniel Jacobowitz
2002-09-05 16:16 ` Maciej W. Rozycki
2002-09-05 16:19 ` Daniel Jacobowitz
2002-09-05 16:33 ` Maciej W. Rozycki
2002-09-05 16:39 ` Daniel Jacobowitz
2002-09-05 17:16 ` Maciej W. Rozycki
2002-09-05 17:29 ` Kevin D. Kissell
2002-09-05 17:29 ` Kevin D. Kissell
2002-09-05 19:34 ` Maciej W. Rozycki
2002-09-06 9:42 ` Ralf Baechle
2002-09-05 18:07 ` Hartvig Ekner
2002-09-05 18:07 ` Hartvig Ekner
2002-09-05 18:54 ` Maciej W. Rozycki
2002-09-05 19:16 ` Thiemo Seufer
2002-09-06 9:30 ` Ralf Baechle
2002-09-05 14:22 ` Daniel Jacobowitz
2002-09-05 15:08 ` Maciej W. Rozycki
2002-09-05 15:14 ` Daniel Jacobowitz
2002-09-05 16:28 ` Maciej W. Rozycki
2002-09-05 16:30 ` Thiemo Seufer
2002-09-05 16:54 ` Maciej W. Rozycki
2002-09-05 17:44 ` Thiemo Seufer
2002-09-05 19:50 ` Maciej W. Rozycki
2002-09-05 22:12 ` Thiemo Seufer
2002-09-09 17:39 ` Maciej W. Rozycki
2002-09-06 10:14 ` Ralf Baechle
2002-09-09 14:01 ` Dominic Sweetman
-- strict thread matches above, loose matches on Subject: below --
2002-09-04 13:56 Ralf Baechle
2002-09-04 14:14 ` Maciej W. Rozycki
2002-09-04 14:31 ` Ralf Baechle
2002-09-04 15:19 ` Maciej W. Rozycki
2002-09-04 18:46 ` Ralf Baechle
2002-09-05 9:53 ` Maciej W. Rozycki
2002-09-05 6:40 ` Carsten Langgaard
2002-09-05 9:23 ` Maciej W. Rozycki
2002-09-05 13:41 ` Daniel Jacobowitz
2002-09-04 17:32 ` Jun Sun
2002-09-04 17:56 ` Maciej W. Rozycki
2002-09-04 18:40 ` Ralf Baechle
2002-09-05 10:15 ` Kjeld Borch Egevang
2002-09-05 10:15 ` Kjeld Borch Egevang
2002-09-09 20:20 ` Jay Carlson
2002-09-16 13:01 ` Ralf Baechle
2002-09-16 15:40 ` Ralf Baechle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200209051420.QAA26367@copcs01.mips.com \
--to=hartvige@mips.com \
--cc=carstenl@mips.com \
--cc=kevink@mips.com \
--cc=linux-mips@linux-mips.org \
--cc=macro@ds2.pg.gda.pl \
--cc=ralf@linux-mips.org \
--cc=tor@spacetec.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.