Slashdot Mirror

"Linux wil run on most, if not all desktop computers currently running Windows."

In fact, Linux runs on about 23 additional architectures that Microsoft can't even remotely support with their most-flexible embedded target.

• Diverse PDA / embedded / microcontroller / router devices:
  • Advanced RISC Machines, Ltd. ARM family (StrongARM SA-1110, XScale, ARM6, ARM7, ARM2, ARM250, ARM3i, ARM610, ARM710, ARM720T, and ARM920T)
  • Analog Devices, Inc.'s Blackfin DSP
  • Axis Communications ETRAX series ("CRIS" = Code Reduced Instruction Set RISC architecture)
  • Elan SC520 and SC300
  • Fujitsu FR-V
  • Hitachi H8 series
  • Intel i960
  • Intel IA32-compatibles (Cyrix MediaGX, STMicroelectronics STPC, ZF Micro ZFx86)
  • Matsushita AM3x
  • MIPS-compatibles (Toshiba TMPRxxxx / TXnnnn, NEC VR series, Realtek 8181)
  • Motorola 680x0-based machines (Motorola VMEbus boards, ISICAD Prisma machines, and Motorola Dragonball & ColdFire CPUs, and Cisco 2500/3000/4000 series routers)
  • Motorola embedded PowerPC (including MPC / PowerQUICC I, II, III families)
  • NEC V850E
  • Renesas Technology (formerly Hitachi) SH3/SH4 (SuperH: link1 link2)
  • Samsung CalmRISC
  • Texas Instruments's DM64x and C54x DSP families
• Intel 8086 / 80286 .
• Intel IA32 family: i386, i486, Pentium, Pentium Pro, Pentium II, Pentium III, Xeon, and Pentium IV processors, as well as IA32 clones from AMD, Cyrix, VIA, IDT, Winchip, NexGen, Transmeta, VIA C3 Ezra "CentaurHauls", and others.
• Intel/HP IA64: Trillian/Itanium/Itanium2
• AMD x86-64 Hammer family (including AMD Opteron)
• Motorola 68020-68040 series (with MMU): m68k Mac, Amiga, Atari ST/TT/Medusa/Falcon, HP/Apollo Domain, HP9000/300, sun3, and Sinclair Q40.
• Motorola/IBM PowerPC family: Most PowerMac (including G3/G4/G5) / CHRP / PReP / POP, Amiga PowerUP System, and IBM PPC64 (AS/400, RS/6000).
• MIPS

Linux has been running on the ia64 since mid-2000, no need to go to XP for that.

Caldera, yes, the same Caldera that acquired the server part of Old SCO in August 2000 and renamed itself The SCO Group in 2003, created an IA-64 distribution.

Take a peek here:

http://linuxia64.org/

Interesting that HP is one of the companies SCO is so cozy with (the other one is sun), maybe HP even had the rights to distribute that code. Nevertheles the copyright is SGI. But what probably really happened was that HP submitted a whole bunch of code developed in the Trillian project in cooperation with others (Caldera for example) and the snippet was just part of a huge patch.

As an example, the author takes issue with the SCO's claim that IBM must have stolen SCO trade secrets in order to improve Linux by saying "OK, then, diff the code."

Perhaps. But if I were you, do what I did: download the kernel changelogs for 2.4 (and if you like 2.2) and grep them for ibm.com (i.e. commits from someone at IBM).

For example, I fetch the changelogs from here. And then I ran:

$ grep -il "ibm\\.com" *

What?!? You're not running linux?!? Shame on you!

As you will see, most of the checkins involve bug fixes for IBM's JFS, some patches for IPV6, and few ones for s390. Gotta love version control, eh?

Suppose part of the validation test set for Monterey consisted of a stress test written by SCO and owned by SCO.

Project Monterey was a plan that never happened. It was a plan to put Unix on IA-64 machines that died during conception. What we have is a lot of white papers on the subject but no written, working code. Of course I could be wrong, and if there was working code it would have probably been written by IBM developers anyway with a "Copyright (c) 2000 IBM Corp." near the top of the sources.

