Xcode preprocessor defines

Okay so you have several macros :
_ppc_ = PPC 32 bits
_ppc64_ = PPC 64 bits
_i386_ = Intel 32 bits and/or 64 bits
_x86_64_ = Intel 64 bits

You also have interesting macros like :

_LP64_ = PPC and Intel 64 bits
NS BUILD_32_LIKE64 = Leopard only, it allows you to use simplification available in Leopard, for example, with Cocoa, you would have NSPoint, NSSize and NSRect and in Core Graphics framework you would have CGPoint, CGSize and CGRect, this macro allows you to make these types compatible : NSPoint = CGPoint, NSSize = CGSize and NSRect = CGRect.

And also you have the availability macros defined in AvailabilityMacros.h.

I can tell you right now you don't want to have a bunch of #defines in your code for processor types. There are much, much better ways to handle this situation. If you explain precisely what you are trying to accomplish, I'm sure we can come up with some solutions that are much better than #define's.

Brian Postow wrote:
Oh, clearly I don't want them either. however, they're sort of unavoidable... at least temporarily.

I've got a couple of places with old PPC assembler.

Yes, that is pretty unavoidable. You'll want to handle that with the specific #define that matches that cpu, then do #else and do the rest not using assembly.

Also, the code historically uses old style resource files for some preference data. I'm in the process of turning that into text-files. However, the intel native version won't be able to read the resources (endian issues), so the PPC version reads the resource file and writes out the text file in preparation for eventually only using the intel version...

I don't like the sound of that. Are you sure the Intel can't read the resource data? If it is just regular resource data, it should be no problem. If you have binary structures inside that resource data, you can read it in and swap the bytes. What you do is read it into a buffer, knowing that the data has a certain endian-ness, and then use the platform independent byte-swapping routines to conver the data to whatever is appropriate for the currently running (PPC or Intel) system.

Any processor can handle any type of data, as long as it knows what the data is. Furthermore, your code can do that determination at runtime using platform independent routines, without #defines.

The ZIP file format, for example, uses both big and little-endian data at the same time.

All the #define macros or byte swapping routines you'll need are listed here.

Brian Postow wrote:
And is there a reason why there's a generic i386 define, but no generic PowerPC define? (I can use ! _i386_, or flip my #if #else structures, but I'm just curious)

I have no idea. I don't know the chip architectures that well. That is the problem with the #defines - to use them, you do need to know the architectures and why _ppc_ is not _ppc64_. That is why I would prefer the byte-swapping routines, even on PPC when, in theory, they aren't needed. Apple knows the difference between the chips and knows how to store data into them. You know how your data is formatted. Combine your knowledge of your data with Apple's knowledge of the architecture and you avoid #defines. Your code will also run on Intel. But, I think a text-based (hopefully XML) scheme would be much better. The problem would be if your code to read in these resources is already done and fairly complicated. In that case, it might just be better to check _ppc_ or _ppc64_ and test your code on both a G4 and G5. That link I posted may have more detail on the difference in those processors. I haven't read it myself.