64bit osx?

Folks,

New MBP, running 10.5.3...yet when I do a uname -a on the kernel, it reports it at i386.

How do I install/load the 64bit kernel on the MBP and Mac Pro?

Thanks!

 

As far as I know the kernel of 10.5 is still 32bit. There is only one version. Apple kept the kernel 32bit so that old drivers still work and so that it can run on older PPCs. All the subsystems (Carbon, Cocoa, Core Foundation, QuickTime, Quartz, etc.) are 64bit.

 

As far as I can tell, apple is combined 32 bit and 64 bit in one disk, as Steve Jobs introduced on the WWDC07.
I do not understand what is the difference between 32 bit and 64 bit, and i do not care.

 

64 bit- imagine a big fat bloke standing in the wind vs 32 bit a skinny woman.. the stability is in theory better

 

Download and install any 64-bit Linux distro.

 

Hmm...

http://www.apple.com/macosx/technology/64bit.html

I know having a 64 bit kernel will allow you to run and load 32 bit apps, but how the heck do you run 64 bit apps / drivers on a 32 bit kernel?

Any other suggestions, since the url above clearly states OSX is 64 bit, and I would think the OSX kernel would need to be 64 bit? (Save the Load linux on it!!11!! stuff pls...)

Tom

 

I was under the impression that Mac OS X 10.5 is 64-bit completely.

But hey, I'm not always right.

 

I'm hardly an OS X programmer, but from the bits and pieces I've picked up through various forums and other resources 64-bit support works as follows. Basically, unlike Windows where the address space is split between the user and the kernel, usually 2GB/2GB in 32-bit Windows, OS X always gives either the kernel or user access to the complete address space. So on a 32-bit system, when the kernel does it's tasks it gets the full 4GB, and when a user task is running, the address space is switched and the user gets the full 4GB. Windows loads the kernel into the address space all the time to avoid switching address spaces all the time between kernel and user tasks, but that artificially limits the memory available to applications. OS X maximizes the memory available to applications, but tries to minimize address space switches to the kernel, by mirroring some commonly used kernel operations to the user address space, but not as much as Windows.

Now this approach to having exclusive kernel and user address spaces seems to be very helpful to Apple's 64-bit implementation. In 10.3 Panther, applications were still 32-bit, but multiple 32-bit 4GB address spaces can be kept on the 64-bit G5's >4GB of RAM to improve performance. In 10.4 and 10.5, the processor is actually run in 64-bit mode, and when a user address space is loaded it has access to all the features of a 64-bit processor such as >4GB address spaces, 64-bit registers, etc. Of course, both 64-bit PPC and x64 include a 32-bit compatibility mode, and that's what the 32-bit kernel address space runs in when it's loaded. Obviously, the 32-bit kernel can not directly manage a full 64-bit memory space, but it supposedly does it through mapping the 64-bit address space onto some type of structure within the kernel's 32-bit address space. There is no doubt a limit to how much memory the 32-bit kernel can manage through this method, which is less than full 64-bit but more than what 32-bit normally provides so it's a good stop-gap measure. Any 64-bit data from user address spaces that is directly accessed by the kernel will of course be broken up and stored in 32-bit registers due to the 32-bit compatibility mode. However, the commonly used kernel operations, usually dealing with copying, that I mentioned before that were loaded into user address spaces are 64-bit, so direct transfers between 64-bit user address spaces occur natively.

That's my understanding on how the kernel deals with 64-bit support. I'm pretty sure most of this comes from a flip through a copy of Mac OS X Internals that passed through my hands a while ago, so you could try to get your hands on that book for a lot more on how Mac OS X works.

 

Leopard is a single kernel image for 32/64 bits. Allways is loaded as a 32 bits process, if detect 64 bits hardware the kernel switches into long mode compability.

For this reason we can not build KEXT that support the extended x86_64 register set yet.

The kernel only support 64 bits on user mode, not in the kernel by itself.

The kernel is 32 bits, that all.

 

Thank you for the detailed response, makes sense now!

Tom