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

Francois-Xavier Kowalski
2002-01-22T08:43:36Z

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