Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 64 bit addressing

Then it sounds like most of Mac OS X will remain 32-bit except for special cases (apps which need the large allocations). It seems like making the libraries 64-bit will cause huge backwards compatibility problems. Unless there are 32 and 64-bit versions of each.

What would happen if your 32-bit code linked with a 64-bit lib? How does the G5 map the memory to allow for both 32 and 64-bit addressing on the fly? If/when does Apple plan on making a move to full 64-bit support (soon or later), namely for the kernel?

I don't need 64-bit addressing for my projects; I just want to know if I need to start making them 64-bit compliant or if 32-bit will suffice for quite a while. I'm just trying to get a feel for what's lost/gained from staying with 32-bit.

And thanks for the information.


On Saturday, June 28, 2003, at 09:32 AM, Chris Kane wrote:

Apart from all the other issues one could talk about, I'll talk about the basic library issue. If you do build a snippet of code using 64-bit pointers, make sure you don't link it with any 32-bit code, including all system libraries (including an existing libSystem.dylib). That code is expecting pointers to be 32-bit -- calling [32-bit] strlen() with a 64-bit pointer quantity may or may not work out. It depends on what the instructions inside the [32-bit] function are doing, and where sizeof(void *)==4 has been hard-coded into them by the compiler, such as in effective address computations. And I doubt that the "indexed" instructions like lswx, when executed by the processor in 32-bit mode, will do the right thing if there is a 64-bit pointer in the source register (except perhaps in 'lucky' situations). Vararg functions or functions with stack-based arguments (where the amount of data for each item on the stack has been hard-coded by compilation) will also be trouble. The same goes for kernel APIs potentially (depends on whether the kernel thinks that vm_address_t, vm_size_t, natural_t, int, and so on are 32-bit or 64-bits inside; though, in some cases it shouldn't matter, like a 32-bit flags argument being passed in, in a larger register).

libSystem could possibly rebuilt 64-bit, if you figure out how to do that (and I don't know). As long as there are no sizeof(void *)==4 assumptions in the C sources or in the hand-coded assembly. And the kernel APIs are still a separate issue that I don't know anything specific about.


The OS will run the task in 32-bit mode. One would have to test to see if there is a performance difference. If the processor being in a 32-bit mode doesn't affect the bus/memory/cache subsystem (that is, the L1 cache is still filled in the same way with the same speed), then it's conceivable that a 32-bit program may run faster than a 64-bit one for certain operations, like searching through an array of N-bit ints (since the 32-bit program would be loading twice as many 32-bit ints into the L1 cache in the same amount of time), even if there were a small in-processor performance difference.
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: 64 bit addressing (From: Chris Kane <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.