Trillian Project Release Linux for IA-64
Smack writes "The Trillian developer's release of the Linux port to Intel's new IA-64 architecture was made available yesterday on kernel.org. Q & A from the press conference are also available in PDF format. " At the keynote done this morning at LWCE, some of the engineers demonstrated the code - very, very cool. The examples were running Doom as well as an excellent rendering of a skull.
--
"Convictions are more dangerous enemies of truth than lies."
And it's obvious from this page from a document that's been out for quite a while that it has 128 general-purpose regs and 128 floating-point regs, although it uses a register window scheme so you may have to shuffle windows to get at more than the 32 global registers and the 32 registers in the current window (at least for the general registers).
Documentation for the user-mode side of IA-64 has been available for a while; take your choice of Intel's PDF version, HP's PDF version, or HP's HTML version.
(There's some other IA-64 documentation on the HP site, e.g. the IA-64 Software Conventions and Runtime Architecture manual and, if a link to it hasn't already been posted, (an old - August 1999) paper on "The Making of Linux/ia64".
Is there any information on how the IA64 is supposed to perform compared to current 64-bit chips (like the Dec Alpha)? I mean, are we waiting around just to get another been-there-done-that?
"Being right too soon is socially unacceptable." - Robert Heinlein
What about Slartibartfast? Would have been a cooler name than Trillian "Intel Slartibartfast Inside"
Syllable : It's an Operating System
PAE is a 36 bit physical address format. The Linux development kernel uses that mode as well for userspace pages that won't be the target of DMA (DMA is not supported for memory that cannot be addressed in 32 bits due to hardware limitations). Fortunatly, it's not braindead as segmented memory was in real mode.
The zoning of physical memory in the kernel will (probably has) come in handy for the merced port since it will need to deal with 32 and 64 bit bus mastering PCI for some time to come.
"Ford" was already taken.
"Prefect" sounds too close to "perfect" -- no way intel holds themself to THAT standard.
"Zaphod" and "Beeblebrox" are to hard to remember.
(Tomorrow I will look back on this post and say, "My God, what was I thinking?")
-- In the future, everyone will code Perl for 15 minutes. --
At one point (about a year back) I was, but the picture has all changed.
Most of the software I have is distinctly x86 bound. Most of it isn't open, and came to me via binaries. A large portion of it runs on an OS from that company in Washington State. Almost none of it can pretend to be anything other than games.
For my money, I can't think of anything that looks more interesting in the processor market than TransMeta's Crusoe chip. Technically this is still on the "coming-to-market real-soon-now" list, but so is the Merced (now officialy IA-64).
Given that, I'd rather settle for continuing to be able to run my existing software. I upgrade my system bit-by-bit. Compatibility and continuity are very important!
... and today's pet project has
From the FAQ,
Q6: What is the contribution of each of the members of the Trillian project?
A6: Cygnus is porting GNUPro Toolkit (GCC, G++, GDB). HP is provided the initial kernel and glibc port, and continues to work on the kernel. IBM is providing kernel support. Intel is providing IA-32 support, IA-64 platform port, Apache port, and various drivers. SGI is providing an optimized C compiler and kernel support. VA is leading the project and providing kernel support, boot loader, commands and libraries, Xfree86, Mesa, E & GNOME, and the GIMP.
Wow. Look at all the large companies behind this. IBM, SGI, Intel. All big players. One of the biggest problems that linux faces with hardware, is that of always playing "catch up" with Windows for hardware support. Efforts such as these can only be considered to be a Good Thing for Linux in general.
Speaking as a computer engineer, the IA-64 is one of the few processors that feels truly designed from the ground up.
As such, one of the things Intel did very right was avoiding the craziness when switching between IA-32 and IA-64 code. It looks VERY straightforward: a new instruction in the IA-32 instruction set that jumps to IA-64 code and an IA-64 instruction that jumps to IA-32 code. The IA-32 registers are mapped into the lowest 32 registers on the IA-64 side. This is very much unlike the (IMO) stupid way Intel did protected mode/real mode switching in the IA-32 instruction set, which is complex and downright nasty at times.
As to the other features of the processor (the 128 GP integer registers set up in a processor-managed rotating stack, the 128 FP registers, the 3 different sub-instruction-sets that allow the processor to be seperated into modular pieces, predication, and explicit parallelism), they are shockingly well-designed and make sense from both an engineering and programming viewpoint. I am very much looking forward to running on one!
The crux of the matter is that IA-32 applications should run with no modifications under a properly written IA-64 OS and it should even be possible to run a IA-32 OS with no problems on an IA-64 processor!
"You can represent this entire problem as a 3x2 matrix"