Slashdot Mirror
Panther Will Not be a 64-bit OS
rouge86 writes "The Register has an article on what Mac OS X 10.3 will be like. Mac OS X 10.3, aka Panther, will not be a 64-bit operating system, despite running on a 64-bit processor. Instead, the next major release of the Mac operating system will be a hybrid, much like version 10.2.7." You mean they didn't rewrite the entire operating system from the ground up? And that it will run on older, 32-bit, Macs? I am shocked!
You don't have to re-write code to make it 64-bit. You just have to re-compile it. Granted, you have to make sure it's 64-bit safe code, but there's not all that much effort involved in that. Basically, you just can't assume that you have 32-bit integers and pointers.
For instance, the Linux kernel was made 64-bit safe in version 2.0, when they added support for the Alpha architecture. It's one code base that can be compiled for different architectures, some 32-bit, some 64-bit. There's not a whole lot of 64-bit specific code.
Most Open Source programs are 64-bit clean now. I'd think Apple's programmers would have been working to make sure all the Mac OS X code is 64-bit clean.
Software sucks. Open Source sucks less.
http://developer.apple.com/documentation/Hardware/ Developer_Notes/Macintosh_CPUs-G5/PowerMacG5/Power MacG5.pdf
The data bus going to each processor is only 32 bit. It's fast, and it's full duplex, but it's only 32 bit. See page 22.
First 64-bit CPU: MIPS R4000, 1991 (see Microprocessor Report, Feb 6, 1991)
The first 32 bit program: 1948
The first 32 bit OS: ???
At least, as far as a quick Google finds. There may be other systems that predate those. As for IBM PC compatables, Coherent 4.0 (1992), BSDi and 386BSD (1990?) and Linux (1991, usenet announcement) all ran on 80386s in 32 bit mode. I remember seeing other OSes in Dr. Dobbs that claimed to be 32 bit as well. SCO Xenix was not 32 bit in the earlier versions (despite what the other reply claims)... SCO Xenix (and Coherent and other *nixish OSes for the PC lineage) predate the 80386.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
You are confusing 64-bit support with a 64-bit OS. You shouldn't. Panther does indeed have 64-bit support.
> First 32 bits CPU: 386, 1985
> First somewhat 32 bits OS: Windows 95, 1995
Actually there was a Windows/386 (Windows 2.0 with 386 32-bit memory support in 1989). There was also a truly 32 bit operating system known as OS/2 V2.0 in 1992.
You also forget the numerous UNIX on Intel implementations, such as Interactive (now owned by Sun) and Xenix (SCO).
PAE isn't a "real" solution like going to 64bits is; the processor is still 32bits, so it's doing paging tricks to get past the 4GB barrier. Those tricks work, but it has a very noticable speed penelty for doing so. One other thing to keep in mind right now is that just because the chip arcitecture supports 4bil^2 worth of memory, doesn't mean that current devices are designed to use it. That much memory is overkill, and designing a chipset/CPU at this point that can use that much is just as much overkill. Full 64bit memory addressing requires more logic, more transistors, and more traces to use, so it's not surprising that Apple/AMD aren't going the whole 64bits; they'll get there when they're ready.
Now, in the current generation G5, memory is actually limited in hardware to four thousand gigabytes, and limited in practical terms to eight gigabytes. But applications can, nonetheless, allocate and address up to 18 billion gigs of virtual memory. The OS won't stop them from doing that.
The PPC 970 only implements 42 virtual address bits. Similarly, other current 64 bit microprocessors only implement a subset of the available 64 bits in their MMU. In short, an application running on a PPC 970 processor will only be able to address 2^42 bytes, or 4 terabytes of memory.
That sounds rather limited to me.
The Mac OS has been 32-bit from day one, AFAIK. The memory addressing was 24-bit until the Mac II series, but the CPU and OS were always 32-bit.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
So mark that down as 1984.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
So while the G5 can handle 64-bit math and memory/file addressing, it sounds like 10.2.7 and apps running on it aren't going to be using those.
Wrong and right. Any program that runs on the G5 will get 64-bit math automatically. File addressing is already 64-bit. Memory addressing will continue to be 32-bit until you recompile with -mpowerpc64.
They're going to be using the existing emulations, and a few extra hacks bolted on a the last minute to get a few extra bits on the memory address space.
Wrong. The kernel will use full 64-bit addressing; it already does so in 10.2.7. No emulation will be necessary, at any level. Applications will have 32-bit pointers unless they're specifically compiled for 64-bit pointers. This is, incidentally, a good thing. Applications with 64-bit pointers do not use cache as efficiently as those with 32-bit pointers. Take the same application and compile it in 32- and 64-bit versions, and the 32-bit version will be measurably faster on the same hardware.
IMHO, if it's still thunking 64-bit operations down to 32-bit operations in software, it's not really 64-bit.
IMHO, if you don't know what "64-bit" actually means, you should probably think twice before posting in a thread like this. Just friendly advice.
And I don't know why people are ripping on this strategy. This way Apple doesn't have to Ship 10.3 for the G5 and a seperate 10.3 for the G4. That just confuses customers and pisses off people who have a G4 and a G5. Now Apple can ship one version and only have small changes between the G4 and G5 versions, and let the installer make the appropiate changes. Also, Solaris did the same thing. Alot of there utilities were 32-bit for a long long time after 64-bit support came out, programs like top simply do not receive any advantages from being 64-bit.
Actually, it is 52 bit for the older PowerPC's: Page 7-35 It is 64 or 80 for the 970: Page 258.
It is also important to note that these values are a per program basis if you are willing to change around some special registers in your context switches.
You see? It's like I've always said. You can get more with a kind word and a 2x4 than you can with just a kind word.
Actually, Nermal was a boy. I know, it's hard to believe, but this was actually documented in one particular Garfield comic.
The cartoon gave him a girl's voice, and he's an feminine looking cat.
Vonal Declosion
There are many ways for an OS to be "a 64-bit OS". However programmers/users of existing 64bits OSes will typically check a single criterion, which is unlikely to be met by OS X 10.3 .
...) can make use of memory beyond the 4GB limit by using specific APIs that work around the 32bits pointers limitation. I hope that Panther will allow that.
1. An OS could be called "64bits OS" because it allows programs running on the computer to use 64bits-instructions, while leaving them with 32bits pointers. This is typically done by offering a 64bits datatype (int64_t/uint64_t in C99 compliant environments) and a compiler that will emit the right instruction sequences. It also requires that the underlying OS will be made somehow "64bits aware", ie that it will save/restore the full 64bits content of processor registers on context switches. My understanding is that Panther/10.3 will allow that, or at least most of that.
2. An OS could be called "64bits OS" because parts of the kernel (VM / buffer cache,
3. An OS could be called "64bits OS" because it allows the usage of more than 4GB of memory by all userland processes, while any given process is still limited to 4GB (32 bits pointers). My understanding is that Panther will do that.
4. An OS could be called "64bits OS" because the kernel code is compiled to follow a 64bits ABI (Application Binary Interface). In such an ABI, pointers are 64bits entities and some integer types are also 64bits. While an ABI covers _a lot more_ ground than just the size of the common C types, those sizes are often used to characterize the ABI. The most common 64bits ABI is known as LP64 (aka I32LP64) where "int" remain 32bits, while "long" and "void*" are 64bits. By comparison the most common 32bits ABI is known as ILP32 (int, long, void* are all 32 bits). I don't think any "common" OS offered a ILP64 model (Cray maybe?). Windows64 is a different beast, being LLP64 (aka IL32 LLP64), where int and long are 32bits, while "long long" and pointers are 64bits. My understanding is that this will _not_ be the case for Panther, the kernel code will be compiled with a ILP32 ABI.
5. 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.
My "belief"/"understanding" of the Panther situation comes from reading the WWDC reports, rumours reports and also the Darwin development mailing list where one Apple employee said that OS X won't offer an LP64 ABI until much later (not in Panther, at _least_ not in 10.3.0 and I doubt any 10.3.x release).
Most current users of 64bits systems will only use criterion 5, but I expect Apple PR to try to muddle the issue. And I won't blame them much, the issue is not as clear cut as some users think.
Some tidbits related to 64bits platforms:
- HP-UX 11.00 shipped as two different kernels, one 32bits kernel and one 64bits kernel. 64bits machines could run either of them, while 32bits machines were restricted to the 32bits kernel.
On the 64bits kernel a user could run 32 and/or 64bits processes, while the 32bit kernel could only run 32bits processes.
It sometimes made sense for the owner of a 64bits machine to only install the 32bits kernel, if they didn't intend to run any 64bits application and didn't have more than 4GB of ram (rare then). Running the 64bits kernel typically consumed a bit more memory and consumed a bit more memory bandwidth.
- Linux on 64bits machines is "pure" 64bits (today, this may change due to ISV pressure). It doesn't run anything but programs compiled with the 64bits ABI (I32LP64). A special case is Linux IPF (IA64) which also runs 32bits apps, but those aren't "native" applications using the Itanium ISA but x86 binaries running using the hardware (now) or software (future) emulation. Another special case will be Linux on x86-64 which also has to run "emulat
Would that be any relation to the Dogcow?
Actually, no. It is a reference to the Nickelodeon animated show about a creature that is half dog half cat -- the front ends of both animals joined at the mid section and pointing in opposite directions. Read more about it here. But the dogcow would have been much more inline with the Mac culture; howver, it is not a cat reference.
It struck me that OS X on the x86 (would that be OSx86 ??) would be an odd combination and should have an appropriately odd mascot -- catdog!
Yeah, Darwin was the codername of the Quadra 900.
Yes. Assuming the data being processed is only 16-bits or 8-bits wide. For example, if you were to make a piece of photo editing software that could only do 8-bit grayscale images, it would be more efficient as an 8-bit program than as a 32-bit program. (Assuming that the host processor had an 8-bit instruction set that is the same as it's 32-bit instruction set.) Likewise, if you write it as a 16-bit program, and have a fully modern 16-bit OS to go with it, (say, ELKS, the 16-bit Linux derivative,) and run it on a Pentium 4, it would be faster than the same thing (again, processing 16-bit data) on a 32-bit version.
In the case of the PowerPC 970, it is the exact same instruction set, in 32-bit or 64-bit modes. The only difference is the data being processed. If you don't *NEED* to use 64-bit data, then 32-bit mode will be faster, as you're not 'padding' the data with an extra 32-bits of unecessary info. The PowerPC architecture was designed from the get-go to be 64-bit, with 32-bit as a subset of it. Until now, there haven't been any PowerPC processors that have been capable of processing the full 64-bit width of data though. (Yes, the original PowerPC 601 could theoretically be redesigned to allow 64-bit data, and it wouldn't take too terribly much work.)
It's not at all like the IA-32 (386-Pentium 4/Xeon/AthlonXP,) AMD-64 (Athlon64/Opteron,) or the IA-64 (Itanium) architectures.
IA-32 was a kludge of the existing 16-bit instruction set. AMD-64 is a further extension of the old 16-bt set. IA-64 is an all-new instruction set, not at all compatible with the old IA-32. (The Itanium Processors have hardware IA-32 decoders in them, but the IA-64 spec doesn't call for it at all. Intel could make a later Itanium that cannot run existing 32-bit code at all, and it would be fully compliant with the IA-64 spec.)
Another non-functioning site was "uncertainty.microsoft.com."
The purpose of that site was not known.
solaris. runs in 32bit or 64bit mode on my ultra1.
Be ot or bot ne ot, taht is the nestquoi.
You are wrong, neither the kernel nor any userland application will use 64bits pointers (void*), certainly not on 10.2.7 and most likely not in 10.3 .
Another idiot.
The kernel is just a program. Okay? If compiled with -mpowerpc64, the kernel will have 64-bit pointers. The Smeagol and Panther kernels (indeed, the Darwin 7.0 preview kernel that's available for download already) are compiled -mpowerpc64.
Any "userland" (how cute) program will get 64-bit pointers if compiled with -mpowerpc64. Whether or not to recompile is up to the individual ISV. The general rule is: don't. Compile with GCC 3.3 with -mtune=970 to optimize for the G5, but don't use -mpowerpc64 unless your application actually needs more than 4 GB of virtual memory.
That's a bit of an over-generalization. For many apps it will be the case, but certainly not for all. I have even seen the reverse in some cases.
Wrong. A 64-bit pointer is (duh) twice as wide as a 32-bit pointer. That means you can only fit half as many of them in cache. Therefore *every* 64-bit program runs more slowly and less efficiently than its (possibly notional) 32-bit counterpart.
I've spent ten years on SGI's ProC and MIPSpro C compilers. What are your qualifications for saying I'm wrong?
From Apple's site:
Native compatibility with 32-bit application code
For PC users, going from 32-bit to 64-bit computing requires migrating to a 64-bit operating system (and purchasing the 64-bit applications that will work on it) or running a 32-bit operating system in slow-as-molasses emulation mode. The PowerPC G5, however, offers a seamless transition to 64-bit performance: Current 32-bit code -- such as Mac OS X, the Mac OS 9 Classic environment and existing applications -- runs natively at processor speed. With no interruptions to your workflow. And no additional investment in software required, period.
That's because, unlike competing instruction sets, the PowerPC architecture was designed from the beginning to run both 32-bit and 64-bit application code. This enables the PowerPC G5 processor to run Mac OS X natively for an immediate performance boost. In addition, as applications are optimized and as Mac OS X is further enhanced for the PowerPC G5 processor, performance gains will be even more dramatic.
The emulator was entirely software. The emulator initially wasn't particularly fast, but since most Mac applications spend a great deal of time in the Toolbox, Apple made the most heavily used traps native.
NeXTstep/Intel became available in Fall 1992, and was 32-bit clean at the time. Since OSX inherited from this codebase and is still largely controlled by the same developmers, you can expect a timely transition to 64-bit.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
The history of OS/2. OS/2 2.0 was the first 32-bit version.
Linux IT Consulting and Domino Development in Michigan