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

[Raffael Cavallaro]

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:

<http://developer.apple.com/documentation/MacOSX/Conceptual/ 
universal_binary/universal_binary.pdf>

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.


regards,
Ralph


Raffael Cavallaro, Ph.D.
raffaelcavallaro at mac.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20050611/b76c6abf/attachment.htm>