gcc 3.0 question: ILP32 mode ?

This report http://www.linuxia64.org/gcc_summit.2001.06.06.html mentions that:

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

No.

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.

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

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
[email protected]

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

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 :-)

Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/938-9838

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

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/

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.

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