apple drops 64-bit carbon support?

Luminary
Posts: 5,143
Joined: 2002.04
Post: #31
Essentially "just the registers"

i386 has 8 32-bit integer registers,and 8 128-bit SSE registers. x86_64 has 16 64-bit integer registers and 16 128-bit SSE registers. Both have 8 64-bit MMX registers (which overlap the x87 FPU's stack, though I don't think the x87 is available in x86_64)

The additional registers allow the compiler to better indicate [lack of] data dependencies to the CPU, allow it to better keep temporaries in efficient storage, etc.

The additional registers also allow sufficient room for a more efficient register-based function calling convention, similar to PowerPC, rather than the stack-based one i386 is forced to use.

Instructions which use the new registers are longer than instructions which don't, so there is a slight offset to the performance benefits they provide (more of an offset on Intel than on AMD), but it's still overall a substantial improvement.

Here's a couple of relevant messages from Ian Ollmann:
http://lists.apple.com/archives/PerfOpti...00007.html
http://lists.apple.com/archives/PerfOpti...00011.html
Quote this message in a reply
Member
Posts: 81
Joined: 2007.05
Post: #32
Thanks for the tips.

Glad I got rid of carbon fonts in my project. ( though, they did look really nice )

Its interesting to see how the universal format adds flexibility. Makes one wonder -- an iPhone or iPod would just be another architecture flag. Its like the inverse of java except compile once and run native everywhere.
Quote this message in a reply
Member
Posts: 81
Joined: 2007.05
Post: #33
Thinking about this issue some more. This is sorta evil. He he...

The HID stuff has a device list. Just happens the keyboard and mouse is in the list too -- which is what most game developers are really after. So, I just read that and call my c++ call back. I suppose that is similar to reading a gamepad. Looking the HID stuff over, it appears the only carbon thing there is a timer for a callback. ( I happen to be using carbon at the moment ) There is a carbon timer thats used to poll the devices but I ditch that and replace it with a pthread.

To build the OpenGL context I'm using cgl. Its fullscreen I'm after. If I recall, cocoa is using cgl too under the hood too. I recall agl is tied up in Carbon and that was to be avoided.

I use c++ but I get rid of all carbon / cocoa stuff and build for 64 bits. Cool

Still, its probably safer to use Cocoa.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #34
Depending on precisely what is and isn't available, you may get hung up on HideMenuBar, for example, or KeyTranslate. I've tried and failed to avoid both Carbon and Cocoa simultaneously before now.

From the summary page I linked earlier, it looks like the Carbon Event Manager will remain, so your keyboard and mouse input and timers should still work fine...
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,990 May 7, 2002 06:24 AM
Last Post: deekpyro