[Linux-ia64] gcc 3.0 question: ILP32 mode ?

[Linux-ia64] gcc 3.0 question: ILP32 mode ?

[Jose Luu]

This report http://www.linuxia64.org/gcc_summit.2001.06.06.html mentions
that:
> the HP-UX version of GCC on IA-64 supports
>   ILP32 as well as LP64

Is this also available on linux gcc 3.0 ?
If not, how difficult would it be to make such a version ?
In case I want to undertake it, are the changes for HP-UX already
incorporated in the opensource tree ?



Thanks
Jose

RE: [Linux-ia64] gcc 3.0 question: ILP32 mode ?

[Boehm, Hans]

> -----Original Message-----
> From: Jose Luu [mailto:jluu@mainsoft.com]
> Sent: Thursday, July 26, 2001 12:51 PM
> To: linux-ia64@linuxia64.org
> Subject: [Linux-ia64] gcc 3.0 question: ILP32 mode ?
> 
> 
> 
> This report 
> http://www.linuxia64.org/gcc_summit.2001.06.06.html mentions
> that:
> > the HP-UX version of GCC on IA-64 supports
> >   ILP32 as well as LP64
> 
> Is this also available on linux gcc 3.0 ?
No.

> If not, how difficult would it be to make such a version ?
How are you going to run the resulting code?  The kernel doesn't support it.
Neither do the libraries installed on any system.  Neither do any ISV
libraries.  Nor in all probability should they, since that raises the
possibility of applications that can't be built because it relies on one
library that's only available as ILP32 and another that's LP64.

> In case I want to undertake it, ...
If this requires building another version of standard libraries, you don't
want to do this, given that Linux/Itanium can run X86 binaries on Linux.
Supporting another ABI is very expensive.  The tradeoffs for HP/UX are
different.

Hans

Re: [Linux-ia64] gcc 3.0 question: ILP32 mode ?

[Rich Altmaier]

Dear Jose and others, I would like to caution against proceeding
in this direction (to create ILP32 mode on IA64 systems).
Although it may seem attractive to be able to port code to IA64
without doing the 64bit address corrections, the result is a total
forking of the ABI.

Since 32bit-address and 64bit-address object code cannot be linked
together, persuing 32-bit address becomes a steadily expanding
space.   You have to collect each and every library that you need,
and libraries used by libraries, to get them available in this 32bit
format.   The library developer has to provide two versions.

Since it is always less engineering work to do the 32bit version,
some developers will decide to not do the 64bit version.
Other developers will decide to not do the 32bit version.

The end result will be such fragementation that no application will
find all the libraries it needs, in either format.

Creating a second ABI for IA64 is not to be taken lightly.  It is a big,
big step.   It will echo its result for years.
I urge you to do the 64-bit address cleanup in your code.
For this little bit of up front work, you will promote IA64's success
for the next 10 years.   Other approaches will sink it.

Thanks, Rich
Rich Altmaier
VP of Foundation Software
SGI
richa@sgi.com


Jose Luu wrote:

> This report http://www.linuxia64.org/gcc_summit.2001.06.06.html mentions
> that:
> > the HP-UX version of GCC on IA-64 supports
> >   ILP32 as well as LP64
>
> Is this also available on linux gcc 3.0 ?
> If not, how difficult would it be to make such a version ?
> In case I want to undertake it, are the changes for HP-UX already
> incorporated in the opensource tree ?
>
> Thanks
> Jose

Re: [Linux-ia64] gcc 3.0 question: ILP32 mode ?

[Jose Luu]

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

Re: [Linux-ia64] gcc 3.0 question: ILP32 mode ?

[Don Dugger]

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

Re: [Linux-ia64] gcc 3.0 question: ILP32 mode ?

[Jes Sorensen]

>>>>> "Jose" = Jose Luu <jluu@mainsoft.com> writes:

Jose> Hans wrote:
>> Supporting another ABI is very expensive.  The tradeoffs for HP/UX
>> are different.
>> 

Jose> I am sure I don't realize how expensive it is, but it seems
Jose> worth investigating, for our purposes we need the libc and
Jose> libX11, little else.

Lets just say that libc (glibc) itself is reason enough not to do
it. It's a TON of work and I don't want to see glibc/ia64 being split
for this unless there is a real good reason. I certainly do not want
to maintain two versions.

Jose> Some code is just not worth cleaning up because it is too big,
Jose> and will never require 64 bit addressing, but still useful to
Jose> have in native mode, mostly because of the performance gap
Jose> between ia32 and ILP32 which will moreover widen with the
Jose> McKinley chip. Look at netscape, it has never been cleaned up,
Jose> it was ported on linux alpha using the DEC/Compaq/(Intel now?)
Jose> compiler in taso mode (32 bit pointers).

Linux/Alpha's glibc doesn't support 32 bit pointers afaik.

Jose> DEC/Compaq developped a technology for VMS where one can mix 32
Jose> and 64 bit libraries, I am wondering if the same ideas can be
Jose> applied here (see references below), nowadays this technology
Jose> should be with Intel. This would avoid the fork in the ABI.

The only way what you are asking for requires all library calls to be
made 64 bit. Not to mention that Linux/ia64 doesn't support loading
native ia64 binaries into the lower 4GB segment, we currently load the
text segment at 0x4000000000000000.

Jes

Re: [Linux-ia64] gcc 3.0 question: ILP32 mode ?

[Rik van Riel]

On Fri, 27 Jul 2001, 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.

And the compiler, the linker, support for the ABI in
the kernel, system call wrappers, etc...

Oh, and of course all of these will need to be maintained
across 25 different releases the next 10 years - in random
combinations of version numbers.

I'm sure you have the time to implement all of the above
right now, but do you have the time to maintain it for the
next decade ?

(oh, and with "you" I really do mean YOU, unless of course
you hire somebody else to take care of it for you ;))

cheers,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: [Linux-ia64] gcc 3.0 question: ILP32 mode ?

[Christoph Hellwig]

On Tue, Jul 31, 2001 at 12:06:48AM +0200, Jes Sorensen wrote:
> Jose> McKinley chip. Look at netscape, it has never been cleaned up,
> Jose> it was ported on linux alpha using the DEC/Compaq/(Intel now?)
> Jose> compiler in taso mode (32 bit pointers).
> 
> Linux/Alpha's glibc doesn't support 32 bit pointers afaik.

The netscape usually used on Linux/Alpha is the DEC OSF/1 one,
which means it uses the DEC libs..

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: [Linux-ia64] gcc 3.0 question: ILP32 mode ?

[David Mosberger]

>>>>> On 31 Jul 2001 00:06:48 +0200, Jes Sorensen <jes@sunsite.dk> said:

  Jose> Some code is just not worth cleaning up because it is too big,
  Jose> and will never require 64 bit addressing, but still useful to
  Jose> have in native mode, mostly because of the performance gap
  Jose> between ia32 and ILP32 which will moreover widen with the
  Jose> McKinley chip. Look at netscape, it has never been cleaned up,
  Jose> it was ported on linux alpha using the DEC/Compaq/(Intel now?)
  Jose> compiler in taso mode (32 bit pointers).

  Jes> Linux/Alpha's glibc doesn't support 32 bit pointers afaik.

Note that netscape doesn't/didn't get cleaned up for 64 bits because
Mozilla already *is* 64-bit clean.

I have yet to see a program that is worth running in natively yet not
worth cleaning up for 64 bits.

	--david