Forgot your password?
Linux Software

Porting Linux Software to the IA64 Platform 160

Posted by Hemos
from the hey-now-get-yer-port-on dept.
axehind writes "In this article, Dr Moshe Bar explains some of the differences between IA32 and IA64. He also explains some things to watch out for when porting applications to the IA64 architecture."
This discussion has been archived. No new comments can be posted.

Porting Linux Software to the IA64 Platform

Comments Filter:
  • by Ed Avis (5917) <> on Thursday May 16, 2002 @04:07PM (#3532355) Homepage
    From the article:
    Back in the early '80s, nobody at Intel thought their microprocessors would one day be used for servers; the inherent architecture of the i386 family shows that clearly.
    That's funny, I thought that the i386 was specifically designed to run MULTICS, which was the very definition of a 'server' operating system (computing power as a utility, like water and electricity). The early 80s was the time Intel designed the i386 wasn't it?
  • by morbid (4258) on Thursday May 16, 2002 @04:10PM (#3532373) Journal
    In the article he mentions that itanic can execute IA32 code _and_ PA-RISC code natively, as well as its own, but these features will be taken away sometime in the future.
    Does anyone remember the leaked benchmarks that showed the itanic executing IA32 code at roughly 10% of the speed of an equivalently-clocked PIII?
    I wonder how it shapes up on PA-RISC performance?
    It has to offer some sort of advantage over existing chips, or no one will buy it.
    On the other hand, maybe its tremendous heat dissipation will reduce drastically when they remove all that circuitry for running IA32 and PA-RISC code.
    Which leads me to think, why didn't they invest the time and money in software technology like dynamic recompilation, which Apple did very successfully when they made the transition from 69k to PPC?
  • by NanoGator (522640) on Thursday May 16, 2002 @04:22PM (#3532433) Homepage Journal
    "Intel can't stick with IA64 now that AMD is rolling out their 64bit chips. They'd just fall too far behind the curve."

    Yeah, I mean its not like Intel knows how to develop chips or stay in business or anything.
  • by NanoGator (522640) on Thursday May 16, 2002 @04:29PM (#3532471) Homepage Journal
    " isn't one of the selling points of Itanium its backward i386 compatibility?"

    If I remember clearly, the 386 instructions are interpreted instead of being on the chip. That means that those instructions will execute alot slower. It would work, but it wouldnt work well. Its nice because you could transition to IA 64 now and wait for the new software to arrive.

    Personally, I dont think that selling point is that worthwhile, but Ill let Intel do their marketing without me.

  • by jmv (93421) on Thursday May 16, 2002 @04:39PM (#3532531) Homepage
    A while ago, I tried compiling and running my program ( on a Linux PPC machine and (to my surprise) everything went fine. Does that mean that it should work on ia64 too since (AFAIK) both are big-endian 64-bit architectures?
  • by Russ Steffen (263) on Thursday May 16, 2002 @04:41PM (#3532540) Homepage

    What's really funny is that I have an Intel propoganda book for the "brand new 80386." It spends two whole chapters talking about how the 386 is the perfect CPU for LAN servers. Of course, it also had to spend almost that much space describing what a LAN is and what a server might do, since very few people had ever heard of a LAN at that point, much less had one.

  • by 00_NOP (559413) on Thursday May 16, 2002 @05:13PM (#3532735) Homepage
    When I started messing about with computers 8 bit chips were stanard on the desktop and 4 bit in the embedded sphere.

    Within four years 16 bit was the emerging standard for the desktop and four more than that 32 bit was emerging.

    In the 12 years since then, well...

    32 bit rules in both the desktop world and in the embedded world. Can someone tell me why we aren't on 128 bit chips or more by now? Why do 64 bit chips not amke it - is this a problem of the physics of mobos or what?
  • by hey! (33014) on Thursday May 16, 2002 @05:54PM (#3533007) Homepage Journal
    386 designed for Multics? I doubt it. Running multics on a 386 would be like scoring Beethoven's ninth for a kazoo.

    Multics was pretty much tied to it's unique mainframe hardware with loads more weird addressing and virtual memory management features that would never have fit the paltry 275,000 transitors of the 80386. Also, at the time (1985) Multics was a legacy system; Unix was seen the operating system of the future, in particular because it was portable to microprocessors and didn't require much special hardware.

  • by leek (579908) on Thursday May 16, 2002 @11:07PM (#3534492)
    The article is inaccurate.

    First of all, IA-64 is now called IPF (Itanium Processor Family), although I've heard rumors that this is changing again, to a third name.

    Although the initial acceptance of Itanium-based servers and workstations has been slow, there is little doubt that it will eventually succeed in becoming the next-generation platform.

    Actually, as /. readers know, there have been some doubts. Itanium is 5 years late. Right now Itanium ranks lowest in SPEC numbers, and Itanium 2 (McKinley), while it addresses some of the problems, can't expect to compete with Hammer or Yamhill when it comes to integer code.

    For tight floating-point loops, Itanium 2 is great -- 4 FP loads + 2 FMAs per clock. But on integer code with lots of unpredictable branches, the entire IPF architecture leaves a lot to be desired. Speculation and predication were supposed to address that, but it is very hard for compilers to exploit speculation, and predication does not address issues such as the limitations of static scheduling.

    (Also, Itanium 2 removes any benefit that the SIMD instructions had on Itanium, because on Itanium 2, SIMD instructions such as FPMA are split and issued to both FPU ports, negating any performance benefit they had on Itanium. So while Itanium can perform 8 FP ops per clock with FPMA, Itanium 2 can only perform 4 FP ops per clock. This does not look good for the future of IPF implementations. But Itanium 2's bigger memory bandwidth is probably more important than SIMD instructions anyway. Itanium 2 is built more for servers, while Itanium is built more for workstations, which might benefit from SIMD MMU instructions, although the rest of Itanium, and its price/performance, make almost anything else better.)

    Superscalar processors with dynamic scheduling are improving much better than was expected during IPF's design (witness the P4 and AMD chips). So Itanium's static instruction scheduling design may be a liability more than an asset today. It puts considerable burden on the compiler.

    The x86 emulation and stacked register windows take up a lot of real estate on the chip, which could be better used for something else.

    The IA64 can be thought of as a traditional RISC CPU with an almost unlimited number of registers.

    Nonsense!!! No CPU has unlimited registers. When writing code by hand or with a compiler, registers are a limited resource which are used up quickly.

    And even though IPF has "stacked" general purpose registers which are windowed in a circular queue with a lazy backing store, these windows are of limited utility in real code. How many times does real code use subroutine calls which can take heavy advantage of register windows, before call branch penalties start to negate any benefit the windowing provides?

    It's a great idea in theory, but windowing just adds to the complexity of the implementation, taking up real estate that could be better used elsewhere.

    The IA64 has another very important property: It is both PA-RISC 8000 compatible and IA32 compatible. You can thus boot Linux/IA64, HP-UX 11.0, and Windows on an Itanium-powered box.

    Absolutely false: PA-RISC emulation was dropped years ago, before the first implementation, although it was originally planned. Also, HP-UX 11.0, which is PA-RISC only, is not supported on IPF. Only HP-UX 11.20 and later are supported. HP-UX 11.22 is the first customer-visible release of HP-UX on IPF.

    The endianism (bit ordering) is still "little," just like on the IA32, so you don't have to worry about that at all.

    Misleading -- the endianism is still a part of the processor state (i.e. context-dependent). This means it can be both big and little endian, and can switch when an OS switches context. HP-UX, for example, is big-endian on IPF.

    The rest of the article had generic ANSI C programming tips which everyone knows already -- nothing specific to IPF.

Your own mileage may vary.