The 64-bit question

Echoes of the past

How does the shift to 64-bit computing emulate the shift from 16-bit to 32-bit that happened 10 years ago?

In the early-to-mid 'nineties, the industry was buzzing with speculation about the 'new' 32-bit computing platform and, more importantly, how it would integrate into the 16-bit environment.

However, the situation then was quite different, with the emphasis firmly on the software rather than the hardware involved. The reason for this was the already wide availability of 32-bit processors. For example, 32-bit RISC processors were commonplace in the enterprise world, and lower down the scale Intel's Pentium was becoming commonplace. Moreover, while the 64-bit processors hitting today's headlines are destined primarily for SMP servers and high-end workstations, the 32-bit processors were everywhere, even in the cheapest of consumer PCs.

Compatibility wasn't an issue either, at least not in the PC world, with both the Intel processors and their clones all based on the same x86 architecture. This enabled them to run existing 16-bit and newer 32-bit applications natively. This is a big contrast to the situation today, where the much-vaunted 64-bit Intel Itanium, for instance, is based on a new architecture with an x86 emulator for backwards compatibility.

Hardware may not have been an issue back then, but software was. As late as 1994, most of us were still running 16-bit DOS-based programs. As the article pointed out, users of workstations and network servers could get 32-bit Unix, Novell NetWare and Windows NT, but most desktops were stuck in an MS-DOS time warp – even those with Windows, as the implementations of the time (Windows 3.1 and Windows for Workgroups 3.11) still ran under DOS, with only minor concessions towards 32-bit processing.

The light on the horizon was a Windows re-write codenamed Chicago, later to become Windows 95. At the time we all though this would at last bring PC desktops into the 32-bit universe to take full advantage of the extra memory and multitasking capabilities such processors had to offer. We now know that it took far longer (until Windows XP just over a year ago) to fully rid the desktop of its DOS roots, but the claims made of Chicago soon came to fruition.
 
There are very few 16-bit apps in mainstream circulation these days, and it would be easy to predict the same eventually happening to 32-bit programs. However, it would not be unreasonable to believe it may be a similar 10 years from the introduction of 64-bit computing before we see 32-bit applications go the way of Retiograptus geinitzianus (a graptolite, which is an extinct type of Paleozoic colonial organism, either planktonic or benthonic, believed to have lived between 375 to 505 million years ago - ed).

Itanium 2 – this time it's serious

The first Itanium may not have made much of a stir, but Intel is going all out to make its successor the flagship of its 64-bit venture.

Intel's involvement seems to be galvanising the market to adopt 64-bit technology more widely. 'Galvanising' is perhaps too strong a word, as the gestation period of the 64-bit Itanium has been long.

After several years talking up the technology, Intel started shipping the first generation of the Itanium in May 2001, almost two years behind the original schedule. A number of system vendors had already announced their intention to use it, but that proved premature. Intel subsequently went to great lengths to position the first Itanium as a test bed for hardware and software developers. As a result, hardly any production systems based on the first Itanium have ever shipped and system and software vendors' enthusiasm has, understandably, waned.

Then along came the McKinley, or Itanium 2 as it's now known, in a low-key launch in July 2002. The Itanium 2 is the 64-bit chip Intel should have waited for; fixing many of the problems in the original design to, potentially, double performance. It includes a wider and faster system bus and, although reduced in size, the Level 3 cache moves on-die which significantly reduces latency. The newer processor also has more issue ports and execution units and a higher core frequency, although the first Itanium 2 chips are still only clocked at 1GHz.

The Itanium 2 requires a different chipset from the original processor, but in future Intel is promising to support at least two generations on the same motherboard. This will enable the next Madison chips (Itanium 3, perhaps) with up to 6MB of on-die cache to plug into the same sockets as the Itanium 2. Madison is slated for the end of 2003, followed by Montecito (Itanium 4, anyone?) a year later.

Low-end versions of the Itanium 2, with less cache, are also expected with a similar, low-end version of Madison (codenamed Deerfield) due towards the end of 2003. Few other details are forthcoming, but clock speeds are bound to increase and it's known that Montecito will be manufactured using a smaller process.

64-bit software

Faster, more capable 64-bit processors are all very well, but to benefit fully from what they have to offer, specialist 64-bit software is also required.

On the plus side, software support for the established platforms is straightforward, most running their own proprietary implementation of Unix – as with Tru64 Unix for the AlphaServer, 64-bit Solaris for Sun's UltraSPARC III products and so on. Some also support their own software, such as OS/400 for IBM's Power processors and OpenVMS on Alpha as well as Linux, in many cases.

The move to embrace the Itanium by some of these (principally HP) shouldn't have any real software implications – the vendor simply adds support for the Intel processor into the Unix involved. Leading application developers such as Oracle and SAP have 64-bit implementations of their products for these platforms already and will continue development and support regardless of what chips the hardware guys opt to use.

Lower down the scale, life isn't so simple. The dominant software platforms are Windows and Linux, and it depends which you favour as to what's available. You can already get 64-bit implementations of most Linux products from the likes of Red Hat and SuSE. These support the Itanium and AMD x86-64 processors, although 64-bit applications that run on such operating systems are less common.

The leading vendors have all pledged allegiance to the 64-bit flag and there are plenty of betas around. However, actual production software is harder to find and may not materialise until this sector of the 64-bit hardware market matures over the next 18 months to two years.

For those looking to run Windows, there's less choice. The only products at present are a 64-bit implementation of Windows 2000 – Windows Advanced Server Limited Edition – and a promised (first quarter 2003) 64-bit version of XP. But the current versions only support Itanium processors, leaving those with 64-bit AMD chips (when they ship) to run 32-bit Windows. Similarly, the first 64-bit versions of the up-coming .NET Server 2003 family will only provide support for the Itanium. Microsoft has committed to supporting the 64-bit AMD Opteron in a later release, but exactly when that will happen isn't clear.

This would appear to put the ball firmly in the Intel court, but a lack of 64-bit applications may work in favour of AMD. As with Linux, the big-name application vendors have all said they will support the 64-bit Windows platform and are, no doubt, busy tweaking and recompiling their products as we go to press. However, few, including Microsoft itself, have shipped anything other than demo and beta test implementation