Let us further suppose that code was used in the Linux development work, and found a key set of bugs. (Don't tell me it isn't possible that it would have been -- developers tend to think of tools as just tools, and forget that they may be encumbered.)

Probably, but one of the accusations SCO makes is that IBM allegedly handed out Unix code owned by SCO to Linux kernel hackers. And that Linux would not have advanced if IBM had not handed out said code. But so far, all code commits from IBM appear to be mostly patches to existing code. What's more SCO accuses IBM of handing out code from SCO Unix to improve Linux's SMP capabilities. However, Linux's SMP support was one of the primary reasons why IBM adopted Linux in the first place (for proof, see my earlier post in this thread). Ergo, by adopting an Open, Freely Available variant of Unix with SMP support would lessen their development efforts.

What I find rather interesting is Caldera's Logo on the IA-64 Linux page. And it lists them as one of the players in this project. And even more interesting is the missing links on SCO's website pointing to details of the Itanium Netfarm they have presumably made available to IA-64 Linux developers.

- casts polymorph other spell on grue... 0xB00F!

It looks like all the big Linux distributions have gotten together to support the IA-64 Linux development.. This was the first hit on search "Linux IA-64" on google.


http://www.linuxia64.org/

Working distributions date back from 03/2000

Straight from their page:

IA-64 Linux Distributions
# Caldera Systems (initial release 8/4/00) Download at ftp.caldera.com/pub/OpenLinux64
# Debian (initial release 8/10/01) Download at www.debian.org/ports/ia64
# Red Hat (initial release 5/17/00) Download at ftp.redhat.com/pub/redhat/ia64
# SuSE (initial release 6/13/00) Download at ftp.suse.com/pub/suse/ia64
# TurboLinux (initial release 3/13/00) Download at www.turbolinux.com/ia64.html

Their short list of representative companies include: Caldera Systems, CERN, Debian, Hewlett Packard, IBM, Intel, Linuxcare, NEC, Red Hat, SGI, SuSE, TurboLinux, and VA Linux Systems.

If you search their site, you'll see a few emails from Linus in their mailing list archives, so he's obviously involved at least to a degree (I couldn't imagine him not being involved). I dare say he's educated in the matter, and would know all the in's and out's of say putting together an OS. :)

I'm sure support will be included eventually.. Well, maybe not.. I know Linux will run on SGI, DEC Alpha, ARM (I'm running Linux on a Compaq iPaq with an ARM CPU), so maybe they'll leave it as a patch and let folks do seperate distributions.

I guess it's all in how widely used a processor is.. Not the average Joe has an SGI, Alpha, or Itanium at their house. (I'll keep quiet about the 150Mhz SGI Indy that we use as a doorstop).

MS already has 64-bit Windows that runs on a chip that's currently shipping. For that matter, so does Linux.

Apple moving into this market is unlikely to provide them a bump. If an ( Intel && ( Windows || Linux ) ) user wants 64-bit today, they can go get it.

Linux already runs on several 64bit platforms, including IA 64, so that argument is bullshit.

No biggie, but TurboLinux was first, in May, and RedHat was earlier, by a month. See the Linux on IA-64 page.

Though I don't know if these were actually up and running, or on the simulator. I'm just not checking out Itanium stuff, for FP speed.

In general, the Itanium has seen quite poor adoption rates and even Intel/HP admit that their initial public silicon is really only fit for software developers and platform work (due to low performance, and altready established players in the 64-bit field).

Do you think that IPF64 line will see any kind of broad industry adoption? Will it become just like rest of the (non-embedded) processor architectures designed since the x86 -- constantly fighting for 5% of the market? Do you think the AMD Hammer architecture will be a meaningful player in the field?

