Author: Jem Matzan
The AMD64 and EM64T instruction set architectures
AMD64, also called x86_64 in the Linux realm and EM64T (Extended Memory 64-bit Technology) by Intel, is basically the old x86 architecture (called “general purpose instructions”) plus the old x87 floating point instructions (which are deprecated now but still used by some older 16- and 32-bit programs), 64-bit media instructions (a la MMX and 3DNow!) and these significant enhancements:
- Increased number of general purpose registers
- 64-bit addressing
- 128-bit (SSE, SSE2) media instructions
- Improved physical and virtual memory management
The AMD64 ISA includes twice as many general purpose registers as the old x86 design, and all of them are twice as wide due to the 64-bit addressing (as opposed to 32-bit). The instruction pointers (a pointer is a variable that contains an address rather than data) also increase from 32 to 64.
Having more and wider general purpose registers means that memory can be used much more efficiently and memory traffic can be minimized, which in turn allows compilers to compile programs to work much faster on your machine.
64-bit addressing means that the physical memory limitation rises to 1TB from 4GB. The processor can also work with longer instructions. To really notice this advantage, you have to stress the system to a degree that most desktop users don’t with current software, but as desktop applications demand more from processing hardware, this advantage will become much more important. (The advantages to 64-bit addressing in a workstation or server machine are more obvious as they regularly deal with CPU-intensive work.)
128-bit media instructions refer specifically to Intel’s SSE and SSE2 (Streaming SIMD — Single Instruction Multiple-Data — Extensions) technology. These instructions are very useful for working with large blocks of data, which benefits anyone who deals with a lot of scientific data or high-performance media (streaming high-resolution video, image processing, 3D rendering, and speech recognition) or anything that uses floating-point math. Previously the Athlon XP processor did not have SSE2, although it did have SSE functionality. Intel Pentium4 CPUs utilize both.
AMD64 deals with both physical and virtual memory in a much more sensible manner than x86, treating the entire virtual memory space as one unsegmented block and eliminating a lot of translation layers from the process of addressing physical memory. Previously x86 would segment virtual memory into small blocks for use with different programs and functions, but this ended up being inefficient and rarely used by the software. AMD64 eliminates that inefficiency by letting the software choose how it will handle virtual memory (which it does anyway, even if the virtual memory is segmented). This translates into lower latency and faster performance when dealing with both physical and virtual memory.
Performance and enhanced capabilities aside, the most valuable feature of the AMD64/EM64T is its ability to run 32-bit x86 binaries without a separate processor or operating system. This makes it much easier to slowly transition from a 32-bit to a 64-bit environment without having to change software applications. While AMD64 and EM64T processors are still very fast while in 32-bit mode, you won’t be able to take advantage of any of the above-mentioned features and expanded resources (with the exception of the SSE and SSE2 instructions) if you’re running a 32-bit operating system. Even if you’re going to be running 32-bit binary programs, it pays to have a 64-bit operating system underneath them so that the rest of the system can run more efficiently. That’s only the beginning, though — the next step to maximum performance is to eliminate all 32-bit binaries from your system.
Operating systems
One great advantage to free software is its ability to be easily ported to new architectures. While at first it was difficult to find many programs that would compile for 64-bit, today you can have a complete desktop system that is entirely 64-bit without making too many sacrifices. Fedora Core, starting with version 3, offers a mostly 64-bit operating environment with the exceptions of programs which are not yet modified to compile for the AMD64 architecture. If you’re not a Fedora Core fan, 64-bit editions of your preferred commercial distribution may be available, or you can compile it all yourself a la Gentoo Linux, FreeBSD, OpenBSD, or NetBSD.
Red Hat and Mandrake both offer AMD64 editions of their commercial distributions. Mandrakelinux 10.1 for x86_64 is $45US more than the x86 Powerpack edition that it was based on. Novell used to offer their AMD64 edition of SUSE Linux Professional at a higher price, but starting with version 9.1, the AMD64 and x86 editions are packaged together in the same box. That means that for SUSE users switching from 32-bit to 64-bit is as easy as reinstalling the distribution.
As we mentioned, there are a few programs that will not properly compile or run in 64-bit mode. Fortunately, with each successive distribution release, more is made 64-bit.
“There are parts bound to remain 32-bit, namely bootloaders — e.g. lilo, grub,” says Mandrake spokesperson Gwenole Beauchesne. “Besides, OpenOffice.org is still 32-bit as it’s not fully 64-bit clean yet. The rest default to 64-bit packages.
“Note that we also provide a lot of 32-bit library packages to retain compatibility for users willing to use 32-bit programs. Generally, that’s proprietary applications that are not ported to x86-64 yet. Finally, exclusively for Mandrakelinux 10.2 and next distributions, we also provide 32-bit packages useful for development of 32-bit applications from an x86-64 system. Compared to our competitors, our solution does not require you to install a 32-bit chroot, neither need repackaged files, nor manually fiddling with 32-bit libraries or headers. So far, it has been verified to let you build a 32-bit evolution2 package from an x86-64
system as simply as linux32 rpm --rebuild <evolution>.src.rpm.”
The BSDs can be compiled entirely for 64-bit, although we had some significant problems with stability in testing FreeBSD 5.3 for AMD64. We had frequent crashes and data loss, DHCP and other network problems with SysKonnect/Yukon-based LAN cards, and found the 32-bit binary compatibility layer to be nonexistent. The entire system was 64-bit, but it never seemed to work reliably on two test systems (Asus K8V Deluxe with an Athlon 64 3200+, and an MSI K8T Neo2-FIR with an Athlon 64 4000+). The final nail in the coffin was that there were so few programs in the Ports tree that would properly compile, and some were limited to the x86 arch but would compile perfectly for AMD64 by editing that port’s makefile. Finding programs was a matter of trial and error — and sometimes a little configuration hacking.
OpenBSD is also compiled top to bottom for 64-bit (with the necessary exception of the boot code, which does not affect system performance), and nearly all of the programs in the Ports tree compile for 64-bit without any problems. A complete list of precompiled 64-bit OpenBSD packages can be found here.
OpenBSD project leader Theo de Raadt says the OpenBSD Ports tree is thoroughly tested; that “it is not a matter of trial and error. In our Ports tree development processes, something has to compile fully to be enabled on an architecture. The Ports tree is compiled continually on as many architectures as possible to spot flaws like this. Actual tested-to-run-perfectly is a little bit behind this, since 64-bit bugs do tend to lurk in hidden areas, many programmers out there still are not aware of how to code carefully for 64-bit machines.”
OpenBSD’s AMD64 package builder Peter Valchev added, “You can expect most things to work. Out of about 3000 ports in our tree right now, there are less than 20 that are broken (don’t build), which is less than 1%. And fixing these is a matter of completely rewriting portions of the program in order to get it to build (often due to complete assumptions of ‘all the world is i386’ on the part of the programmers), and infeasible for us to do. The reason for the breakage being so minimal is not an accident — the OpenBSD Ports contributors strive for quality as a primary goal. There are, of course, 64-bit runtime bugs that appear in programs due to careless programming combined with the fact that other operating systems ship 32-bit binaries, so their users don’t run into issues, and programs never get fixed! That’s completely the wrong approach — instead we suffer from the odd bug that bites us, but pretty much all of the known issues are continuously being fixed by volunteers.”
Drivers and programs
In our several months of *BSD and GNU/Linux 64-bit testing, we didn’t run across any trouble with getting drivers to work. Nvidia has provided a working, up-to-date 64-bit binary driver for Linux for more than a year, but ATI only released theirs this past January. It’s not without its problems, and seems to be no better off than the 32-bit version was in terms of performance and stability. These exceptions aside, you may be stuck with a 32-bit operating system if you have hardware that only has binary proprietary drivers available. Other proprietary drivers — however rare they may be these days — may not be compiled for 64-bit in the near future. Unlike userland software applications, it is not possible to use a 32-bit binary driver with a 64-bit kernel.
Fedora Core and Gentoo are the only community-developed GNU/Linux systems we tested that can be completely 64-bit, with the aforementioned exception of the boot code. Debian has an AMD64 edition, but it is still in the beta stage.
Like FreeBSD’s Ports, Gentoo’s Portage tree is hit-and-miss with programs that are able to compile and run. While you can get a 64-bit Mozilla, the MPlayer plug-in package is still masked and marked as unstable. There are many similar examples of masked packages, like OpenOffice.org and the Azureus BitTorrent client. Fortunately, most of the masked programs have 32-bit binary builds available in Portage, so you don’t have to go without them.
The biggest hassle we had was with Web browsers and word processors. OpenOffice.org 1.1 would compile partway, but not all the way. AbiWord 2.2.3 (the latest edition available in Portage) would do nothing but crash every time we tried to open a file. The eventual solution was to use a 32-bit OpenOffice.org binary from Portage; we’re hoping that the upcoming version 2.0 is a bit more portable.
Mozilla and Firefox will compile for AMD64, but Opera has no plans to ever offer a 64-bit binary of their Qt-based proprietary browser. While we had some trouble with Mozilla’s long-term stability (over time, it would crash at random), and Firefox crashed left and right, our biggest challenge was in getting the plug-ins to work. The Java Runtime Environment is now available for Linux/AMD64, so we installed that from Portage and made sure that the plug-in was copied to the correct location. Both Mozilla and Firefox would detect it in the about:plugins screen, but only 64-bit Mozilla could use it. The MPlayer plug-in, unmasked manually, would work well in 64-bit Mozilla, but was not detected by 32-bit Firefox. Opera would detect our 32-bit binary Acrobat Reader plug-in, but neither Mozilla nor Firefox would. Flash worked in Opera and 32-bit Firefox, but not 64-bit Mozilla. After days of searching for answers and fiddling with 32-bit binaries and 64-bit compiles of both browsers, we determined that it was necessary to have both a 64-bit Mozilla and a 32-bit Firefox to use all of the usual browser plug-ins with 64-bit Gentoo.
While many packages are masked in Gentoo, some of them may work perfectly or partially. There’s a rather large thread on the Gentoo forums where AMD64 users discuss masked programs that seem to work well.
Not all proprietary software is 32-bit. Epic released Unreal Tournament 2004 last year with both 32-bit and 64-bit AMD64 Linux binaries. After extensive testing of both editions, we can say for certain that they work rather nicely.
The challenge and the compromise
While the road to a completely 64-bit operating environment with an AMD64 or EM64T processor is almost comfortable enough to travel, there are still some roadblocks here and there. Most of them have workarounds, and you’re going to either spend more time or more money to get a working 64-bit environment.
Fedora Core 3 (and the upcoming 4) is a good, safe bet for those who want to go 64-bit with as little cost and hassle as possible. Novell, Mandrake, and Red Hat have mostly 64-bit versions of their desktop, workstation, server, and corporate distributions, if that’s the route you prefer. Gentoo Linux requires more time and tinkering to get things working properly in 64-bit mode, but for those of us who enjoy that sort of thing, that only makes Gentoo more appealing. The BSDs are also an option for the more technically-minded 64-bit enthusiast.
There’s no doubt that the AMD64 architecture has come of age in the free software world. While proprietary software companies only seem to see the expense of porting their x86 code and supporting yet another version of their software, open source projects see it as a challenge to develop better programs. It may not be perfect yet, and depending on your needs you may have to make some minor sacrifices to go totally 64-bit — or you’ll have to use a handful of 32-bit binaries for the time being — but it’s there and it works.
