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
˲ 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
˲ 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.
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.
1. aspen Data model committee. 64-bit programming
models: why lP64? (1997–1998); www.unix.org/
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
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
6. rationale for international standard—Programming
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
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.
© 2009 acm 0001-0782/09/0100 $5.00
64-bit zSeries (S/360
addressing still supported
(now called AMD64)
64-bit X86, (called EMT64),
compatible with AMD
Windows XP Professional
x64 for X86; LLP64