Slashdot Mirror
Porting Linux Software to the IA64 Platform
axehind writes "In this Byte.com 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."
Now I, and the other two IA64 users, will have some programs to run on our Linux-64 boxes!
Can someone please port nethack for us?
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
The major difference between IA32 and IA64 is price.
IA64 is twice as wide as IA32. Therefore, it will be necessary to remember to halve the size of all variables to compensate in your programs. Additionally, we now have to type twice as much for each command or function. It really sucks that we will no longer see Ms. Portman onscreen in Star Wars anymore. So, in conclusion, nuts to IA64: I'm sticking with my Athlon, thank you very much.
Well obviously what we'll see next is a kernel extension that dynamically 'ports' all your applications to IA-64 and transparently migrates them to IA-64 machines elsewhere in the cluster. When Intel's next Great Leap Forward is released, you'll be able to transparently migrate to that as well. In fact it will be so transparent, you won't notice any difference and you can continue working at your 80286-based machine without any interruption.
-- Ed Avis ed@membled.com
I figured this would be coming now, I just started my first Assembly class as a CS undergrad, a whole new group of registers to memorise!
It's not the OS it's the user that sucks. If it's user friendly, you get stupider people. - clinko
Isn't that the instruction set of the Itanium processor that isn't selling worth crap? I was under the impression that intel was going to eventually drop (or push to a back burner) support for this and go with x86-64 (the AMD 64 bit architecture being rolled out with the Opteron.)
Oh please.
return (char *) ((((long) cp) + 15) & ~15);
is not portable.
return (char *) ((((size_t) cp) + 15) & ~15);
is much better.
Ah, porting to homogeneous isa but with a bigger word size. Funny how it's the same old issues over and over again. Structs change in size, bad assumptions about the size of things such as size_t, sizeof(void *) != sizeof(int) (though sizeof(void *) == sizeof(long) seems to be pretty good at holding true here), etc. Of course now there are concerns about misaligned memory accesses, which on IA32 was just a performance hit. Most IA32 types are not used to being forced to be concerned about this (of course many *NIX/RISC types are very used to this).
When things were shifting from 16 to 32 bit (seems like just yesterday, oh wait, for M$ it was just yesterday), we had pretty much the same issues. Never had to do any 8 -> 16bit ports (since pretty much everything was either in BASIC, where it didn't matter, or assembler, which you couldn't "port" anyway).
Speaking of assembler, I guess the days of hand crafting code out of assembler is really going to take a hit if IA64 ever takes off. The assembler code would be so tied to a specific rev of EPIC, that it would be hard to justify the future expense of doing so. It would be interesting to see what type of tools are available for the assembler developer. Does the chip provide any enhanced debugging capabilities (keeping writes straight at a particular point in execution, can you see speculative writes too?). It'd be cool if the assembler IDE could automagically group parallelizable (is that a word?) together as you are coding.
-- Ed Avis ed@membled.com
Debian is already ported to the IA64 -- not sure about the number of packages ported yet, but I know they intend to release the new 3.0 (woody) with a IA64 port.
See here for more details
zadok.org.uk
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?
I'm out of my tree just now but please feel free to leave a banana.
I don't see what is so obvious - isn't one of the selling points of Itanium its backward i386 compatibility? Even if running the 64-bit version of Linux it should still be possible to switch the processor into i386-compatible mode to execute some 386 opcodes and then back again. After all, the claim is that old Linux/i386 binaries will continue to work. Or is there some factor that means the choice of 32 bit vs 64 bit code must be made process-by-process?
Interesting question: which would run faster, hand-optimized i386 code running under emulation on an Itanium, or native IA-64 code produced by gcc? They say that writing a decent IA-64 compiler is difficult, and I'm sure Intel has put a lot of work into making the backwards compatibility perform at a reasonable speed (if not quite as fast as a P4 at the same clock).
-- Ed Avis ed@membled.com
Designing the rest of the API, writing the myprintf() function and dealing with macros with variable number of parameters is left as an exercise to the implementor.
The examples he gives for usage of null pointers are both wrong. When a null pointer (whether written as 0 or NULL) is passed to a varargs function, it should be cast to a pointer of the appropriate type. See the comp.lang.c faq for details. The relevant questions are 5.4 and 5.6. But feel free to read them all!
A while ago, I tried compiling and running my program (http://freespeech.sourceforge.net/overflow.html) 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?
Opus: the Swiss army knife of audio codec
When I was reading the article, the part about no Floating Point in the Kernel stuck out for me. Is this an absolute, or a "don't do it, it's bad"? I looked at the Mossberg presentation on the IA-64 kernel and it looked like they were using some of the fp registers for internal state, but it didn't look like all of them.
Derek
Don't Panic...
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?
Surely porting of applications written in C and other high level languages shouldn`t be difficult. In that respect Itanium is nothing new, a 64bit little-endian architecture.. alpha anyone?
64bit machines have been commercially available for atleast 10 years, you`d think coders would have got used to writing 64bit clean software by now.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
nvidia already has drivers out for Linux/IA64 with some of their higher end cards (quadro line).
Check out ioquake3.org for a great, free, First-Person Shooter engine!
asked in sincerity: does this mean faster chips, or what?
visit the hwky website for a lyrical genius infusion.
Marxism is the opiate of dumbasses
And forget about the problem!
Mats
universe, would be:
printf( "%{pid}\n", pid );
printf( "%{uid_t}\n", getuid() );
etc.
The way it *does* work in the little universe where I am the king is:
This way is arguably better, because it's type safe, and easier on the users. Of course, since it's not Compatible With C, it will never be used by anybody
-- Did you try Tao3D? http://tao3d.sourceforge.net
There's not any conceptual difference in the high-level programmer's view (nor the C programmer's view for that matter) between IA64 and any other POSIX platform, 64-bit or otherwise, either. The code that breaks, unless it's really CPU-specific stuff, breaks because it was coded poorly. Most of the unportable code out there is really unwarranted.
Karma 39 and still posting at 0.
How do you do that? It'd be great for off-topic posts like this one (that should be modded to 0 anyway)
"Save the whales, feed the hungry, free the mallocs" -- author unknown
Java might be a good cross-platform development language, but I haven't seen a JRE for IA-64 at this point.
Is there a JRE for IA-64? How can Java bytecode be executed/interpreted on Itanium systems at this stage?
Does the IA-32 emulation work with a IA-32 JRE? If so, wouldn't the dual layers of Java and IA-32 emulation make it too slow to be practical?
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.
"Intel's Itanium processors handle 64 bits, but the Pentium family handles 32 bits."
"The Hammer family of processors ... will be able to run conventional 32 bit applications ... as well as 64 bit applications"
The press anouncements also got Intel to change its mind and start developing a new 32/64 bit combo chip.
The compiler most certainly can be beaten, even more so today than in the past. I haven't done much asm programming on RISC machines, but on x86, the stuff the compiler puts out is generally garbage. If you're using GCC, it's trivial to beat, as it doesn't know how to deal with the extreme lack of registers on the x86. GCC is constantly going to memory when, with some rearangement, it's possible to keep many more things in registers. The Intel compiler is much better, but it still isn't hard to beat.
Furthermore, with the SIMD stuff in the newer x86 processors (MMX, SSE, SSE2), an asm programmer can get huge speedups which the compiler just doesn't know how to exploit. The Intel compiler will use these features in some instances, but far from optimally. Mind you, you have to know the processor well, and for the big wins, you have to optimize for a specific processor, but if you're doing computationally intensive stuff, the gains can be huge.
The Itanium isn't really a "faster chip". If you count clock cycles, it's actually slower than the mainstream. It gets its speed from better instruction scheduling, so that each clock cycle does more work. The architecture provides for this in several ways:
- The processor can assume that a sequence of instructions can all be executed simultaneously, unless it is told otherwise. This passes the burden of figuring this out from the processor (which has to do it on every run) to the compiler (which will have to do it only at compile time, and has a lot more information to work with too).
- The architecture is designed so that conditional jumps are needed less often. Conditional jumps interfere with efficient instruction scheduling by making it harder to predict which instructions should be executed next, so reducing the need for them is a good thing.
- There are lots of general-purpose registers, which means that fewer instructions are wasted on just shuffling data between the registers and main memory. This is an old trick, but the x86 architecture is even older... when I look at a compiled x86 program, about half of the instructions seem to be that kind of data shuffling. What makes it worse is that main memory is significantly slower than the processor.
Note that the first point creates a problem mentioned in the article: it relies on the compiler to determine which instructions can be executed together. It is difficult for a compiler to take full advantage of this, particularly when compiling C code. It's an interesting area for experimentation, though.