in Hardware

searching for a 64-bit future

This month in ACM Queue there’s an interesting and lengthy article entitled The Long Road to 64 Bits, which addresses why, fifteen years later after the 64-bit MIPS R4000 was announced, most systems are still not fully 64-bit clean. I use the word “clean” to mean that most systems do not run entirely in 64-bit mode; many systems are running 32-bit operating systems on 64-bit processors, or even when a 64-bit operating system is in use, running many 32-bit programs in compatibility mode.

The article is a fascinating account of how technological decisions that were made all the way back in the 1970’s, both with respect to hardware and compilers, still impose limitations today. Although many of the hardware compatibility challenges have now gone away — for example, system designers now know enough to trap address bits that they are not using for addresses rather than letting "clever" programmers get away with using them for data — the assumptions that were made by programmers back in the days of 16 and 32-bit machines with respect to the size of C data types continues to hinder the porting of programs from 32 to 64-bit. One can’t just make and hope one’s pointers all work. As Mashey puts it, some programmers got sloppy and assumed things like

sizeof(int) == sizeof(long) == sizeof(ptr) == 32

All this may sound really abstract to readers who don’t have a hardware design background (admittedly, mine is minimal, but I understand enough of the general concepts) so let’s talk about how this impacts us end-users. We run into problems like “there is no 64-bit web browser that can execute Java and Flash” because the Java and Flash plugins haven’t been ported to 64-bit clean versions. In some ways, this is an example of shocking neglect on the part of software vendors like Sun and Macromedia (pardon me, Adobe). Bug Number 4802695, entitled “Support Java Plug-in on 64-bit AMD Opteron”, has been open with Sun since January 14, 2003, and after three years there is still no resolution in sight. This should be embarrassing for Sun, which is a vendor of 64-bit Opteron and UltraSparc IIIi workstations.

On the Adobe side, they have finally managed to create Flash Player 9 for operating systems other than Windows and Macintosh. But where’s the 64-bit version? Again, it looks like they are having problems with C data types in their virtual machine. From what I can deduce, they used some 32-bit data type to represent virtual addresses in their VM, and now they are paying the price — exactly what Mashey alluded to in his ACM Queue article.

The future for pure desktop 64-bit systems will come very slowly, and I don’t think much will happen until both Windows and Macintosh ship pure 64-bit operating systems, with a 64-bit kernel and 64-bit userland. Maybe this is already happening, at least at the kernel level, but it will take some time before all of userland is also 64-bit. Of course, on Windows, the userland is very large, so checking all those nasty applications like Internet Explorer for 64-bit cleanliness will take a great deal of time. Again, I’m sure much of the "cleverness" (with respect to assumptions about address size that no longer hold true) that past Microsoft programmers rejoiced about is coming to bite the current generation of Microsoft programmers in the ass.

On the server front, though, 64-bitness is already here today. I attribute this to a signficantly smaller userland and the fact that server applications are, in general, address-size agnostic. It is possible to run a pure 64-bit server operating system like SLES and userland on a 64-bit CPU today, whether your flavour of 64-bit is AMD64, EM64T, UltraSparc-IIIi, or something else.

It remains to be seen which will be slower — widespread deployment of pure 64-bit systems, or the wide-scale adoption of IPv6. (That’s a topic for another day.)