Since your group is a key player in the Linux on IA64 and GCC for IA64 projects, can you give us any status information about recent developments in the project since the IA-64 Summit?

Thanks,

-Chris

Some people may find this interesting: GCC for IA64 Summit Talks about some of the optimization problems with GCC. Here's one juicy bit:

Suneel Jain: Is the goal of having a higher-level tree representation
to do inter-procedural optimizations from information written to
disk?

Mark Mitchell: This question comes up a lot. The sticky issue is that
the FSF is morally opposed to doing this. The aim of the FSF is not
to produce the best compiler, but to convince the world that all
software should be free. The concern is that writing out the
representation to disk would allow a vendor to use a GCC front end,
write the IL to disk, read it back in, and graft proprietary code
into GCC in a sneaky way to get around the GPL. This is a very
firmly held position in the FSF.

Better link ...http://www.linuxia64.org/

Bah! Bah!

You should of pointed them here.

It was first after all.

What you meant to say (and what the article said), is that 464mm^2 is size of the actual die size of the processor This includes the CPU and the caches. The CPU is a relatively small portion of the processor die, and noting there is 3MB of L3, the total cache may amount to 2/3 of the die size. The square on top of the athlon is also the entire processor die: cpu, caches and all.

Also, L3 cache can never perform "equivalently" to L2 or L1 cache unless it runs at core speed. And I can tell you now, it doesn't -- or they wouldn't need L1 and L2. The L3 cache probably runs at something like 10 access cycles or more. It's not difficult to engineer 10 access cycles into any pipeline -- it's impossible. Which is precisely why it's not L1.

I'm quite sure the engineers at Intel have done their modeling homework and determined that however fast the L4 memory may be, the L3 will improve performance by that much more.

Remember, this processor is not meant to go on you or any other Joe Sixpack's desktop. It is meant to sit inside the workstations on the desks of engineers and in the racks of high-bandwidth servers. These platforms are specifically designed to run hundreds of tasks simultaneously and handle staggeringly high memory bandwidths. It has nothing to do with "complicated instructions." The L3 exists for swapping out large pages of memory in large bursts from a significantly larger sized L4 memory (think on the order of 100's of GB) from L5 memory (local drives and SANs) that has an incomprehendable virtual memory space.

This has absolutely nothing to do with mainstream. I'm quite certain an OS already exists that will run on the platform. An IA-64 Linux is well under way (try http://www.linuxia64.org) and you can bet that Compaq, HP, Dell, and Intel have put a total of more than 100x your lifetime earnings into developing software for that platform.

Intel could not care less whether you or 99.9% of the /. readers out there ever buy an IA-64. They don't give a crap about your market segment, but I'm sure if you want to drop $10K+ on a IA64 workstation, be my guest. Your choices are limited. Either choose IA64 or UltraSparc. Or maybe if AMD ever gets a design win, you might get a chance to buy a Hammer box.

These numbers shouldn't suprise anyone. If you want to learn more about gcc's performance weaknesses and how to improve it, read this report.

It wouldn't surprise me if the bulk of this 40% difference in performance has been achieved by proper data-prefetching.

The gcc "open projects" page gives people a good idea of what remains to be done on gcc. The minutes of the IA-64 GCC summit are especially interesting and informative, because it gives a good idea of the current state of GCC and also what GCC needs to be a competitive compiler in the future.

Bottom line: Do not be surprised when commercial compilers beat gcc performance. It's catching up, but it's still got a long way to go.

GCC Home Page

I'm not an Itanium fan, because very long instruction word machines require a near-omniscient optimizing compiler to find enough concurrency in the code to keep the hardware busy. (Smart people are, at this moment, beating their heads against the wall on that problem. Assuming, of course, that the HP compiler team didn't get laid off.) Respected CPU architecture designers have looked at the thing and groaned. It's viewed as a move by Intel to move the industry from an open CPU architecture to a proprietary one over which Intel has a monopoly. Intel has enough patents on the Itanium to prevent cloning. The architecture is so wierd that it requires lots of new inventions to make it work, so Intel can get strong intellectual property rights by going this route. (By comparison, the AMD Sledgehammer 64-bit architecture is a straightforward extension of IA-32, minus some of the cruft.)

