[Openmcl-devel] More Intel: Rosetta & Universal Binaries
david at david-steuber.com
Sat Jun 11 00:25:24 UTC 2005
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
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
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.
More information about the Openmcl-devel