5. Convert the operating system to
64-bit, but with 32-bit interfaces as well,
to run both 64- and 32-bit applications.
6. Create 64-bit versions of all system
7. Ship the new operating system
and compilers on new 64-bit hardware,
and hopefully, on the earlier 64-bit
hardware that has now been shipping
for a while. This includes supporting (at
least) two flavors of every library.
8. Talk third-party software vendors
into supporting a 64-bit version of any
program for which this is relevant. Early in such a process, the installed base
inevitably remains mostly 32-bit, and
software vendors consider the potential
market size versus the cost of supporting two versions on the same platform.
DEC helped the industry fix 32- to 64-bit
portability issues by paying for numerous 64-bit Alpha ports.
aPPle mac ii PhotograPh by alexanDer schaelss, miPs r4000 PhotograPh by DirK oPPelt
9. Stop shipping 32-bit systems (but
continue to support them for many
10. Stop supporting 32-bit hardware with new operating system releases, finally.
11. Going from step 1 to step 6 typically took two to three years, and getting to step 9 took several more years.
The industry has not yet completed
Operating system vendors can avoid
step 1, but otherwise, the issues are similar. Many programs need never be converted to 64-bit, especially since many
operating systems already support 64-
bit file pointers for 32-bit programs.
Next, I trace some of the twists and
turns that occurred in the 1990s, especially involving the implementation of
C on 64/32-bit CPUs. This topic gener-
We could have gotten by with char,
short, and int, if all our systems had
been 32 bits.
c: 64-bit integers on 64/32-bit It is important to remember the na-
cPus: technology and Politics ture of C at this point. It took a while for
People have used various (and not al- typedef to become common idiom.
ways consistent) notations to describe With 20/20 hindsight, it might have been
choices of C data types. In the accompa- wise to have provided a standard set of
nying table, the first label of several was typedefs to express “fast integer,”
the most common, as far as I can tell. “guaranteed to be exactly N-bit integer,”
On machines with 8-bit char, short “integer large enough to hold a pointer,”
is usually 16 bits, but other data types and to have recommended that people
can vary. The common choices are build their own typedefs on these def-
shown in the table. initions, rather than base types. If this
Early days. Early C integers (1973) had been done, perhaps much toil and
included only int and char; then trouble could have been avoided.
long and short were added by 1976, This would have been very counter-
followed by unsigned and typedef cultural, however, and it would have
in 1977. In the late 1970s, the installed required astonishing precognition.
base of 16-bit PDP-11s was joined by Bell Labs already ran C on 36-bit CPUs
newer 32-bit systems, requiring that and was working hard on portability,
source code be efficient, sharable, and so overly specific constructs such as
compatible between16-bitsystems (us- “int16” would have been viewed with
ing I16LP32) and 32-bitters (ILP32), a disfavor. C compilers still had to run on
pairing that worked well. PDP-11s still 64KI+64KD PDP-11s, so language mini-
employed (efficient) 16-bit int most mality was prized. The C/Unix commu-
of the time, but could use 32-bit long nity was relatively small (600 systems)
as needed. The 32-bitters used 32-bit and was just starting to adapt to the
int most of the time, which was more coming 32-bit minicomputers. In late
efficient, but could express 16-bit via 1977, the largest known Unix installa-
short. Data structures used to com- tion had seven PDP-11s, with a grand
municate among machines avoided total of 3.3MB of memory and 1.9GB of
int. It was very important that 32-bit disk space. No one could have guessed
long be usable on the PDP- 11. Before how pervasive C and its offshoots would
that, the PDP- 11 needed explicit func- become, and thinking about 64-bit
tions to manipulate int[ 2] (16-bit int CPUs was not high on the list of issues.
pairs), and such code was not only awk- 32-bit happy times. In the 1980s,
ward, but also not simply sharable with ILP32 became the norm, at least in
32-bit systems. This is an extremely im- Unix-based systems. These were happy
portant point—long was not strictly times: 32-bit was comfortable enough
necessary for 32-bit CPUs, but it was for buyable DRAM, for many years. In
very important to enable code sharing retrospect, however, it may have caused
among 16- and 32-bit environments. some people to get sloppy in assuming
ated endless and sometimes vitupera-tive discussions.
ships first 64-bit micro
(MIPS R4000) in system;
still running 32-bit
informal 64-bit c
discusses various models
(LP64, ILP64, LLP64),
with no agreement except
to use long long and have
inttypes.h to help users
ships 64-bit Alpha
systems, running 64-bit
operating system; LP64
ships IRIX 6 (64/32
ILP32LL + LP64) on
customers buy 4GB+
memory, use it
ships 4GB+ in DEC 7000
SMPs (may have been
32-bit-only operating system
hal computer’s sPaRc64
uses ILP64 model for C
large file summit
codifies 64-bit interface
to files >2GB, even in 32-bit
supports LP64 model
for C, so that unix vendors