macOS ObjC 1.0 versus 2.0 - PPC versus Intel?

[zmttoxics]

I just read a previous post that has something to do with this. I own a g5 and a macbook and I am just picking up ObjC / Cocoa now so I want to get it straight.

Is there a difference between 1.0 and 2.0 related to the platform? Does ObjC only support 1.0 for the PPC platform?

 

[lee1210]

The switch to objective-C 2.0 was with the release of OS X 10.5. If either machine is running 10.4 or below, you won't be able to use 2.0 if you want your program to run on both. Where the platform really matters is if you're doing bit-shifting things, storing endian-dependent data (any primitive other than chars) to disk that you want to exchange between machines, etc.

-Lee

 

[zmttoxics]

The switch to objective-C 2.0 was with the release of OS X 10.5. If either machine is running 10.4 or below, you won't be able to use 2.0 if you want your program to run on both. Where the platform really matters is if you're doing bit-shifting things, storing endian-dependent data (any primitive other than chars) to disk that you want to exchange between machines, etc.

-Lee

They are both running 10.5 so that is a non issue.

I gather that the PPC chips are Big Endian and Intels are Little Endian. I have never done bit shifting on anything other then an x86 platform (I just got my G5 a month and a half ago ). Are the functions in ObjC / the osx libraries for automatic conversions or is it up to the programmer as always to be platform aware?

How does this tie into making an application Universal?

 

[lee1210]

You can set the build target to universal in XCode. Not at a Mac, so I'm not sure exactly where you might find that.

You don't need to worry about your endianness until you are persisting data. If you have an 4-byte integer literal 7 in your code the compiler will store it as:
0x00000007 for little-endian (x86)
0x07000000 for big-endian (PPC)

You'll never need to know about this. When you do have to worry is if you write 1000 4-byte integer values to a file on disk. If you will never move such a file between two machines, you still have no problem, it will be written in the native endianness of the system, so when it is read back you have no problem. Where you do have a problem is if this is moved to a system with the other endianness. When it is read back, the values will all be different in memory. So a 4-byte integer 7 written on big-endian, and read on little-endian will be interpreted as 117440512 and vice-versa.

One way around this is to persist data in a relational-database, so you'll have a library that is specific to each system that deals with this for you. There are other ways to handle this. One is to do it yourself, by testing the system endianness, and always storing in one or the other, and converting where necessary. For 4000 bytes, this isn't a big deal. For 3GB of data, this would become very time consuming.

This is not a very fun problem. We moved a lot of legacy Fortran and C from HP-UX on PA-RISC and moved it to Linux on x86 recently. Between the OS changes and the endianness changes this took quite a while. This problem is a good argument for VMs running your code. For example, the JVM is big-endian, but it's big-endian no matter what the endianness is of the host system.

-Lee

 

[zmttoxics]

You can set the build target to universal in XCode. Not at a Mac, so I'm not sure exactly where you might find that.

You don't need to worry about your endianness until you are persisting data. If you have an 4-byte integer literal 7 in your code the compiler will store it as:
0x00000007 for little-endian (x86)
0x07000000 for big-endian (PPC)

You'll never need to know about this. When you do have to worry is if you write 1000 4-byte integer values to a file on disk. If you will never move such a file between two machines, you still have no problem, it will be written in the native endianness of the system, so when it is read back you have no problem. Where you do have a problem is if this is moved to a system with the other endianness. When it is read back, the values will all be different in memory. So a 4-byte integer 7 written on big-endian, and read on little-endian will be interpreted as 117440512 and vice-versa.

One way around this is to persist data in a relational-database, so you'll have a library that is specific to each system that deals with this for you. There are other ways to handle this. One is to do it yourself, by testing the system endianness, and always storing in one or the other, and converting where necessary. For 4000 bytes, this isn't a big deal. For 3GB of data, this would become very time consuming.

This is not a very fun problem. We moved a lot of legacy Fortran and C from HP-UX on PA-RISC and moved it to Linux on x86 recently. Between the OS changes and the endianness changes this took quite a while. This problem is a good argument for VMs running your code. For example, the JVM is big-endian, but it's big-endian no matter what the endianness is of the host system.

-Lee

Thanks Lee! This is an excellent reminder for me. I am going into my last year of computer engineering and last semester required a ton of bit shifting and data manipulation under C. I was able to stay cross platform compliant between my linux workstation and my macbook very easily (both x86) but it appears the G5 may throw a kink into the mix...

Thanks again!

 

[Santiago]

Apple provides CoreFoundation functions to take care of this for you. See http://developer.apple.com/document...nceptual/CFMemoryMgmt/Tasks/ByteSwapping.html

 

[lee1210]

Apple provides CoreFoundation functions to take care of this for you. See http://developer.apple.com/document...nceptual/CFMemoryMgmt/Tasks/ByteSwapping.html

Nice, I was unaware of those. even an "optimized" version of this is going to require a lot of memory bandwidth for a lot of data, so if a lot does have to be committed to disk and read back it still might slow things down.

-Lee

 

[Sander]

This is not a very fun problem. We moved a lot of legacy Fortran and C from HP-UX on PA-RISC and moved it to Linux on x86 recently. Between the OS changes and the endianness changes this took quite a while. This problem is a good argument for VMs running your code. For example, the JVM is big-endian, but it's big-endian no matter what the endianness is of the host system.
-Lee

Hmm. In that case, when running the VM on a machine with different endianness, wouldn't you pay the price for every operation instead of just when loading the data?