Re: [Linux-ia64] native ia64 32-bits compile & run on linux-ia64?

[Francois-Xavier Kowalski <francois-xavier_kowalski@hp.com>]

[-- Attachment #1: Type: text/plain, Size: 4076 bytes --]

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 <francois-xavier_kowalski@hp.com> 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



[-- Attachment #2: Type: text/html, Size: 5552 bytes --]