But if you want an Itanium machine, you can get one. Although, unusually for Dell, the Dell product page doesn't mention price or have a "Buy" button, so Dell isn't serious about selling it.

The unfortunate truth is that the Intel compiler isn't entirely theirs to sell (or at least 'open up' for GCC to consume) - the front end is an Edinburgh Portable Compilers' one (hope I spelt that right) and the back end could never be worked into GCC without tearing it (GCC) up completely, and reimplementing the whole thing...

Free beer isn't bad, if it quenches your thirst ;)

1. The article is not about providing a specially-designed chip that runs Linux. The article is about the fact that chip designers are now getting interested in making sure Linux runs on their chipsets especially now that it looks like Linux due to its Open Source nature will be quicker at supporting new chipsets than Microsoft's offerings as is witnessed by how long Linux supported Itanium versus Microsoft's recent announcement.
   
   Similarly it looks like Linux on the AMD's Hammer chipset is already way underway as a project while according to the article Microsoft has no current plans to support that chipset.
   
   
2. What exactly do you mean by the Linux architecture is too fragmented to ever allow for a chip that runs Linux?
   

Intel's Extensible Firmware Interface specification contains the spec for GPT. All systems incorporating EFI (currently, this is only IA-64 systems) need use GPT, for others it is optional.

I wrote the Linux IA-64 kernel GPT support, and it has been included in the IA-64 kernel port since September 2000. It allows use of either MBR-style or GPT-style partition records per disk. With minor tweaking, it could be used on Linux IA-32, but it is not currently.

Boot loaders such as LILO remain unaffected. LILO takes a file system location (i.e. /boot/vmlinuz), from which it asks the kernel for the physical location of that file on the disk (i.e. where in /dev/sda is the file?). The file location is entirely independent of the partitioning strategy, thus LILO works with both MBR-style and GPT-style partitioning. Linux IA-64 uses its own boot loader (elilo.efi) which again does not need to be aware of the partitioning strategy of a given disk.

Partitioning tools such as fdisk and GNU Parted need to become GPT-aware. I have created a patch for GNU Parted and have made it available to the IA-64 distributions. It could use a bit of cleanup, but is quite functional. I don't believe that anyone has written GPT support into fdisk, and would encourage anyone who wishes to please do so.

I've also written a new Linux IA-64 application "efibootmgr" which manages the EFI Boot Manager options (as defined in the EFI spec above). This tool is both MBR and GPT-aware, and allows for booting your OS off of any disk/partition in your system provided the partition contains a FAT-12,-16, or -32 file system. Additional work will go into EFI in the future to add ext2 file system awareness to avoid even this restriction.

All of these topics have been discussed on the Linux IA-64 developer mailing list. If you care to join the Linux IA-64 developer community, please see www.linuxia64.org.

You really could see this comming. With Caldera buying bits of SCO IBM has lost their partner in Monterey and it makes little sense for them to create another UNIX by themselves. They've already got AIX and as partners in the Trillian project they'll have a Linux IA-64 solution as well. IBM's complete adoption of Linux may have killed this project regardless of SCO's sale, but I suspect that was the final nail in the coffin.

Monterey was the joint effort of IBM, SCO, and two others to port a high-end, enterprise class unix to Itanium (IA-64). The excitement driving the buzz was that Monterey looked like the migration path for AIX.

Looks like Linux inherits all that buzz.

GO TRILLIAN

greetings, eMBee.
--

Work is being done in this direction. When the Itanium comes out Linux will definately boot and most of the applications should work as well. It has already worked on a simulation.

The responsible group is the Trillian Project which has support from Intel, IBM and other industry heavy weights.
Check it out here http://www.linuxia64.org/