Robert Clair [Robert Clair] - Learning Objective-C 2.0: A Hands-on Guide to Objective-C for Mac and iOS Developers, Second Edition

Note

These are (currently) the only toll-free bridged classes. You should not use type or class names as a guide. If a class and type are not in the preceding table, they are not toll-free bridged, even if the class and type names are the same or similar.

At the time of the first edition of this book, Apple was in the process of moving OS X to 64-bit. That transition is now almost complete. Xcode and Clang build OS X programs as 64-bit by default. With Lion (OS X 10.7) new Macs boot a 64-bit kernel by default. While it is still possible to build 32-bit Objective-C programs for OS X, 32-bit OS X programs use the legacy runtime and cannot use the newer features of the Objective-C language such as ARC, synthesized instance variables, and instance variables that are declared in class extensions.

iOS and iOS devices are 32-bit only. The material in the rest of this appendix refers to OS X.

The terms 32-bit and 64-bit refer to the number of bits used to address memory. A 32-bit program uses pointers that are 4 bytes wide and can address 232 or about 4 gigabytes (GB) of memory. A 64-bit program can theoretically address 264, or about 1.8 1019, bytes of memory. In practice, current Intel machines use only 48 of the 64 bits in an 8-byte pointer for addressing, giving a maximum address of about 280 terabytes. (A terabyte is about 1012 bytes.)

What is the point of such huge numbers? As computers have become faster, people in some disciplines have begun to write programs to work with very large data sets, large enough to run into the 4 GB limit on 32-bit addresses. On the hardware side, physical memory above 4 GB has become much more common. (Apple now sells laptops with up to 8 GB of physical memory and desktops with up to 32 GB of physical memory.) There is clear pressure to expand the size of addressable memory beyond 4 GB. Computer architectures work best with sizes that are powers of two, so the next logical pointer size after 4 bytes is 8 bytes.

The kernel and user programs are separate. Each can be either 32- or 64-bit. A 32-bit kernel can run both 32- and 64-bit user programs. So can a 64-bit kernel.

Programs must be entirely 64-bit or entirely 32-bit. If you compile a program for 64-bit, all the libraries and frameworks that you link against, and any plugins your program uses, must be available in 64-bit versions. This is not a problem for the system-supplied libraries and frameworks, such as the Cocoa frameworks, which are all available in 64-bit versions. However, if you are using other libraries, you may have to compile them yourself for 64-bit (if you have access to the source) or continue to build your program as a 32-bit application until 64-bit versions of the resources become available.

The main difference between 32- and 64-bit executables is the size of some of the primitive types. In a 32-bit executable, ints, longs, and pointers are all 4 bytes. In a 64-bit executable, ints are still 4 bytes, but longs and pointers are 8 bytes. The primary point, the one that can cause you trouble, is that in a 64-bit executable, longs and pointers are no longer the same size as ints.

Assigning a type to a longer type is OK, but assigning a longer type to a shorter type truncates the value held in the longer type and may result in nonsense. This may seem an obvious point, but there is a long history in C programming of ignoring the difference between a pointer and an int, and ignoring the fact that many system calls actually return long rather than int. Glossing over the difference between a pointer and an int, or the difference between a long and an int, makes no real difference when they are all 4 bytes; but the same code compiled for 64-bit can cause real problems. When coding for 64-bit, you should be careful when doing pointer arithmetic; you should never cast a pointer to an int variable.

Does compiling a program as a 64-bit executable make it run faster? There is no way to tell without building the program as separate 32- and 64-bit executables and then comparing the execution times. When you move to a 64-bit executable, there are some competing effects. On one hand, when an Intel CPU runs in x86_64 (64-bit) mode, it has access to more registers. It can use these registers instead of the stack to pass arguments during a function call, resulting in better performance. But moving from a 32- to a 64-bit executable can cause your programs memory footprint to increase (because many 4-byte variables are now 8-byte variables), sometimes dramatically. The larger size can mean more instruction cache misses, which results in worse performance.

New OS X projects in the current version of Xcode default to 64-bit. If you use the Clang compiler on the command line, it also defaults to 64-bit.

If you want to compile a program as 32-bit (if, for example, you are maintaining a program that must still run on older, 32-bit-only Macs), you can tell Clang to produce a 32-bit executable by using the -arch