Intel has begun selling programming tools that let developers create software that supports 64-bit x86 chips, an important step in making the new generation of processors useful.
Intel earlier this year began selling Xeon and Pentium 4 processors with 64-bit extensions called EM64T that enable the processors to easily use more than 4GB of memory. Intel's 64-bit chips came more than a year after rival Advanced Micro Devices came out with its own version, the AMD64, in its Opteron and Athlon 64 products.
The compilers create code for either Intel or AMD chips, said James Reinders, director of marketing for Intel software development products. "Our customers are interested in producing code that runs well on their customers' machines. Some percentage of that is going to be non-Intel," he said. "Our code works at least as well as any other compiler for AMD's processors."
Intel's compiler will come in versions for Linux, which already is available in 64-bit versions from Red Hat and Novell, and for Windows, which because of delays won't support 64-bit x86 chips until 2005.
Among the customers for the programming tools are IBM and Oracle, who build their database software with it, Reinders said. And even though open-source programmers overwhelmingly prefer the GCC compiler -- itself an open-source project -- Red Flag Linux and the MySQL database use it, Reinders said.
The computing industry is avidly monitoring the spread of 64-bit x86 chips, which also can run the prevailing 32-bit software. Intel for years favoured a different 64-bit design, Itanium, which can run 32-bit x86 software only slowly and awkwardly. But Intel now positions Itanium only for higher-end machines, and the chip's biggest promoter, Hewlett-Packard, discontinued selling Itanium workstations in favour of 64-bit x86 models.
The compiler costs $399 for compiling C and C++ programs for Windows and Linux; versions to compile programs written in Fortran range from $499 to $1,399.
Sun Microsystems, a relatively new convert to the x86 server market, is aggressively pushing its Solaris operating system for the chips, but Intel doesn't plan to support it. "We want to be responsive to our customers, and we see them moving away from vendor-specific Unix to x86 Linux, so that's where our offering is focused," spokesman Michael Houlihan said.
Intel's revenue stems chiefly from chips, but the company's software efforts are a critical catalyst to making chip improvements useful. Right now, the company is focusing not just on 64-bit extensions, but also on new chips that are better at doing multiple jobs at once.
The first generation of these multitasking chips came with Intel's hyperthreading technology, which lets a processor quickly flick to a second instructions sequence, or thread, when the primary thread is idly waiting for new data. The next generation of the technology will come in 2005, when Intel releases dual-core chips that combine two separate processing cores onto the same slice of silicon.
From a software perspective, multithreading and multiple cores mean essentially the same programming problem: how to write software that can do multiple tasks simultaneously. It's a tricky issue, and mainstream software has only rudimentary support for it, Reinders said.
Sometimes programmers split tasks into two threads -- one for a program's main engine and one for its user interface, for example -- but that's a matter of programming convenience, not performance, Reinders said.
The next step will be breaking down software modules into separate threads. For example, a video game that features simulated physical effects might break down each effect into separate threads rather than having one thread for the entire physics engine, he said.
To make this change easier, Intel sells other software tools. Its VTune software can monitor the performance of individual threads so programmers can see how efficient various approaches are. And its Thread Checker software checks software as it runs to find instances when two threads are incorrectly synchronised.
"It's a bad thing if one (thread) has to write data and the other has to read it and they're out of order," he said, and worse, synchronisation errors can be hard to track down because they aren't predictable. "The experience of moving your code to a threaded environment can be very frustrating."
