All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.