A recent article by Tony Smith from The Register titled "Mac OS X 10.3 Panther will not be a 64-bit OS" caused a good deal of confusion with many people, including me. It is also caused a heated argument here on OSNews. The basic point of the article is that Mac OS 10.2.7 and 10.3 are not "true" 64-bit OSes, but the article does not clearly explain what a "true" 64-bit OS is. This had led to a lot of claims that the article is false or misinformed, rather than just unclear, which is certainly is.It turns out that Smith's article on The Register is more or less correct. More and more evidence is out there that applications on Mac OS 10.2.7 and 10.3 cannot address more than 4GB of RAM, which is the limit imposed by 32-bit operating systems. The basic evidence is from a post on Apple's darwin-development list by Apple employee (or email account holder at least) Godfrey van der Linden. Van der Linden writes:
"Yes the kernel's virtual address space will remain 32bit for the medium term but self-evidently we can address >32bit of physical memory from the kernel."
So the kernel in current (10.2.x) and future (10.2.7 and 10.3 Panther) versions of Mac OS X will only support a virtual address space of 2^32 bytes = 4GB of memory. No one really cares how much memory the OS internals use, the key question is can real life applications break the 4GB barrier? One non-Apple poster on the darwin-development list, Shawn Erickson, speculates:
"Outside of that I believe the user mode libraries/frameworks will remain 32 bit and hence most processes/applications must remain 32 bit (if you are careful of what you use I see no reason you could not use 64 bit addressing in certain tasks). I have not seen anything yet that implies that new 64 bit addressing versions of the systems libraries and framework will be provided in Panther (I bet they will be recompiled to use 64 bit native math, etc. just not addressing). "
Whenever you compile even the simplest application on an OS, you must link to libraries of some sort. While there are technical details yet to be revealed by Apple, if there are no 64-bit libraries on Mac OS X, the OS does not support 64-bit applications, in all practicality.
An anonymous poster on a Slashdot thread (OK, not the most relibable of sources) confirms this:
"Your code could use 64-bit addresses after being recompiled. But there is only one set of mmap(), etc... traps on the system at the moment (both 10.2.7 and Panther), and they only supports 32bit addresses. So, there is no way to put anything above 4GB in your address space to back those 64-bit addresses."
Finally, The Ego on the same Slashdot thread says:
"An OS could be called "64bits OS" because it offers a 64bits ABI to userland applications compiled in "64bit mode". My understanding is that this will _not_ be the case for Panther, all code will be compiled with the traditional ILP32 ABI."
What does this mean? First, an individual application (or process) on current (10.2.x) and future (10.2.7 and 10.3 Panther) versions of Mac OS X can only address 4GB (2^32 bytes) of memory. So Panther does not change the status quo. As someone who writes Fortran programs that use lots of memory (but is not a computer scientist), MY personal definition of a 64-bit OS is one in which an individual application can use up to 2^64 bytes (17 billion GB) of virtual memory. OSes such as Solaris and 64-bit versions of Linux and Windows meet my test. Mac OS X, in what van der Linden calls the "medium term" (at least the next major release cycle, Panther), does not meet my test.
The other part of van der Linden's post says that the kernel can support more than 2^32 bytes=4GB of physical memory. So, yes, the 8GB of memory that Apple claims the high end G5 model supports will indeed work. It is just that, from what I gather, no one application can grab all of it at once. Instead, each application can use only 4GB (the virtual address space limit which has not changed under Panther).
If this sounds suspiciously like 32-bit Windows, you are correct. The Windows NT kernel (found in Windows NT 4, 2000, XP and 2003) supports more than 4GB of physical RAM, but each process has only a virtual address space of 4GB, although the practical limits are much lower, as I will explain in a minute. For commercial market segmentation reasons this >4GB of physical RAM feature appears only in the 32-bit versions of Windows 2003 Enterprise and Datacenter Editions. Also for market segmentation reasons, hardware support for this feature is found only in the Intel Xeon chips, and not the nearly identical Pentium 4s. The 32-bit x86 Linux kernel also has support for the Xeon's memory addressing abilities. Somewhat humorously, Red Hat is playing a similar segmentation game by charging extra for the more than 4GB of physical RAM feature.
As a side note, if you care, an Apple developer's guide for the G5s says that they support 2GB DIMMs, so the high end G5 can really use 16GB of physical RAM, if you have the money. As a further side note, Motorola's documentation for its recent G4 processors suggest that they can support 64GB of physical RAM, so Apple did not technologically have to wait until IBM's release of the PowerPC 970s to support more than 2 or 4GB of RAM in PowerMacs and XServes. It's not clear that Apple will support any of the 64-bit defining features of the PowerPC 970/G5, unless you are a cryptographer who cares about integer arithmetic with larger numbers.
- "Counting the Bits of a Panther, Part I"
- "Counting the Bits of a Panther, Part II"
