apple drops 64-bit carbon support?

Member
Posts: 144
Joined: 2004.07
Post: #16
ThemsAllTook Wrote:From what I understand (which is quite a bit more than before since WWDC), 64-bit applications get little to no benefit over 32-bit applications if they don't need to address more than 4 GB of memory at a time. If you think about it, how often do you actually need to do that in an application?

Since x86 chips weren't designed from the start for 64-bit (as PPC were), registers had to be added to the new 64-bit x86 chips to support 64-bit - so recompile for 64-bit and get more registers (eg better performance).
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #17
From a post in the the carbon-dev lists:
http://www.engadget.com/media/2006/08/dsc_0487.jpg
http://www.engadget.com/media/2007/06/dsc_5242.jpg

Personally, I don't care about Carbon too much but... isn't Photoshop a Carbon app, and one that would benefit a lot from being 64bits?

Also, wouldn't a regular game written mostly in plain C but using Cocoa to handle events/windowing/etc (for instance SDL, which basically isolates the game from the Cocoa code) be able to be compiled as 64-bit code? (after all, Obj-C is a strict superset of C). I would guess "yes", otherwise this would be a really big dealâ„¢ for everyone in this community, since as was already mentioned x86-64 can provide noticeable benefits over x86-32, not just limited to a larger addressable space.

I hope the same applies for Obj-C++ though, I'd hate to be forced to make a 3D vector class in Obj-C to gain 64bit support... :/
Quote this message in a reply
Moderator
Posts: 3,571
Joined: 2003.06
Post: #18
PowerMacX Wrote:I hope the same applies for Obj-C++ though, I'd hate to be forced to make a 3D vector class in Obj-C to gain 64bit support... :/
Just use Obj-C and stop using C++! Rasp

Quote:Personally, I don't care about Carbon too much but... isn't Photoshop a Carbon app, and one that would benefit a lot from being 64bits?
I'm sure Photoshop would most definitely benefit from being 64 bits. Adobe must have some of the lamest management in the business. At the speed with which they have demonstrated that they can't keep up with technology and get stuff out the door, we'll be on OS XI before they ever get to 64 bits on OS X...
Quote this message in a reply
Member
Posts: 105
Joined: 2007.03
Post: #19
AnotherJake Wrote:Adobe must have some of the lamest management in the business. At the speed with which they have demonstrated that they can't keep up with technology and get stuff out the door, we'll be on OS XI before they ever get to 64 bits on OS X...

I could be completely wrong, but doesn't Apple own a significant share in Adobe(which would make it all the more bizarre)?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #20
PowerMacX Wrote:Also, wouldn't a regular game written mostly in plain C but using Cocoa to handle events/windowing/etc (for instance SDL, which basically isolates the game from the Cocoa code) be able to be compiled as 64-bit code? (after all, Obj-C is a strict superset of C). I would guess "yes", otherwise this would be a really big dealâ„¢ for everyone in this community, since as was already mentioned x86-64 can provide noticeable benefits over x86-32, not just limited to a larger addressable space.

I hope the same applies for Obj-C++ though, I'd hate to be forced to make a 3D vector class in Obj-C to gain 64bit support... :/

Not quite sure what to quote here, since you seem very confused Rasp

You will be able to build 64-bit applications with C, C++, ObjC and ObjC++. Almost all the frameworks on Leopard (including Cocoa, OpenGL, and the vast majority of what we currently call "Carbon") are 64-bit. The only thing you won't be able to do is make 64-bit GUI apps without Cocoa, since the Carbon HIToolbox is (for apparently political reasons) not 64-bit.

So yes, your example of a 64-bit C++ SDL app is just fine.
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #21
Ah, ok that makes sense. Smile I was a bit confused by the "whether any but ObjC will support 64-bit out-of-the-box" line in one of your earlier posts, which I took to mean something more than Cocoa code.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #22
PowerMacX Wrote:Ah, ok that makes sense. Smile I was a bit confused by the "whether any but ObjC will support 64-bit out-of-the-box" line in one of your earlier posts, which I took to mean something more than Cocoa code.

What I meant is I don't know whether PyObjC or RubyCocoa will be offered as 64-bit.
Quote this message in a reply
Member
Posts: 104
Joined: 2007.01
Post: #23
AnotherJake Wrote:Just use Obj-C and stop using C++! Rasp

Can't do that and still be cross-platform.
Quote this message in a reply
Moderator
Posts: 3,571
Joined: 2003.06
Post: #24
Leroy Wrote:I could be completely wrong, but doesn't Apple own a significant share in Adobe(which would make it all the more bizarre)?
I don't recall ever hearing that, but I'd be interested to know a little more about it. Wouldn't really surprise me if Apple has an investment in Adobe though. Of course, investment doesn't mean management as we all know, one has to take into account that Microsoft has a serious investment in Apple if one wants to count straws with that method!
Quote this message in a reply
Moderator
Posts: 3,571
Joined: 2003.06
Post: #25
GolfHacker Wrote:Can't do that and still be cross-platform.
I'm just yanking on the chains! Rasp

But OTOH, .net and C# aren't cross-platform either, so who cares? I went off on this yesterday already so I'll spare everyone the rant... Sneaky

