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 libraries.
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 years).
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 step 10.
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.
sGi ships first 64-bit micro (MIPS R4000) in system; still running 32-bit operating system
informal 64-bit c working group discusses various models (LP64, ILP64, LLP64), with no agreement except to use long long and have inttypes.h to help users
DEc ships 64-bit Alpha systems, running 64-bit operating system; LP64
sGi ships IRIX 6 (64/32 operating system; ILP32LL + LP64) on Power Challenge; customers buy 4GB+ memory, use it
DEc ships 4GB+ in DEC 7000 SMPs (may have been slightly earlier)
sun ultrasPaRc 64/32-bit hardware, 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 systems (ILP32LL+LP64)
aspen group supports LP64 model for C, so that unix vendors are consistent
References:
Archives