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

On Saturday, June 28, 2003, at 11:08, Mike Vannorsdel wrote:

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.

I assume there will need to be an entire stack of libraries for 32 and another for 64 bit, with no mix-n-matching.

What would happen if your 32-bit code linked with a 64-bit lib?

I assume that the upper 32 bits in the general purpose registers in a 32-bit task would always be zeros, since the task wouldn't be putting anything in there itself. However, if the library tried to return something > 32 bits, the 32 bit task won't see the value properly in some way or other. Or, if a pointer to a pointer was being passed in, the 64-bit library might put a 64-bit pointer in the space for a 32-bit pointer that the app is passing a reference to. It's all just trouble waiting to happen.

How does the G5 map the memory to allow for both 32 and 64-bit addressing on the fly?

Even if the machine can have > 4GB RAM and registers are 64-bits wide and whatnot, it is the operating system (kernel mostly) that decides how big the address space is that is given to tasks. It is conceivable that even in a fully 64-bit system top-to-bottom, an OS could still give only 4GB of address space to tasks, and specify that pointers are 32-bit values. Not that I know any reason why such a thing would be done. The size of the ambiguous integer types in C is of course yet another separate question.

If/when does Apple plan on making a move to full 64-bit support (soon or later), namely for the kernel?

Dependencies on sizeof(void *)==4 and related occur easily in C and similar languages and presumably there either has been or will be a massive effort to root them out of the whole system. I can't say anything about that of course.

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.

I would strongly suggest doing some of these things now to help yourself later (when we invented CoreFoundation, we took into consideration some of these same things, but didn't even go quite far enough I think -- it would have been somewhat different if C99 had been out by that point):

1) Invent your own names for types, for what the type is used for. typedef int MyInt;, and so on, so that you can easily change them, individually, in one place later and recompile. For example, you may want to grow one type of value currently typed to int, and not another typed similarly, if you don't need more room for those values.

2) Use C99's stdint.h and inttypes.h headers. Use specifically sized types when you can and when appropriate; you'll know exactly the range of values these types can take on, and these won't need to change in a 64-bit world, so you'll have less to deal with at that time. Avoid "int" and "long" and other vague C types unless you want to examine each occurrence of these later.

3) Don't assume that sizeof(void *)==4, or that sizeof(void *)==sizeof(int)==sizeof(long), or that sizeof(anything)==something, except sizeof(char)==1 (required by C). When wanting to interconvert between pointers and integers, use intptr_t and uintptr_t from stdint.h as your integer sizes, and _understand_ that the range of integer values these can take on might be variable (for example sizeof(void *) could be 2, and then your value of 1 million won't fit -- though I think this particular example can be ignored as a concern). Avoid knowing the integer range of pointer-sized quantities, and avoid converting back and forth between the ambiguous C types. Relatedly, don't print out pointers as ints by using "0x%x" and casting the parameter to (int), unless you're willing to have the wrong value printed out (and if so, why really bother with the printf?).


A big problem for C type code is that casts get sprinkled around like holy water by people to shut the compiler up (since obviously the code must be better when the compiler spits out no complaints). Hopefully when 64-bit tasks become a real possibility for developers, there will be compiler options to complain about pointer-to-int conversions even if there is a cast, or to ignore many kinds of casts, or whatever. Options that could be turned on to help the conversion, then turned off again (probably).

Please file enhancement requests on the compiler if anybody has good ideas on how the compiler might help people at compile time find potential or real problems in their code. Even if some of the ideas are the same, the number of "votes" will help indicate worthiness of the feature to some extent.


Chris Kane
CoreFoundation
_______________________________________________
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: Mike Vannorsdel <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.