[Openmcl-devel] More Intel: Rosetta & Universal Binaries

[David Steuber]

On Jun 10, 2005, at 5:06 PM, Raffael Cavallaro wrote:

> Now some might say that this due to the nature of the Carbon framework 
> - that is, that it is lower level than Cocoa and therefore does not 
> for example inherently take care of the endian issues that Cocoa does. 
> Quite possibly so. But why hasn't Apple been maintaining a secret set 
> of Carbon APIs that just do the right thing so that all that is needed 
> is a recompile? My answer is that this would have entailed a good deal 
> more work for Apple, and again, Apple does not have infinite manpower 
> resources.

You've taken a simple comment about Apple's desire to have everyone use 
Xcode rather far afield.  Now you are talking about endian issues?  
Perhaps you've had vastly more programming experience than I have in C 
and it's children than I have.  In my experience, endian issues are 
irrelevant accept when exchanging data between two architectures with 
different byte ordering schemes.  That is why network byte ordering is 
a standard, so that it doesn't matter if you are big or little endian.  
That is why file formats contain a tag when either endian order is 
supported.

Universal Binaries are a bit pathological because they represent not 
only data exchange between two architectures but executable data at 
that.  In spite of that, the programmer from Wolfram didn't seem to 
have too much trouble porting Mathematica which is not written all in 
Objective-C, if there is any there at all.

The real issue is with programs that use assembler or emit machine code.

You've made your point about why people should use Cocoa abundantly 
clear by now.  Let's let it drop now and consider how we can help 
OpenMCL make the transition.  I'm sure that no one disagrees that 
OpenMCL having a working Cocoa bridge is a good thing.