Re: Which Mac models use the new 64-bit Objective-C ABI?
Re: Which Mac models use the new 64-bit Objective-C ABI?
- Subject: Re: Which Mac models use the new 64-bit Objective-C ABI?
- From: "Påhl Melin" <email@hidden>
- Date: Thu, 20 Nov 2008 20:35:23 +0100
2008/11/20 Nick Zitzmann <email@hidden>:
>
> On Nov 20, 2008, at 7:50 AM, Påhl Melin wrote:
>
>> I'm very tempted to use the new 64-bit Objective-C ABI in my next
>> project. Primarily because of the improved interoperability with C++
>> destructors, that are now called when unwinding Objective-C exceptions
>> and should make it possible to use RAII designs in Objective-C++
>> programs.
>
> The 64-bit environment has sort of been a mixed bag in my experience so far.
> On one hand, you'll never run out of memory, you get lots of ABI
> improvements such as the one you listed, and X86-64 builds will be somewhat
> faster since the software no longer has to push arguments onto the stack
> unless you deal with huge data structures.
>
> However, there are several problems:
>
> 1. A lot of legacy stuff got snipped out of the 64-bit frameworks. If your
> software uses ATSUI, for example, then be prepared to do a lot of rewriting.
> You'll also have to switch your existing code to use NSInteger and CGFloat
> or you'll have problems.
>
> 2. The QuickTime framework isn't available in 64-bit at all; you have to use
> the QTKit framework instead, and QTKit is not as powerful as the QuickTime
> framework yet.
>
> 3. The 32-bit frameworks are over a decade old and are very stable. The
> 64-bit frameworks are relatively new and had some interesting bugs. In
> particular, there used to be a crash bug involving Inkwell and 64-bit apps.
> They've been fixed by now, but this means you'll have to lock out people who
> are for whatever reason sticking to older point releases.
>
> 4. Right now, there are very, very few shipping 64-bit apps available for
> Mac OS X. Because of this, we've had some users notice the 1.7 or so GB of
> VRAM that 64-bit apps allocate on startup, and complain to us that we're
> leaking their memory. Part of this is due to misinformation (Mac OS 9
> veterans are used to VM meaning swap, when that is no longer true), but
> there does seem to be some public reluctance to using 64-bit apps. I think
> this will change in time, as more 64-bit apps ship.
Thanks for the warnings! I'm totally new to both Mac OS programming
and Cocoa so have no old code to maintain and want to have a fresh
start without having to support too much "baggage". I'm also from a
C++ background and don't like to lose one of the greatest C++ features
IMHO – deterministic resource cleanup with stack-allocated RAII
classes. But I'm sure the situation for the 64-bit ABI will improve,
especially with Snow Leopard approaching as well.
>> If I were to require the use of the 64-bit ABI in my next project,
>> which mac models would the application run on?
>
> 1. All Xserves, except for the very first model
> 2. All Power Mac G5s
> 3. All Mac Pros
> 4. All MacBooks, except for the first edition
> 5. All MacBook Pros, except for the first edition
> 6. All MacBook Airs
> 7. All iMacs, except for the CRT-based models, "iLamps", and the first two
> Intel-based models
> 8. All Mac minis starting with the fifth model (mid-2007)
> 9. All VMware virtual machines running OS X Server in X86-64 mode
> 10. All unauthorized Hackintoshes with an X86-64 CPU (Core 2 Duo, Xeon,
> Athalon 64, etc.)
>
> Basically, every desktop/server Mac except for the mini that shipped between
> late 2003-2005, and every Mac that shipped between mid 2007-present supports
> either PPC64 or X86-64.
>
>> And is it possible to
>> detect at runtime if I'm running the old 32-bit ABI or the new 64-bit
>> to enable a fallback on non-64-bit models?
>
> As others have said, you don't need to worry about this, as long as you
> build your app as a four-way universal binary.
I do have to care about this since if I run the app with the 32-bit
ABI and I'm using lots of stack-based C++ classes, an Objective-C
exception will leak all my resources and put the program in an unknown
state since no destructors of my objects have run. So even if I catch
an exception I will probably have to make an emergency exit and
possibly throw away unsaved data (any thread locks will also still be
in place making it even worse). But if the program is running the
64-bit ABI everything will be cleaned up (including thread locks etc.)
and the program will be in a known state.
But, as Shawn Ericsson replied, I can use preprocessor #def:s to
determine the ABI running. The only problem is that the 32-bit version
of the app will be quite vulnerable to errors.
Thanks for all answers everyone!
/ Påhl
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden