Mac OS X Tiger breaks the limitations of 32-bit computing and allows developers to create command-line applications, servers, and computation engines that can work with mind-blowing amounts of memory. Previous versions of Mac OS X have been able to take advantage of more than 4GB of system memory when running on a G5-equipped Mac, but each application was still subject to the 4GB limit imposed by a 32-bit address space. Tiger obliterates that restriction and allows applications to access a 64-bit address space when running on the PowerPC G5. Better yet, this support comes with no compromise in the ability to run current 32-bit applications.
This is no small feat. Others are trying to bring 64-bit computing to the desktop but have met with limited success. Apple is doing so in a manner that maintains 32-bit compatibility at full speed while providing the headroom to meet application requirements for the next 20 years—even if application memory requirements double each and every year. As well, only Mac OS X supports both 32-bit and 64-bit hardware with a single version of the operating system. From G3 to G5, from iBook to Xserve, there is just one kernel and set of core system libraries for Tiger.
Furthermore, the transition of the Mac to 64-bit computing has been, and will continue to be, a smooth one. This is, in large part, because the PowerPC architecture was defined as a 64-bit architecture with a 32-bit subset from day one. This means that a 64-bit migration strategy has been part of the platform since the PowerPC was first introduced. It is also the reason why 32-bit applications don't have to run in a special compatibility mode as is required on other 64-bit architectures. No penalties. No compromises. In fact, thanks to overall system improvements and fine-tuning, many 32-bit applications will run more efficiently than before.
This article shows you what 64-bit computing means for you, how 64-bit support has been built into Tiger, and how you can build 64-bit applications. First, let's start with what 64-bit computing can deliver.
What 64-bit Computing Gets You
By definition, the difference between 32-bit computing, the gold standard for the last 20 years of desktop computing, and 64-bit computing is the size of the memory space an application can use. In a 32-bit world, an application can address 4GB of memory. For many of the applications that we use everyday, such as word processors and spreadsheets, this is more than enough memory. However, if you work with large datasets, such as the human genome or geospatial data, 4GB suddenly becomes very limiting.
64-bit computing shatters the 4GB limit giving a virtual address space in excess of 16 exabytes. That's more than 18 billion billion bytes. You can't even begin to put that much RAM in a Power Mac—yet—but Tiger sets the stage for some truly incredible system capabilities.
64-bits in Real Terms
The idea of a 4 terabytes of physical memory, much less 16 exabytes of address space, is a bit mind-blowing. To help you wrap your head around the scale of data that we are talking about, consider the following:
- A DVD can hold 4.7GB of data storing over 2 hours of high quality MPEG-2 video.
- 250 DVDs can contain about a terabyte of data.
- 4 250GB hard drives, the largest currently available in the Power Mac G5, will also store a terabyte of data.
- A fully loaded Xserve RAID can currently hold 5.6 terabytes of data.
- The largest physical library in the world, the U.S. Library of Congress, contains about 20 terabytes of text.
- The Internet Archive, dedicated to maintaining an archive of the Internet, holds over a petabyte (1000 terabytes) of data and is growing at over 20 terabytes a month. It would take 175 Xserve RAIDs, 4000 250GB hard drives, or 4.4 million DVDs to store that much data.
- An exabyte can contain 1000 Internet Archives—at least right now.
No matter how you slice it, 16 exabytes is a lot of address space. There's a lot of headroom for the future and it will take a long time to exhaust the potential of the 64-bit address space.
Tiger's 64-bit Support
The focus of Tiger's 64-bit support is to enable C and C++ applications that are most likely to benefit immediately from a larger address space. These include scientific data processing applications, rendering engines, and high load servers. These applications have naturally large data sets. Typically, these applications are faceless—meaning that they don't have a GUI—and are executed from the command line.
To meet this focus, Tiger ships with a 64-bit version of libsystem—the system library implementing most of the fundamental UNIX APIs. In addition, Tiger comes with a 64-bit PowerPC ABI, based on the 32-bit ABI. 64-bit binaries are contained in an updated Mach-O format that can run on G5 systems with Tiger or later installed.
It is important to note that in Tiger, the support for 64-bit programming does not extend throughout the entire set of APIs available on Mac OS X. Most notably, the Cocoa and Carbon GUI application frameworks are not ready for 64-bit programming. In practical terms, this means that the "heavy lifting" of an application that needs 64-bit support can be done by a background process which communicates with a front-end 32-bit GUI process via a variety of mechanisms including IPC and shared memory.
Fat Binaries
The updated Mach-O format in Tiger supports the concept of Fat Binaries. These allow both 32-bit and 64-bit executables to be shipped as part of the same file. This means that developers and network system administrators can distribute a single version of an application to all users regardless of whether their system contains a G3, G4, or G5 processor. When the application is executed, the system automatically selects the appropriate code for the system without user intervention. Using Fat Binaries greatly simplifies distribution, installation, and administration of applications.
I/O
64-bit applications can use posix read, write, and ioctl APIs to access storage devices and can use sockets for network I/O. However, they won't be able to use IOKitLib and IOUserClient plug-ins to access devices.
Benefits to 32-bit Applications
Tiger's support for 64-bit computing doesn't leave 32-bit applications out in the cold. 32-bit applications will be able to access most of the 64-bit based registers in the G5 as well as take advantage of the 64-bit based load/store units and logic units of the G5.
In addition, 32-bit applications can take full advantage of the G5's massively parallel execution core. This core sports two pipelined double-precision floating point units, support for more than 200 in-flight instructions, and more than three times the internal bandwidth of the G4. Even when running 32-bit applications, the G5 makes short work of the most complex tasks.
Creating 64-bit Applications
Creating a 64-bit application is fairly straightforward. For the most part, it's programming as usual. Xcode and the GCC compiler take care of most of the details. You do need to keep in mind the 64-bit data model as well as the limitations of the 64-bit support in the Mac OS X frameworks.
Enabling the 64-bit Compiler in Xcode
To build a 64-bit executable from within Xcode, all that you need to do is edit the executable's target and make the "Architectures" setting either ppc64 or ppc ppc64. The first of these will produce a 64-bit only binary. The second will produce a fat-binary containing the executable code for running on both 32-bit and 64-bit systems.
LP64 Data Model
The 64-bit data model used by Mac OS X is known as "LP64". This is the common data model used by other 64-bit UNIX systems from Sun and SGI as well as 64-bit Linux. The LP64 data model defines the primitive types as follows:
- ints are 32-bit
- longs are 64-bit
- long-longs are also 64-bit
- pointers are 64-bit
The use of the LP64 data model ensures that source code created for Linux, Sun, or SGI platforms can be easily ported to Tiger. There are, however, a few important things to note about the LP64 data model in comparison to programming in the 32-bit world. These are:
- Since pointers are 64-bit, ints can no longer hold pointers.
- Casting variables can destroy data if you cast between a 64-bit type and a 32-bit type.
- An unsigned 64-bit number may look like a signed 32-bit value.
- Be sure to use the correct printf directives. For example, use %p to print pointers.
64-bit API Support Macros
To conditionally compile 64-bit code or define 64-bit APIs, you can use the __LP64__ and __ppc64__ macros. For example, the following shows a function prototype defined two different ways depending on whether the code is being compiled as a 64-bit executable or not:
#ifdef __LP64__
int getattrlist(const char*,void*,void*,size_t, unsigned int);
#else /*__LP64__*/
int getattrlist(const char*,void*,void*,size_t, unsigned long);
#endif
Adding a GUI to a 64-bit Application
As mentioned earlier, the use of a 64-bit address space is limited to non-GUI applications in Tiger. This doesn't mean, however, that the results of a 64-bit enabled computation can't be displayed on the screen. The strategy that you should use is to create two separate executables that are cooperative. These are:
- A 32-bit based Cocoa or Carbon GUI executable that the user can launch and which presents the application's user-interface.
- A 64-bit based command-line tool that is launched by, and under the control of, the GUI.
Once the 64-bit executable has been launched, communication between the two executables can be accomplished using one or more of the following strategies:
- Simple message passing using the standard input and output pipes of the command-line task.
- Message passing using a UNIX domain socket.
- Shared memory.
- Mach based IPC messaging.
Any of these strategies will work. However, you should use the simplest possible strategy for your application so that you can preserve future flexibility. For example, if you use a filesystem-based socket to communicate between the 32-bit and 64-bit executables in your application, you have the ability to later convert your application to use a TCP/IP client-server approach. This would let you run the 32-bit client on any Mac while communicating with a 64-bit server process running on a G5-based Xserve.
Conclusion
As you have seen, Mac OS X Tiger takes the next step in 64-bit computing with the ability to build certain types of applications, such as server applications, and background processes used by renderers and computational engines, as 64-bit applications. These lower-level tools can communicate with graphical front-end applications for presentation and other visually-oriented functions.
Mac OS X's transition to 64-bit computing is a long-term effort. The support in Tiger for 64-bit applications is just the second of many phases. The timing and specifics of additional support for 64-bit applications will be decided with feedback from the developer community.
How You Can Get Started
Getting started couldn't be easier. The first thing you should do, if you haven't already, is to become an Apple Developer Connection member. A free ADC Online membership provides access to the latest Xcode updates and other developer tools. An ADC Select Membership goes further by providing shipping versions of Mac OS X Tiger and Xcode 2 on disc, along with download access to Mac OS X Tiger Server. Select membership also includes direct, one-on-one consultation with Tiger support engineers, a discount on hardware through the ADC Hardware Purchase Program, and ongoing access to pre-release software.
Next, you'll want to set yourself up with the Xcode 2.2 developer tools. It ships as part of each and every copy of Mac OS X Tiger on the Install DVD. Just double-click on the Xcode 2.2 package on the DVD and the developer tools—as well as a set of example code projects and comprehensive documentation in the ADC Reference Library—will be installed on your system. The documentation and sample code will help you learn more about the technologies covered in this article.
No comments:
Post a Comment