[Openmcl-devel] More Intel: Rosetta & Universal Binaries
raffaelcavallaro at mac.com
Sat Jun 11 04:05:20 UTC 2005
On Jun 10, 2005, at Fri, Jun 10, 8:25 24 PM, David Steuber wrote:
> Now you are talking about endian issues?
If you read Apple's doc on Universal Binaries at:
you'll see that endian issues are one of the largest that Carbon
developers will encounter. There is a whole chapter in a 5 chapter
PDF entitled "Swapping Bytes" so yes, it is a significant porting issue.
> 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's what this transition means - exchanging data (saved documents,
custom resources, etc.) between two architectures (ppc, intel) with
different byte ordering schemes (ppc=big-endian, intel=little-endian).
If a Mac developer's ppc app writes certain multi-byte struct fields
out to disk in byte-address order and reads them back in on an intel
Mac using his own app simply recompiled for intel these multi-byte
data will be read back in reversed. If this same application simply
recompiled for intel writes this same multi-byte data out to disk in
byte-address order, it will be read back in reversed using the same
app running on a ppc Mac.
> That is why network byte ordering is a standard, so that it doesn't
> matter if you are big or little endian.
The real problem is that many developers have implicitly assumed
that byte-address ordering would always be big-endian. This has
worked for them until now because their apps were always compiled for
and run on ppc. Now some versions of their apps will be compiled for
and run on intel, so byte-address ordering is no longer guaranteed to
be big-endian for all versions of their apps.
> 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.
Mathematica is a multi-platform app so they've been doing the right
thing all along - they've had to deal with endian issues for years.
The endian issues will tend to "bite" <groan> Mac-only Carbon
developers who have never dealt with using a little-endian system to
read their big-endian data.
These issues will also affect all Carbon developers - even those
whose applications are cross platform - if their applications write
and read mac specific data such as old style Mac OS Classic
resources. If a developer defined custom resource types, these will
not be automatically byte-swapped by the OS. These developers will
have to write byte swapping callbacks known as "flippers." The
problem of course is that they will now be reading mac specific big-
endian data - custom resources - on a little endian intel system
running Mac OS X.
These issues are largely taken care of for Cocoa developers because
the Cocoa frameworks have dealt with different architectures since
before Apple bought Next. As long as a Cocoa developer uses Cocoa
framework calls to write data and read it back in it will be read
back in properly regardless of what cpu architecture the app is
compiled for and running on.
One byte ordering issue that affects both Cocoa and Carbon is custom
Apple Event data types.
Raffael Cavallaro, Ph.D.
raffaelcavallaro at mac.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel