Macintel and LabVIEW
I recently saw an article from a developer at Adobe about Adobe's Macintosh and the Intel switch. I found myself nodding a lot reading the article. However, I think they are in this position because they did not listen to Apple.
When we ported LabVIEW to Mac OS X (LabVIEW 7.0) we had several decisions to make. Should we keep LabVIEW CFM, or make it Mach-O (native binary format). CFM definitely would have been easier. It would have also given us a single binary that would work on Mac OS 9 and Mac OS X. We could have kept compiling with CodeWarrior (the IDE/Compiler of choice for many Mac developers at the time). It had a lot of advantages. If we would have gone with Mach-O, we would have access to new APIs and we would be following Apple's suggestions, but we would loose the fast compiler, excellent debugging environment and we would have to rebuild everything in Xcode (then ProjectBuilder).
A wise senior Mac developer here in the LabVIEW group decided we should bite the bullet and follow Apple's suggestion. We would not get rid of the CodeWarrior build, so when MetroWerks was able to come up to Xcode's level of Mach-O, we could switch back (which never happened).
LabVIEW has a very large Xcode project, so I feel the pain of the Adobe engineer. Xcode does not do well with large projects, although it has been making huge leaps in every release. Distributed compiles has made the slow compiles much more manageable. The editor is still slow. Link times will put you to sleep (zero link does not work well on large projects). It was painful, to say the least, but we did it because we trusted that Apple knew what they were talking about.
Adobe, on the other hand, did not listen to Apple (or maybe Apple didn't tell them?). Now they are faced with converting over to Xcode and getting everything Macintel ready.
There are a few things in LabVIEW that make it more difficult to port to another processor architecture. The biggest is probably that it is a compiler. When a VI is run, we compile the diagram to native code, and then run it. So for LabVIEW, it is not just a matter of recompiling, we actually have to change our code to compile native x86. One benefit we have, however, is the most of the hard work on that side was done with LabVIEW on Windows and Linux. All that was left was to massage the x86 code generator to follow Mac OS calling conventions, not trivial, but much easier than starting fresh on the compiler part.
We of course found all sorts of Endian assumptions in Mac specific code, along with all the other minor things that all need to be cleaned up.
The bottom line is that we listened to Apple and our transition is going pretty smooth. Adobe didn't and now they are paying the price.
Now what got us is that Apple led us to believe that consumer hardware would not be available until summer. When they sprung a January release on us, we had already set our release schedules. I imagine that is also the case with Adobe and Microsoft. Any project of that scale would be difficult to port, and moving the schedule up six months really causes problems.
Well, I just wanted to give another developer's perspective on the Macintel transition. I think this one is going very well, especially compared to the Mac OS 9 to Mac OS X transition.
[Corrected a statement about Apple's timeline for transitioning to Intel hardware 2006-03-24 13:29pm CST]
When we ported LabVIEW to Mac OS X (LabVIEW 7.0) we had several decisions to make. Should we keep LabVIEW CFM, or make it Mach-O (native binary format). CFM definitely would have been easier. It would have also given us a single binary that would work on Mac OS 9 and Mac OS X. We could have kept compiling with CodeWarrior (the IDE/Compiler of choice for many Mac developers at the time). It had a lot of advantages. If we would have gone with Mach-O, we would have access to new APIs and we would be following Apple's suggestions, but we would loose the fast compiler, excellent debugging environment and we would have to rebuild everything in Xcode (then ProjectBuilder).
A wise senior Mac developer here in the LabVIEW group decided we should bite the bullet and follow Apple's suggestion. We would not get rid of the CodeWarrior build, so when MetroWerks was able to come up to Xcode's level of Mach-O, we could switch back (which never happened).
LabVIEW has a very large Xcode project, so I feel the pain of the Adobe engineer. Xcode does not do well with large projects, although it has been making huge leaps in every release. Distributed compiles has made the slow compiles much more manageable. The editor is still slow. Link times will put you to sleep (zero link does not work well on large projects). It was painful, to say the least, but we did it because we trusted that Apple knew what they were talking about.
Adobe, on the other hand, did not listen to Apple (or maybe Apple didn't tell them?). Now they are faced with converting over to Xcode and getting everything Macintel ready.
There are a few things in LabVIEW that make it more difficult to port to another processor architecture. The biggest is probably that it is a compiler. When a VI is run, we compile the diagram to native code, and then run it. So for LabVIEW, it is not just a matter of recompiling, we actually have to change our code to compile native x86. One benefit we have, however, is the most of the hard work on that side was done with LabVIEW on Windows and Linux. All that was left was to massage the x86 code generator to follow Mac OS calling conventions, not trivial, but much easier than starting fresh on the compiler part.
We of course found all sorts of Endian assumptions in Mac specific code, along with all the other minor things that all need to be cleaned up.
The bottom line is that we listened to Apple and our transition is going pretty smooth. Adobe didn't and now they are paying the price.
Now what got us is that Apple led us to believe that consumer hardware would not be available until summer. When they sprung a January release on us, we had already set our release schedules. I imagine that is also the case with Adobe and Microsoft. Any project of that scale would be difficult to port, and moving the schedule up six months really causes problems.
Well, I just wanted to give another developer's perspective on the Macintel transition. I think this one is going very well, especially compared to the Mac OS 9 to Mac OS X transition.
[Corrected a statement about Apple's timeline for transitioning to Intel hardware 2006-03-24 13:29pm CST]
posted by Marc | 8:25 AM
6 Comments:
Very great news !!!
I want my LabVIEW in Universal Binary :) :) (http://guide.apple.com/universal).
One question about the switch PPP to Intel : could we hope more support of "only windows" features like Bluetooth, Timed Loop, etc… ?
odjau
We will evaluate each feature on a per-item basis. If you have specific features you need or would like to see on the Mac, please take the Support Survey for Mac OS X (near the bottom of the page). We need feedback on where we can best spend our Mac efforts.
Thank you very much for this very valuable information. I am glad to hear about some of the technical details of the porting process and the time scale. No doubt I want to keep on labVIEWing on the Mac, the birthplace of LabVIEW 20 years ago!
Like everyone said: thanks for the honest and hopeful information!
I still have a stack of NI hardware (much of it new in 2004), but have moved more and more away from LV (which i loved in the early 90s) as it has become more "powerful" (complex) and more "simple" (wizard-minded)
These are a terrible trap for developers - the power of complexity is appealing, and building wizards to help people cope with it (as the app has lost it's intuitive feel) becomes a self-fulfilling downward spiral of more wizards hiding worse UI.
On ac concrete note:
#1 request: DAQ on MAC
#2 request: improving labview doesn't
mean making it like C# or windows.
Attend to the roots of the program: virtual engineering.
cheers,
tim
Stumbled across your blog accidentally.
Thanks for the insight. I'm a Windows developer thinking of taking the plunge into Mac development. At this point in the game, would you tell a new Mac would-be developer to buy a stable (ie PPC) machine, and learn on that, and would you say, buy an Intel machine, and learn XCode/etc on it?
Also, are there alternative build tools that handle large projects on the Mac, better than the XCode platform? Ie, ANT-style command line build tools that work on Mac?
Warren
In the question as to getting a PowerPC or Intel machine to develop on, I would probably suggest an Intel machine. It will give your more longevity. The new Intel machines are fast. Even the iMac was surprisingly faster than my Dual 1.8 G5. Plus Apple will be continuing support for Intel, where as PowerPC support will be dropped at some point in the future (probably more than two years out would be my guess).
I like Xcode, and if you are doing Native code (C/C++/Objective-C, Objective-C++) than I would suggest going with Xcode. Apple seems to be using that was the transition tool of choice. If nothing else, I would suggest getting to know how to use Xcode even if you are not planning on using it.
However, I believe that Ant is fully supported on the Mac. I even found an article discussing integrating Ant with Xcode.
For Java development, I don't think it matter much, as long as you are doing 100% Pure. In my Java projects, I do everything old school, command line. Yep, javac java, jar, javadoc, the whole nine yards.
I hope you come join us in the Mac developer community. I've enjoyed the last 17 years as a Mac developer.
Post a Comment
<< Home