[disclaimer] Yeah, I know that C# and .Net are somewhat available on the Mac too. But before you go off on me about it, please consider that Objective-C and Cocoa are also somewhat available on Windows. "somewhat" being the operative term here. [/disclaimer]
Quote this message in a reply
Member
Posts: 81
Joined: 2007.05
Post: #26
GolfHacker Wrote:Can't do that and still be cross-platform.

Ya, I get the vibe. Not sure what all the glee is about on this subject.

I recall that many game frame works, physics libraries, xml parsers, etc. are c++ based. Now its going to be another hurdle for people. Ah, when they port they'll use Cider now.

Pretty funny when Apple spends a wad to get a browser on windows too. But that indicates the service part of the company is flexing its muscles.

In my case, I'll probably have to break things into two programs. One program is going to be for the religious wars -- the events interface. The second is the game in 64 bits. So, you'll have to pass events between the two programs. Either pipe it in or tcp/etc etc. Probably better to break it out anyways.

Sort of liked the book "Cocoa Programming For Mac OS X", Hillegass. He is the big nerd ranch dude.

Oh well, sometimes you have to go around the Apple. Ta Ta ... Smile
Quote this message in a reply
Moderator
Posts: 3,571
Joined: 2003.06
Post: #27
macnib Wrote:I recall that many game frame works, physics libraries, xml parsers, etc. are c++ based. Now its going to be another hurdle for people. Ah, when they port they'll use Cider now.
I know we're all kind of in the prognistication business in this thread since none of us truly know what Apple's final intention will be with this, but... Linking against Cocoa for the system level UI elements like the basic window, GL context and menus (and getting 64 bits) has nothing to do with the rest of your game engine or what libraries you use for physics or scripting and whatnot; they will all get 64 bits too as long as you are using Cocoa for your basic environment setup [edit for clarity: assuming the libraries are also compiled for 64 bit, but that doesn't have to have anything to do with Cocoa]. The language you use outside of that basic Cocoa environment setup and OS services should have nothing to do with whether you get 64 bits or not -- you can be free to use C/C++/D/E/F/G/whatever.

Maybe I am not reading this right, but it *seems* like there are some major misconceptions about what it means to use Cocoa, and how it is used. Using Cocoa does not mean that your program has to be written entirely in Objective-C at all (but after you start using it you'll begin using it for more, I promise). Calling out to other languages from Cocoa code is very easy for the most part (trivial for C). And bridging back into Cocoa from other languages can be just as easy.
Quote this message in a reply
Member
Posts: 81
Joined: 2007.05
Post: #28
ok, lets clear up some misconceptions.

1. If your trying to integrate c++ with objective-c, then its going to boil down to using extern "C" stuff. Just make sure the pointers are correct because c does not understand inheritance and extern "C" will resolve the mangled names etc. So, I just made a simple test program and it works in a test cocoa program. Easy enough. Sort of dovetails with the using c discussion earlier in the thread.

2. Make sure all the frameworks are 64 bits. So, here is a question ... if they are not all 64 bits then I'd assume your app is going to run as 32 bits? So, we avoid the Carbon framework and migrate to cocoa. Also, other cross platform frameworks and anything they depend on must be built as 64 bits. So, most of the Leopard frameworks are already built this way.

3. Will 64 bit apps be compatible with older operating systems. eg 10.4 ? Or will they run in 32 bit mode? I 99% want to say they will not be compatible but I'm not sure.

4. Really all this boils down to is a larger address space. In the vast majority of cases, this probably is not going to matter very much to most applications. But I suspect its a waiting game because of issue 3?

So, unless I'm some nut who wants to use 20 gigs of textures ( most of which would be stored in memory because my card certainty would not have enough room ), then, at the present, this really is not an issue. Smile
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #29
1) You can name your source files .m and mix C and ObjC freely, or .mm and mix C++ and ObjC freely. It's not difficult.

2) 64-bit is like another architecture in your universal binary. You'll build for ppc, i386 and x86_64, and Xcode will magically take care of it. Just as with the universal binary transition, all your source must build as each of the architectures you want, and all the libraries and frameworks you link to must be available for each of the architectures you want, or your program will not compile.

The vast majority of Leopard frameworks are available as 64-bit, and the vast majority of open-source libraries already compile for 64-bit Linux, so except for the particular case of the Carbon HIToolbox, you're unlikely to find problems.

3) Just as "universal" ppc+i386 apps run on PowerPC and 10.3.9 machines, "universal" ppc+i386+x86_64 apps should run on 32-bit and 10.4.10 machines.

4) As has been said, x86_64 provides performance benefits in addition to a larger address space, so for games, it is a bigger deal than it is for most applications. Leopard also supports ppc64 in this way, but ppc64 is almost always a small performance penalty, so it is really only relevant to applications that need a >4GB address space.

Note that even for games, being able to mmap 9GB of data might be a convenient way to deal with assets...

But no, it's not an issue. If you're not already using the Carbon HIToolbox, don't start. If you are already using the Carbon HIToolbox, consider migrating to Cocoa for that small part of your program.

All it is is a shock that after announcing full 64-bit support across the board previously, Apple have decided for apparently political reasons to treat Carbon as a second-class citizen, without fanfare.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #30
OneSadCookie Wrote:As has been said, x86_64 provides performance benefits in addition to a larger address space

Details, please? Or is this just what Derek posted about having more registers?
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Carbon Apple quit Event troubles deekpyro 3 5,745 May 7, 2002 06:24 AM
Last Post: deekpyro