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

I've been doing 32 and 64-bit programming on AIX for a while now.

As Stephane mentioned, for AIX the libraries and executables are completely segregated. The Apple/gcc ABI and object file formats are completely different than IBM's (and have no legacy restrictions), so the experience doesn't necessarily directly translate, but it might signal that the object code is not allowed to mix because the problems are too egregious to deal with.

It's worthwhile to note that AIX changed the object format for 64-bit programs in a non-backward compatible and non-forward compatible manner when going from AIX 4.3 to AIX 5. Such a complete change is enough of a hassle on customers to indicate significant lessons-learned from the first object model.

Chris Kane's recommendations are similar to my own to my own fellow developers in AIX land.

In particular, Chris Kane wrote:
Use C99's stdint.h and inttypes.h headers.

Yes! Use the fixed-size integer types (e.g. uint32_t, int64_t) and then you can and should assume the type will correctly hold and handle the specified number of bits exactly, always. Also, the types include special types (intptr_t and uintptr_t) which are integer types large enough to hold any data pointer.

Similarly, if a system call requires a special size type, such as size_t or signal_t, then please use that type rather than int or long because it may matter when moving to 64-bit or to a future version of the operating system. (This is always good sense, but especially critical when compiling for both 32-bit and 64-bit environments.)

Chris Kane wrote:
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?).

Yes! But there are macros in that people can use to make it easy to get the correct behavior. They've been mentioned in this list before, but they are still unknown enough, and now becoming even more relevant, that it may bear some repeating.

These macros are in <inttypes.h> on AIX, Linux (Redhat 7.1 and 7.2 specifically), and MacOS X. The comments in the MacOS <inttypes.h> were the best.

General comment about the header:

/*
* <inttypes.h> -- Standard C header, defined in ISO/IEC 9899:1999
* (aka "C99"), section 7.8. This defines format string conversion
* specifiers suitable for use within arguments to fprintf and fscanf
* and their ilk.
*/

Specifically about the printf macros:

/* "C++ implementations should define these macros only when
* __STDC_FORMAT_MACROS is defined before <inttypes.h> is included."
*/

Both MacOS X and Linux enforce this with

#if !defined __cplusplus || defined __STDC_FORMAT_MACROS

around the macros, but AIX does not.

Here's an example of usage:

fprintf( stderr, " signed int=%"PRIx32"\n", my_signed_int );
fprintf( stderr, "unsigned long=%"PRIx64"\n", my_unsigned_long );


When 64-bit compilation is available, I'd recommend compiling 32-bit apps for 64-bit execution to find and avoid 32-bit specific assumptions (e.g. an int can hold a pointer!) sooner than later. Do this even when you never intend your app to need to be made available as a 64-bit application. Think of it as a "lint"-like test -- plus who knows when someone in the future will ask you to make a 64-bit library of your 32-bit application's functionality so they can call that functionality directly from their 64-bit application (assuming object code segregation like that of AIX). Or the data on which you operate just grows so that greater than 4 Gb of memory is required -- you never thought you'd see the day, but then here it is.

AIX 64-bit Performance in Focus (SG24-5103)
http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg245103.pdf
An older publication but still provides a good overview of issues related to 64-bit addressing.


I think it's worth noting the following catch of 32 vs 64-bit compilation on AIX and asking whether the same catch must apply to Apple's usage of the G5.
(quote from http://www.eservercomputing.com/ibmunix/articles/index.asp?id=415&dir=/ ibmunix/articles/#)
---
Comparing 32- and 64-bit addressing mode application performanceTheoretically, there shouldnt be any difference between the two modes; only addresses should be affected. In reality, though, these differences exist:

* 64-bit pointers, if spilled from registers to L1 cache and possibly to L2 cache, will consume more cache space and bandwidth. This could slow computation speed compared to a 32-bit application.
* Certain eight-byte integer hardware instructions are only available if compiled with -q64a feature of the PowerPC* architecture upon which the IBM POWER3 and POWER4 chips are built. An application with many eight-byte integer computations can run much faster if compiled -q64, even if it uses little memory.
---

So, it appears there is a catch such that to get the IBM VisualAge++ compiler to use 64-bit instructions, it must also use the 64-bit addressing/object-mode, but there may be a performance benefit for programs that can be compiled with 32-bit addressing/object-mode but using the PowerPC64 architecture otherwise. As I read the g++ manpage on my OS X 10.2.6 machine, -mpowerpc64 option currently gives that nice mix since there is no 64-bit addressing/object-mode (yet).


Travis Pouarz
_______________________________________________
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.


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.