The Register on Mac OS X 10.2 and 64-bit support: a reply

Yesterday, we linked to an article in The Register that indicated that a forthcoming Mac OS X 10.2 would be a 64-bit OS (as opposed to the 32-bit support used by all current and recent OS versions). We included a quote from the MDJ that expressed skepticism that Apple was actually contemplating such a move, noting what a "massive" task such a shift would be. The author of The Register article, Tony Smith, replied to this criticism:

"A pointer is simply a block of bytes in memory that are used to hold the address of another block of bytes. A handle is a block of bytes in memory that stores the address of a pointer.

These are both artifacts of the programming language - methods used to abstract addresses at< various degrees to make programing easier by ensuring the programmer doesn't need to know precisely where every single byte of data resides.

As such, they're not something the CPU needs to be aware of - all it needs at run time are the relevant instructions to get a number from memory and then use that number to get another number from memory. The compiler turns all those complex pointer and handle references into simpler processor instructions to fetch and use data from memory.

What the CPU does require is that when it gets an address from memory it reads the correct number of bytes. That's eight in a 64-bit system, four in a 32-bit one (if I've done my sums correctly). The compiler ensures that any when a program passes handles and pointers around, the correct number of bytes are used.

That surely means the conversion of a 32-bit program to a 64-bit one is just a compile away, this time with the 'Is it 64-bit?' option in the Preferences panel set.

Sure, programs with inlaid chunks of assembly language will need more work, but I'd reckon most don't.

It's a while since I did any assembly code - on the Motorola 6809, on point of fact - but then you had to be aware of number of bytes a given value requires. There's no point trying to load a 16-bit address number (representing an address) into an 8-bit register, for instance. Coding in C to a large degree removes such issues, at least as far as compling goes.

Now there were problems when Apple went from 16-bit to 32-bit code, but they IIRC were as much an issue of ensuring backward compatibility because, unlike the G5, as per the rumours, the old 680x0 couldn't convert 32-bit addresses to 64-bit equivalents on the fly. That said, I'll be the first to admit I wasn't writing about Macs in those days, and there may be more to it than that - perhaps your readers can shine some light on the matter.

Incidentally, of all the emails I've received from software developers re a 64-bit OS X, not one has mentioned the pointer and handle issue MDJ raises. Again, I could be wrong, and perhaps my understanding of the matter is a little simplistic - I'm neither a CPU developer nor a professional programmer - but I'll stand for now by what I've written.

However, anyone can email me at tony.smith@theregister.co.uk, to put me right."

Update: Larry Rosenstein notes: "Apple never went from 16-bit to 32-bit code in the Mac OS. The 68000 family has always been 32-bit. There was an issue because the original Mac OS used the upper 8 bits of a pointer for flags, which wasn't an issue in the original 68000 CPU, but became important later."