native ia64 32-bits compile & run on linux-ia64?
Hi all,
I am wondering if the Linux & GCC port on ia64 allows compilation & execution of native i64 32-bits executables (not speaking about ia32 compatibility, but native 32-bits on ia64).
HP-UX & AIX (at least) have this generation & execution options, because execution speed would be sorted as follows, in descending order:
* native 32-bits executables
* native 64-bits
* ia32 emulation
I did not find any clue of that neither in the GCC web site, nor from the "Linux on ia64" site.
Anyone has information on that? Is it part of the "non-said" wish/todo list ?
TIA
Signature · 4 lines
Francois-Xavier "FiX" KOWALSKI /_ __ Tel:+33 (0)4 76 14 63 27
Telecom Infrastructure Division / //_/ Telnet: 779-6327
SigTech eXpert / http://www.hp.com/go/opencall
i n v e n tI'll try and give a brief run down of the execution environments available on IA64 Linux right now. The CPU is capable of executing two different instruction sets, IA64 and IA32. For the IA64 instruction set there are multiple execution modes possible, the most obvious two being LP64 (long' and pointer are 64-bits, int' is 32-bits) and ILP32 (int', long' and pointer' are all 32-bits).
The `native' environment for IA64 Linux has been declared to be the IA64 instruction set running in LP64 mode. This is fully supported by GCC, GLIBC, tools and the kernel.
Although running IA64 instructions in ILP32 mode is conceptually possible it is not supported and there are no plans to support this mode any time in the near future. This would require significant changes to GCC, GLIBC and the kernel at a minimum and no one has provided any compelling evidence that there is enough performance gain to justify this effort.
The IA32 support in IA64 Linux is designed more as a transition tool rather than a development environment. Our goal all along has been to support executing current IA32 programs, not generating new ones. Therefore the compiler tools (GCC, the linker and what not) have no support for IA32 code generation. If you really want to generate IA32 programs on an IA64 Linux system you can install an IA32 version of GCC and use that.
Quoted 33 lines · Francois-Xavier Kowalski
Hi all,
I am wondering if the Linux & GCC port on ia64 allows compilation & execution of native i64 32-bits executables (not speaking about ia32 compatibility, but native 32-bits on ia64).
HP-UX & AIX (at least) have this generation & execution options, because execution speed would be sorted as follows, in descending order:
* native 32-bits executables
* native 64-bits
* ia32 emulationI did not find any clue of that neither in the GCC web site, nor from the "Linux on ia64" site.
Anyone has information on that? Is it part of the "non-said" wish/todo list ?
TIA
Signature · 11 lines
Francois-Xavier "FiX" KOWALSKI /_ __ Tel:+33 (0)4 76 14 63 27 Telecom Infrastructure Division / //_/ Telnet: 779-6327 SigTech eXpert / http://www.hp.com/go/opencall i n v e n t _______________________________________________ Linux-IA64 mailing list [email protected] http://lists.linuxia64.org/lists/listinfo/linux-ia64
Signature · 4 lines
Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [email protected] Ph: 303/652-0870x117
Thanks for the reply.
Quoted 11 lines · [email protected] wrote:
I'll try and give a brief run down of the execution environments available on IA64 Linux right now. The CPU is capable of executing two different instruction sets, IA64 and IA32. For the IA64 instruction set there are multiple execution modes possible, the most obvious two being LP64 (
long' andpointer are 64-bits,int' is 32-bits) and ILP32 (int',long' andpointer' are all 32-bits).The `native' environment for IA64 Linux has been declared to be the IA64 instruction set running in LP64 mode. This is fully supported by GCC, GLIBC, tools and the kernel.
Quoted 6 lines
Although running IA64 instructions in ILP32 mode is conceptually possible it is not supported and there are no plans to support this mode any time in the near future. This would require significant changes to GCC, GLIBC and the kernel at a minimum and no one has provided any compelling evidence that there is enough performance gain to justify this effort.
I think I am a bit confused. I was assuming that there was a difference between execution of an IA32 executable compiled on a IA32 platform (native IA32), and an IA32 executable compiled on a IA64 machine to run in 32-bits mode.
Do I mistake?
Quoted 7 lines
The IA32 support in IA64 Linux is designed more as a transition tool rather than a development environment. Our goal all along has been to support executing current IA32 programs, not generating new ones. Therefore the compiler tools (GCC, the linker and what not) have no support for IA32 code generation. If you really want to generate IA32 programs on an IA64 Linux system you can install an IA32 version of GCC and use that.
Will this need to install as well a Linux/IA32 version on the whole run-time environment (GLIBC & whatsoever), or will GCC be able to use the native IA64 libraries?
Maybe the question above means mixing IA32 & IA64 instructions within the same execution context & is forbidden.
Quoted 11 lines · Francois-Xavier Kowalski
Quoted 10 lines
Hi all,
I am wondering if the Linux & GCC port on ia64 allows compilation & execution of native i64 32-bits executables (not speaking about ia32 compatibility, but native 32-bits on ia64).
HP-UX & AIX (at least) have this generation & execution options, because execution speed would be sorted as follows, in descending order:
Quoted 7 lines
Quoted 7 lines
* native 32-bits executables
* native 64-bits
* ia32 emulationI did not find any clue of that neither in the GCC web site, nor from the "Linux on ia64" site.
FiX
Signature · 4 lines
Francois-Xavier "FiX" KOWALSKI /_ __ Tel:+33 (0)4 76 14 63 27
Telecom Infrastructure Division / //_/ Telnet: 779-6327
SigTech eXpert / http://www.hp.com/go/opencall
i n v e n tQuoted 8 lines · Francois-Xavier Kowalski
Quoted 5 lines · [email protected] wrote:
Although running IA64 instructions in ILP32 mode is conceptually possible it is not supported and there are no plans to support this mode any time in the near future. This would require significant changes to GCC, GLIBC and the kernel at a minimum and no one has provided any compelling evidence that there is enough performance gain to justify this effort.
Quoted 6 lines
I think I am a bit confused. I was assuming that there was a difference between execution of an IA32 executable compiled on a IA32 platform (native IA32), and an IA32 executable compiled on a IA64 machine to run in 32-bits mode.
Do I mistake?
The ia64 is basically two cpus in one, a real ia64 and a legacy ia32. ia32 code is slow and runs for compatibility not performance. What Don is talking about is that one could theoretically run the ia64 unit in 'short' mode ie. declare pointers to be 32 bit to save some space. However this would require a second glibc target plus modifications to the compiler and it doesn't fit into the memory model we are using.
There has been a few requests for this, but so far nothing convincing enough to justify the effort. I for one has no interest in doing another full glibc target.
Quoted 10 lines
Quoted 6 lines
The IA32 support in IA64 Linux is designed more as a transition tool rather than a development environment. Our goal all along has been to support executing current IA32 programs, not generating new ones. Therefore the compiler tools (GCC, the linker and what not) have no support for IA32 code generation. If you really want to generate IA32 programs on an IA64 Linux system you can install an IA32 version of GCC and use that.
Will this need to install as well a Linux/IA32 version on the whole run-time environment (GLIBC & whatsoever), or will GCC be able to use the native IA64 libraries?
If you want to build and run ia32 binaries, you need a complete ia32 toolchain environment and libraries.
Quoted 2 lines
Maybe the question above means mixing IA32 & IA64 instructions within the same execution context & is forbidden.
It's not possible.
Cheers,
Jes
FiX-
Looks like you did have a minor confusion. The goal for IA32 support is to run `current' IA32 applications on an IA64 Linux machine. Creating IA32 applications on IA64 was never a goal and that's why the IA64 GCC and tools have no support for generating IA32 instructions.
Any IA32 program, including the IA32 GCC, would require the installation of an entire IA32 run-time environment on the IA64 machine. Fortunately all of the IA64 distributions provide IA32 environments as an option so it's easy to provide this.
Mixing IA32 and IA64 instruction sets in the same program is another one of those things that is conceptually feasible but no one supports it because there is not enough benefit. The biggest advantage for this would be in shared libraries and it's not worth it even here. If you can obtain a current IA32 program then you can obtain the IA32 libraries that it uses so there's no need for an IA32 program to call IA64 shared libraries. If you have an IA32 shared library that you want to use from an IA64 program then you should just re-compile the library for IA64 (remember, we're dealing with open source here).
Quoted 71 lines · Francois-Xavier Kowalski
Thanks for the reply.
Quoted 11 lines · [email protected] wrote:
I'll try and give a brief run down of the execution environments available on IA64 Linux right now. The CPU is capable of executing two different instruction sets, IA64 and IA32. For the IA64 instruction set there are multiple execution modes possible, the most obvious two being LP64 (
long' andpointer are 64-bits,int' is 32-bits) and ILP32 (int',long' andpointer' are all 32-bits).The `native' environment for IA64 Linux has been declared to be the IA64 instruction set running in LP64 mode. This is fully supported by GCC, GLIBC, tools and the kernel.
Quoted 6 lines
Although running IA64 instructions in ILP32 mode is conceptually possible it is not supported and there are no plans to support this mode any time in the near future. This would require significant changes to GCC, GLIBC and the kernel at a minimum and no one has provided any compelling evidence that there is enough performance gain to justify this effort.
I think I am a bit confused. I was assuming that there was a difference between execution of an IA32 executable compiled on a IA32 platform (native IA32), and an IA32 executable compiled on a IA64 machine to run in 32-bits mode.
Do I mistake?
Quoted 7 lines
The IA32 support in IA64 Linux is designed more as a transition tool rather than a development environment. Our goal all along has been to support executing current IA32 programs, not generating new ones. Therefore the compiler tools (GCC, the linker and what not) have no support for IA32 code generation. If you really want to generate IA32 programs on an IA64 Linux system you can install an IA32 version of GCC and use that.
Will this need to install as well a Linux/IA32 version on the whole run-time environment (GLIBC & whatsoever), or will GCC be able to use the native IA64 libraries?
Maybe the question above means mixing IA32 & IA64 instructions within the same execution context & is forbidden.
Quoted 11 lines · Francois-Xavier Kowalski
Quoted 10 lines
Hi all,
I am wondering if the Linux & GCC port on ia64 allows compilation & execution of native i64 32-bits executables (not speaking about ia32 compatibility, but native 32-bits on ia64).
HP-UX & AIX (at least) have this generation & execution options, because execution speed would be sorted as follows, in descending order:
Quoted 7 lines
Quoted 7 lines
* native 32-bits executables
* native 64-bits
* ia32 emulationI did not find any clue of that neither in the GCC web site, nor from the "Linux on ia64" site.
FiX
Signature · 4 lines
Francois-Xavier "FiX" KOWALSKI /_ __ Tel:+33 (0)4 76 14 63 27 Telecom Infrastructure Division / //_/ Telnet: 779-6327 SigTech eXpert / http://www.hp.com/go/opencall i n v e n t
Signature · 4 lines
Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [email protected] Ph: 303/652-0870x117
Ok Guys, thanks for your answers.
I was - wrongly - assuming that Linux/IA64 would provide this feature - run ia64 code in 32-bits mode - provided by other UNIX's (at least HP-UX 11i & AIX).
The request was about existing source code which is not (yet) 64-bits clean. I understand that the _real_ porting to 64-bits is mandatory to benefit from ia64 speed.
FiX
Quoted 20 lines · [email protected] wrote:
Looks like you did have a minor confusion. The goal for IA32 support is to run `current' IA32 applications on an IA64 Linux machine. Creating IA32 applications on IA64 was never a goal and that's why the IA64 GCC and tools have no support for generating IA32 instructions.
Any IA32 program, including the IA32 GCC, would require the installation of an entire IA32 run-time environment on the IA64 machine. Fortunately all of the IA64 distributions provide IA32 environments as an option so it's easy to provide this.
Mixing IA32 and IA64 instruction sets in the same program is another one of those things that is conceptually feasible but no one supports it because there is not enough benefit. The biggest advantage for this would be in shared libraries and it's not worth it even here. If you can obtain a current IA32 program then you can obtain the IA32 libraries that it uses so there's no need for an IA32 program to call IA64 shared libraries. If you have an IA32 shared library that you want to use from an IA64 program then you should just re-compile the library for IA64 (remember, we're dealing with open source here).
Quoted 37 lines · Jes Sorensen
Quoted 8 lines · Francois-Xavier Kowalski
Quoted 6 lines · [email protected] wrote:
Although running IA64 instructions in ILP32 mode is conceptually possible it is not supported and there are no plans to support this mode any time in the near future. This would require significant changes to GCC, GLIBC and the kernel at a minimum and no one has provided any compelling evidence that there is enough performance gain to justify this effort.
Quoted 4 lines
I think I am a bit confused. I was assuming that there was a difference between execution of an IA32 executable compiled on a IA32 platform (native IA32), and an IA32 executable compiled on a IA64 machine to run in 32-bits mode.
Do I mistake?
The ia64 is basically two cpus in one, a real ia64 and a legacy ia32. ia32 code is slow and runs for compatibility not performance. What Don is talking about is that one could theoretically run the ia64 unit in 'short' mode ie. declare pointers to be 32 bit to save some space. However this would require a second glibc target plus modifications to the compiler and it doesn't fit into the memory model we are using.
There has been a few requests for this, but so far nothing convincing enough to justify the effort. I for one has no interest in doing another full glibc target.
Quoted 9 lines
Quoted 7 lines
The IA32 support in IA64 Linux is designed more as a transition tool rather than a development environment. Our goal all along has been to support executing current IA32 programs, not generating new ones. Therefore the compiler tools (GCC, the linker and what not) have no support for IA32 code generation. If you really want to generate IA32 programs on an IA64 Linux system you can install an IA32 version of GCC and use that.
Will this need to install as well a Linux/IA32 version on the whole run-time environment (GLIBC & whatsoever), or will GCC be able to use the native IA64 libraries?
Quoted 8 lines
If you want to build and run ia32 binaries, you need a complete ia32 toolchain environment and libraries.
Quoted 2 lines
Maybe the question above means mixing IA32 & IA64 instructions within the same execution context & is forbidden.
It's not possible.
Regards.
FiX
Signature · 4 lines
Francois-Xavier "FiX" KOWALSKI /_ __ Tel:+33 (0)4 76 14 63 27
Telecom Infrastructure Division / //_/ Telnet: 779-6327
SigTech eXpert / http://www.hp.com/go/opencall
i n v e n tI think one point that hasn't been made so far is that we actively discourage supporting an ILP32 data model for IA-64 Linux to avoid splitting ia64 linux into two different worlds (32-bit and 64-bit world). If we supported ILP32, it's very likely that some ISVs will decide to provide *only* 32-bit libraries, which could in turn force other ISVs to stay with 32-bit just because they couldn't get the pre-requisite 64-bit libraries. My understanding is that IRIX suffered from this effect.
There are times where an ILP32 model would achieve slightly better performance, but it's certainly not always the case and, in my opinion, the potential performance benefit is not worth the cost of having to maintain two data models (ILP32 and LP64). Note that the cost is not just in developing, testing, and maintaining two versions of each library, but also in added complexity for programmers.
--david
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"David" = David Mosberger <[email protected]> writes:
David> I think one point that hasn't been made so far is that we David> actively discourage supporting an ILP32 data model for IA-64 David> Linux to avoid splitting ia64 linux into two different worlds David> (32-bit and 64-bit world). If we supported ILP32, it's very David> likely that some ISVs will decide to provide *only* 32-bit David> libraries, which could in turn force other ISVs to stay with David> 32-bit just because they couldn't get the pre-requisite 64-bit David> libraries. My understanding is that IRIX suffered from this David> effect.
Very good point, and even if we went down that road one could argue we should only go for IP32 with long's being 64 bit.
Just say no ;)
Jes
Quoted 13 lines · Jes Sorensen
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"David" == David Mosberger <[email protected]> writes:
David> I think one point that hasn't been made so far is that we David> actively discourage supporting an ILP32 data model for IA-64 David> Linux to avoid splitting ia64 linux into two different worlds David> (32-bit and 64-bit world). If we supported ILP32, it's very David> likely that some ISVs will decide to provide *only* 32-bit David> libraries, which could in turn force other ISVs to stay with David> 32-bit just because they couldn't get the pre-requisite 64-bit David> libraries. My understanding is that IRIX suffered from this David> effect.
Quoted 3 lines
Very good point, and even if we went down that road one could argue we should only go for IP32 with long's being 64 bit.
I see the drawback... :-D But maybe Linux provides enough open-source alternatives to existing ISV libraries to limit the number of ISV's impacted by this kind of forced limitation...?
BTW, do you know what is the choice on Linux/ppc64 vs. the previous Linux/ppc implementation on the same topic(data-model sizes)?
Quoted 2 lines
Just say no ;)
FiX
Signature · 4 lines
Francois-Xavier "FiX" KOWALSKI /_ __ Tel:+33 (0)4 76 14 63 27
Telecom Infrastructure Division / //_/ Telnet: 779-6327
SigTech eXpert / http://www.hp.com/go/opencall
i n v e n tThe tradeoffs here are very different for an OS/platform that previously provided an ILP32 ABI with an existing application base (e.g. Solaris, Linux/ppc), and one that didn't. In the former case, I think the experience has been that it's very expensive to support the second (or third) ABI, but it's completely impractical to drop support for the existing application base, so there is no way around the cost of multiple ABIs if you want to support 64-bit pointers. Linux/Itanium is not one of these, at least if you ignore the X86 ABI. We have a choice. And I don't believe that in the long run the benefit will come close to the cost of an ILP32 native ABI, eventhough it might help some of us in the short run. Even for open source libraries, another ABI adds significant testing overhead, etc.
The other Itanium operating systems present somewhat different tradeoffs. All existing PORTABLE Linux applications were by definition already 64-bit clean, since Linux/Alpha provided only a 64-bit ABI. In the case of HP/UX, I suspect at least some of the ILP32 infrastructure was needed for PA-RISC binary emulation anyway. (I'm not aware of what really went into the decision for HP/UX, so I'm just speculating ...)
Hans
-------------------------
"David" = David Mosberger <[email protected]> writes:
David> I think one point that hasn't been made so far is that we David> actively discourage supporting an ILP32 data model for IA-64 David> Linux to avoid splitting ia64 linux into two different worlds David> (32-bit and 64-bit world). If we supported ILP32, it's very David> likely that some ISVs will decide to provide *only* 32-bit David> libraries, which could in turn force other ISVs to stay with David> 32-bit just because they couldn't get the pre-requisite 64-bit David> libraries. My understanding is that IRIX suffered from this David> effect.
Jes Sorenson wrote:
Very good point, and even if we went down that road one could argue weshould only go for IP32 with long's being 64 bit.
Francois-Xavier Kowalski wrote:
I see the drawback... :-D But maybe Linux provides enough open-source alternatives to existing ISV libraries to limit the number of ISV's impacted by this kind of forced limitation...?
BTW, do you know what is the choice on Linux/ppc64 vs. the previous Linux/ppc implementation on the same topic(data-model sizes)?