Communications - January 2009

back to 1977, knowing what we know now, we could have made all this easier simply by insisting on more consistent use of typedef. In 1977, however, it would have been difficult to think ahead 20 years to 64-bit micros—we were just getting to 32-bit minis!

This process might also have been eased if more vendors had been further along in 64-bit implementations in 1992. Many people had either forgotten the lessons of the PDP-11/VAX era or had not been involved then. In any case, the 64/32 systems had a more stringent requirement: 64-bit and 32- bit programs would coexist forever in the same systems.

Timing is important to creating good industry standards. Too early, standards may be written with insufficient practical experience because no one has real implementations from which to learn. Too late, and vendors may well have committed to numerous incompatible implementations. In between, a few groups have early implementations to help inform the standards. Perhaps by accident, the 64-bit C standards were reasonably well-timed.

lessons

˲ Standards often get created in nonstandard ways, and often, de facto standards long precede official ones.

˲ Reasonable people can disagree, especially when looking at different sets of data.

˲ Sometimes one must work with competitors to make anything reasonable happen.

˲ Programmers take advantage of extra bits or ambiguity of specification. Most of the arguments happen because application programmers make differing implicit assumptions.

˲ Code can be recompiled, but once data gets written somewhere, any new

code must still be able to describe it cleanly. Current software is rarely done from scratch but has to exist inside a large ecosystem.

˲ We might never build 128-bit computers, but it would probably be good to invent a notation for 128-bit integers, whose generated code on 64-bit CPUs is about the same as 64-bit code is on 32-bit CPUs. It would be nice to do that long before it is really needed. In general, predictable long-term problems are most efficiently solved with a little planning, not with frenzied efforts when the problem is imminent. Fortunately, 128-bitters are many years away, if ever (maybe 2020–2040), because we’ve just multiplied our addressing size by four billion, and that will last a while, even if Moore’s Law continues that long! In case 128-bit happens in 2020, however, it would be wise to be thinking about the next integer size around 2010.

Of course, when the S/360 was introduced, IBM and other vendors had 36- and 18-bit product lines. In an alternate universe, had the S/360 been a 36-bit architecture with four 9-bit bytes/word, most later machines would have been 18- and 36-bit, and we would just be starting the 36-bit to 72-bit transition.

˲ Hardware decisions last a long time, but software decisions may well last longer. If you are a practicing programmer, take pity on those who end up maintaining your code, and spend some time thinking ahead. Allow for natural expansion of hardware, hide low-level details, and use the highest-level languages you can. C’s ability to make efficient use of hardware can be both a blessing and a curse.

conclusion

Some decisions last a very long time. The 24-bit addressing of 1964’s S/360

is still with us, as are some side effects of C usage in the mid-1970s. The transition to 64-bit probably took longer than it needed for a host of reasons. It’s too bad that people quite often have been unable to use affordable memory for solving performance problems or avoiding cumbersome programming.

It’s too bad there has been so much “toil and trouble,” but “double” for microprocessors has been accomplished, and “double” for software is at least under way, and people have stopped argu-ing about the need for 64-bit micros.

References

1. aspen Data model committee. 64-bit programming models: why lP64? (1997–1998); www.unix.org/ version2/whatsnew/ lp64_wp.html.

2. bell, c.g. and mudge, J.c. the evolution of the PDP- 11. Computer Engineering: A DEC View of Computer System Design. c.g. bell, J.c. mudge, and J.e. mcnamara, eds. Digital Press, bedford, ma, 1978.

3. Josey, a. Data size neutrality and 64-bit support (1997); www.usenix.org/publications/login/ standards/ 10.data.ht ml.

4. mashey, J. languages, levels, libraries, longevity. ACM Queue 2, 9 (2004–2005), 32–38.

5. mashey, J. 64-bit computing. BY TE (sept. 1991), 135–142. 9 (the complete text can also be found by searching google groups comp.arch: mashey byte 1991).

6. rationale for international standard—Programming languages—c; www.open-std.org/jtc1/sc22/wg14/ www/docs/n897.pdf (or other sites).

7. strecker, w. D. Vax-11/780: a virtual address extension to the Dec PDP- 11 family. Computer Engineering: A DEC View of Computer System Design. c.g. bell, J.c. mudge, and J.e. mcnamara, eds. Digital Press, bedford, ma, 1978.

8. unix specification; adding support for arbitrary file sizes; www.unix.org/version2/whatsnew/lfs20mar. html.

John Mashey is a consultant for venture capitalists and technology companies, sits on various technology advisory boards of startup companies, and is a trustee of the computer history museum. along with spending 10 years at bell laboratories working on the Programmer’s workbench version of unix, he was also one of the designers of the miPs risc architecture, one of the founders of the sPec benchmarking group, and chief scientist at silicon graphics. a previous version of this article appeared in the october 2006 issue of ACM Queue.