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 n0ano@indstorage.com 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). > Jes Sorensen wrote: >Francois-Xavier Kowalski writes: > >>n0ano@indstorage.com 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. >>> >>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. > >>>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. > >>Maybe the question above means mixing IA32 & IA64 instructions within >>the same execution context & is forbidden. >> > >It's not possible. > Regards. FiX -- 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