HP-UX 11i Itanium and endian

[kenneth kahn_4]

Just to make sure I'm understanding this correctly; we currently have software running on various PARisc HP-UX Machines that we need to port over to the Itanium platform. Our first thought was Linux for Itanium, but the problem is all of our current code runs on existing big endian (BE) based UNIX platforms such as AIX, Solaris and HP-UX, and are dependent on BE data structures, and my understanding is Linux for Itanium only runs little endian (LE) (right?). I then though of HP-UX for Itanium, but (and this is where I need some verification) am I correct that the endian 'type' of the OS is dictated by the underlying hardware (right?), so HP-UX for Itanium would still be a LE based OS (right?). I've seen mention on the newsgroups of a BE emulator for HP-UX for Itanium, but that doesn't sound very performance oriented.

If my thoughts are correct, then we have some big BE<->LE issues to resolve, but I thought I'd just verify my facts first.

[Bruno Vidal · Accepted solution]

Hi,
Wrong !! Itanium can be BE or LE. It don't care, the OS configure this at boot time. HP-UX is still BE even on Itanium.

Cheers.

[Massimo Bianchi]

Hi Vidal,
excuse my intromission but i'm interested in the argument.

Big Endian: Most Significant Bytes at right

Little Endian: Most Significant Bytes at left

or vice-versa, it really does not matter.

But, at assembler level, a processor can only be one of the two, MSB at right or left.

I can understand that aftewards O.S. masquerade this, because you use structures in C or whatever language, and the sintax id O.S. and release dependent.


But, for example, if he is writing a driver, he nedds to know exaclty what is the situation.

Massimo

[Bruno Vidal]

Hi,
nope, the itanium can be BE or LE, and yes at assemble level you care, but the boot loader can change this. The Itanium is started be EFI, and EFI is LE, but you can change the endianess of this CPU, so you must really take care when writing drivers of this endianess of your OS: Linux IA64 is LE and HP-UX IA64 is BE.

Cheers.

[Massimo Bianchi]

Thank you very much for the explanation, Vidal.

Massimo

[kenneth kahn_4]

Thanks, that's just what I needed to know (and what I wanted to hear).

[Mike Stroyan]

As a side note, the mentions of emulation under HP-UX on Itanium were probably referring to aries. The aries emulator runs PA-RISC executables on Itanium. You can execute a PA-RISC program just as you would on a PA-RISC system. The exec call sees that the file is PA-RISC and starts it wrapped with the aries library. Aries interprets PA-RISC instructions and translates hot code into native IPF instructions for faster repeated execution of functions. Aries is not performance oriented. It is very convenient when porting from PA-RISC.
Note that you can't compile and link PA-RISC code on Itanium, so programs that involve a link step for customization can't be used on IPF until they are ported to native IPF code.

[Gregory Fruth]

Mike Stroyan wrote:

> Note that you can't compile
> and link PA-RISC code on
> Itanium, so programs that
> involve a link step for
> customization can't be used
> on IPF until they are ported
> to native IPF code.

D'oh! This is exactly what
I didn't want to hear. I
guess I didn't search the
whitepapers closely enough.
Where can I find info on
issues like this? In the
STK docs? Searching for
"Aries" turns up very
little info.

Is there any IPF system
"test drive" program? Before
I committed to buying an IPF
system it would have been
nice to test out my legacy
PA-RISC apps. By now it's
a moot point for me; I guess
the first task for my ZX6000
will be porting my legacy
codes that use the linker
at run time.

[Gregory Fruth]

FYI for future readers:

The test drive program can be found at
http://www.testdrive.hp.com. IPF machines are available,
and accounts are free. I tested my engineering analysis
application (heavily CPU-bound) on their RX2600, and the
performance hit for running under the ARIES PA-RISC
compatibility mode vs. running IPF native was about
5x for my application. The results generated under
ARIES were byte-for-byte identical with the results
generated on PA-RISC (somewhat unexpected, seeing
that the PA-RISC machine was running 10.20 while the
IPF machine was on 11.22). The IPF native results were
a little different, but the differences were small.