Long road to 64 bits

FOCUS

System Evolution

THE LONG ROAD TO 64 BITS
24 October 2006 ACM QUEUE

Double, double, toil and trouble—Shakespeare, Macbeth

JOHN R. MASHEY, TECHVISER

rants: feedback@acmqueue.com

Shakespeare’s words (Macbeth, Act 4, Scene 1) often cover circumstances beyond his wildest dreams. Toil and trouble accompany major computing transitions, even when people plan ahead. To calibrate“tomorrow’s legacy today,” we should study “tomorrow’s legacy yesterday.” Much of tomorrow’s software will still be driven by decades-old decisions. Past decisions have unanticipated side effects that last decades and can be difficult to undo.
more queue: www.acmqueue.com

For example, consider the overly long, often awkward, and sometimes contentious process by which 32-bit microprocessorsystems evolved into 64/32-bitters needed to address larger storage and run mixtures of 32- and 64bit user programs. Most major general-purpose CPUs now have such versions, so bits have “doubled,” but “toil and trouble” are not over, especially in software. This example illustrates the interactions of hardware, ACM QUEUE October 2006 25

FOCUS

System Evolution

THE LONG ROAD TO 64 BITSlanguages (especially C), operating system, applications, standards, installedbase inertia, and industry politics. We can draw lessons ranging from highlevel strategies down to programming specifics.

Running out of address space is a long tradition in computing, and often quite predictable. Moore’s law increased the size of DRAM approximately four times every three to four years, and by themid-1990s, people were able to afford 2 to 4 GB of memory for midrange microprocessor systems, at which point simple 32-bit addressing (4 GB) would get awkward. Ideally, 64/32-bit CPUs would have started shipping early enough (1992) to have made up the majority of the relevant installed base before they were actually needed. Then people could have switched to 64/32-bit operating systems and stoppedupgrading 32-bit-only systems, allowing a smooth transition. Vendors naturally varied in their timing, but shipments ranged from “just barely in time” to “rather late.” This is somewhat odd, considering the long, well-known histories of insufficient address bits, combined with the clear predictability of Moore’s law. All too often, customers were unable to use memory they could easily afford. Some designdecisions are easy to change, but others create long-term legacies. Among those illustrated here are the following: • Some unfortunate decisions may be driven by real constraints (1970: PDP-11 16-bit). • Reasonable-at-the-time decisions turn out in 20-year retrospect to have been suboptimal (1976-77: usage of C data types). Some better usage recommendations could have saved a great deal of toiland trouble later. • Some decisions yield short-term benefits but incur longterm problems (1964: S/360 24-bit addresses). • Predictable trends are ignored, or transition efforts underestimated (1990s: 32 transitioning to 64/32 bits). Constraints. Hardware people needed to build 64/32bit CPUs at the right time—neither too early (extra cost,
26 October 2006 ACM QUEUE

FUNDAMENTAL PROBLEM (LATE1980S)

no market), nor too late (competition, angry customers). Existing 32-bit binaries needed to run on upward-compatible 64/32-bit systems, and they could be expected to coexist forever, because many would never need to be 64 bits. Hence, 32 bits could not be a temporary compatibility feature to be quickly discarded in later chips. Software designers needed to agree on whole sets of standards;build dual-mode operating systems, compilers, and libraries; and modify application source code to work in both 32- and 64-bit environments. Numerous details had to be handled correctly to avoid redundant hardware efforts and maintain software sanity. Solutions. Although not without subtle problems, the hardware was generally straightforward and not that expensive—the first commercial 64-bit...