public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Don Dugger <n0ano@valinux.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] gcc 3.0 question: ILP32 mode ?
Date: Thu, 26 Jul 2001 23:32:27 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590693005938@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590693005928@msgid-missing>

Jose-

My assumption is that if a program is not worth porting to IA64
then you should just leave it as an IA32 program.  If it is worth
porting to IA64 then port it to a full 64-bit implementation.

We've thought about creating a 32-bit IA64 model may times in the
past and everytime we've done that we've reached the conclusion
that it just is not worth the effort and we fall back to the
original assumption.

Also, I predict you need lots more that just `libc' and `libX11'.
Just off the top of my head I know you'll need `ld.so' and `libm'.
I've got 19 `.so's in my `/usr/X11R6/lib' directory so you'll probably
need most of them.  Make a 32-bit mode available and somebody, somewhere
will want every available library in that mode.

Just say no :-) 

On Fri, Jul 27, 2001 at 12:42:25AM +0200, Jose Luu wrote:
> 
> Hans wrote:
> > Supporting another ABI is very expensive.  The tradeoffs for HP/UX are
> > different.
> >
> 
> I am sure I don't realize how expensive it is, but it seems worth
> investigating, for our purposes we need the libc and libX11, little else.
> 
> Some code is just not worth cleaning up because it is too big, and will
> never require 64 bit addressing, but still useful to have in native mode,
> mostly because of the performance gap between ia32 and ILP32 which will
> moreover widen with the McKinley chip. Look at netscape, it has never been
> cleaned up, it was ported on linux alpha using the DEC/Compaq/(Intel now?)
> compiler in taso mode (32 bit pointers).
> 
> DEC/Compaq developped a technology for VMS where one can mix 32 and 64 bit
> libraries, I am wondering if the same ideas can be applied here (see
> references below), nowadays this technology should be with Intel. This would
> avoid the fork in the ABI.
> 
> References:
> http://www.research.compaq.com/wrl/DECarchives/DTJ/DTJM06/DTJM06HM.HTM and
> http://www.research.compaq.com/wrl/DECarchives/DTJ/DTJM07/DTJM07HM.HTM
> 
> Jose
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@valinux.com
Ph: 303/938-9838


  parent reply	other threads:[~2001-07-26 23:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-26 19:50 [Linux-ia64] gcc 3.0 question: ILP32 mode ? Jose Luu
2001-07-26 20:18 ` Boehm, Hans
2001-07-26 20:19 ` Rich Altmaier
2001-07-26 22:42 ` Jose Luu
2001-07-26 23:32 ` Don Dugger [this message]
2001-07-30 22:06 ` Jes Sorensen
2001-07-30 22:15 ` Rik van Riel
2001-07-30 22:16 ` Christoph Hellwig
2001-07-30 22:36 ` David Mosberger

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=marc-linux-ia64-105590693005938@msgid-missing \
    --to=n0ano@valinux.com \
    --cc=linux-ia64@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox