 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / CodeWarrior / November 2005CodeWarrior 10 on Macintel
I tried installing CodeWarrior 10 (the free version) on an Intel-based Macintosh development system to see how well it works. It appears that CW 10 runs fine under Rosetta emulation, with virtually no speed impact. Likewise, I was able to compile and run sample apps for both Carbon/CFM as well as Mach-O, and again, no problem. (I of course could not run Classic builds, as there is no Classic on these machines.) The problem I ran into was debugging. Everytime I would try to start up a debug session, CodeWarrior would launch Terminal and show that gdb was starting up, but CW itself went off to la-la land with the spinning beachball of death. I could do nothing but force-quit CodeWarrior. It's as if the Intel version of gdb wants to run, but the Rosetta-emulated CodeWarrior was not detecting it. I assumed that Metrowerks has similar Intel development systems to test on, so perhaps i am doing something wrong? is this a feature available only in the $99 version, or perhaps there is a settings switch I need to turn on? > I assumed that Metrowerks has similar Intel development systems to test > on, so perhaps i am doing something wrong? is this a feature available > only in the $99 version, or perhaps there is a settings switch I need > to turn on? I wouldn't make that assumption. I'm not really sure what MW would benefit from renting any of the transition kits. It may be that CW is doing something funky and unsupported, but it may also be that it's exposed a weakness in the current build of Rosetta. I've already seen such events acknowledged on the developer lists.  SignatureGoal 2005: Convincing James Hetfield to cover the Strawberry Shortcake "Are You Berry Berry Happy?" song. I would be very surprised if MW/Freescale has a single Intel box running Mac OS X. My impression is that they were working on CW 10 for PPC when the Intel announcement was made, and once that happened CW 10 became a dead product they almost didn't bother finishing to the point of being able to release it. It runs on Rosetta by virtue of the fact that it doesn't do anything that prevents running on Rosetta, which is cool, but I have no idea what kind of trickery is used to run CW applications in their debugger, so I don't know who's to blame for that part not working. I'd file bugs with Apple. If it's a problem in Mac OS X, they can fix it. If not, Freescale for sure isn't going to fix it. Larry > I tried installing CodeWarrior 10 (the free version) on an Intel-based > Macintosh development system to see how well it works. It appears that [quoted text clipped - 10 lines] > It's as if the Intel version of gdb wants to run, but the > Rosetta-emulated CodeWarrior was not detecting it. Good guess. :) That's almost certainly what's happening. But even if that was changed (and it'd have to be fixed on the CodeWarrior side), debugging still wouldn't work. That's because Rosetta apps simply aren't debuggable under a standard run of gdb due to the way Rosetta works. You have to launch the application with a special environment variable set, then attach to it with a PowerPC-targeting gdb. This is described in the Rosetta appendix of the Universal Binary Programming Guidelines. It's worth noting that debugging Rosetta applications isn't supported from within Xcode. Given that, I wouldn't expect it to work with CodeWarrior any time soon either, if ever. -Eric SignatureEric Albert ejalbert@cs.stanford.edu http://outofcheese.org/ > It's worth noting that debugging Rosetta applications isn't supported > from within Xcode. Given that, I wouldn't expect it to work with > CodeWarrior any time soon either, if ever. Although inconvenient, I expect that Apple simply feels that it's OK to require developers to own a PPC Mac in order to debug PPC code. > > It's worth noting that debugging Rosetta applications isn't supported > > from within Xcode. Given that, I wouldn't expect it to work with > > CodeWarrior any time soon either, if ever. > > Although inconvenient, I expect that Apple simply feels that it's OK to > require developers to own a PPC Mac in order to debug PPC code. And that speaks volumes about how much support PPC Mac owners will get in 18 months time. No PPC Macs from Apple - no PPC support at all. Milton Aupperle www.outcastsoft.com >And that speaks volumes about how much support PPC Mac owners will >get in 18 months time. No PPC Macs from Apple - no PPC support at all. Not likely, at least not that quickly. People will be not replacing their PPC Macs en masse with Intel boxes. Look at how long it takes developers to require the latest version the OS, and that's just $129. Some people will jump on the Intel boxes, but lots and lots of people will hold onto to their PPC Macs as long as they can (the average life of a Mac is five years), and if a developer wants to make money he's going to have to sell PPC software at least until the Intel boxes become the overwhelming box of choice of people buying software. Plus, we could see a year's span where Apple is shipping both PPC and Intel boxes, so developers will have to accommodate that situation as well, as I don't think many developers will be in a hurry to limit their market to people using Intel Macs. Just my $0.02. Larry > And that speaks volumes about how much support PPC Mac owners will get > in 18 months time. No PPC Macs from Apple - no PPC support at all. No, I think it speaks volumes about Apple's (and FWIW my) opinion about the foolishness of trying to develop for PPC without testing on an actual PPC. > > And that speaks volumes about how much support PPC Mac owners will get > > in 18 months time. No PPC Macs from Apple - no PPC support at all. > > No, I think it speaks volumes about Apple's (and FWIW my) opinion about the > foolishness of trying to develop for PPC without testing on an actual PPC. Exactly. It also tells you a lot about the difficulty of supporting debugging at all under Rosetta. Dynamic translation environments are not designed to support debuggers because debuggers are all about poking at the machine state and dynamic translators don't necessarily have the machine state at any point. That said, you can debug CodeWarrior-built applications under Rosetta using the same techniques as you'd use for Xcode-built applications. You just can't do it from within the CodeWarrior IDE, just as you can't debug Xcode-built PPC apps under Rosetta from within the Xcode IDE. -Eric SignatureEric Albert ejalbert@cs.stanford.edu http://outofcheese.org/ > > And that speaks volumes about how much support PPC Mac owners will get > > in 18 months time. No PPC Macs from Apple - no PPC support at all. > > No, I think it speaks volumes about Apple's (and FWIW my) opinion about the > foolishness of trying to develop for PPC without testing on an actual PPC. No, it speaks about the foolishness of Apple and you thinking that it is OK to just dump a major platform change on developers from one day to the next and not even provide suitable development tools or support. The 68K to PPC move was done properly, this one is just a rush because Steve Jobs never liked IBM in the first place. Apart from that, anybody who has not noticed that Apple has been treating developers like sh.t in the past five years (and far worse than ever before!) has clearly not been paying attention. Thorsten > No, it speaks about the foolishness of Apple and you thinking that it > is OK to just dump a major platform change on developers from one day > to the next and not even provide suitable development tools or support. What are you talking about? We have a year's notice, machines to test on, usable developer tools with debugger & profiler, and so on. (Our favorite tool is not making the transition, but Apple's alternative is certainly suitable.) I also presume that all Mac software developers already have PPC machines for development and testing. It comes down to this: if you want to support Intel Macs with native code then *of course* you will need Intel Macs for development & testing. Likewise, as long as you need to support PPC Macs, you won't discard your last PPC Macs for testing. Starting 6 months from now, *new* developers who wish to support PPC Macs will either have to choose from a more limited range of machines or buy used Macs. Somewhere around 2 years from now, *new* developers will presumably have to buy used Macs in order to properly support PPC Macs. Now how, exactly, is that different than the move from 68k to PPC??? > The 68K to PPC move was done properly... I don't recall debugging 68k code on a PPC machine? I do recall 68k-specific bugs that did not show up in PPC testing. And I sure don't recall Apple providing usable developer tools for the transition! > I don't recall debugging 68k code on a PPC machine? I do recall 68k-specific > bugs that did not show up in PPC testing. And I sure don't recall Apple > providing usable developer tools for the transition! I do remeber debugging 68K code on PowerPC - of course I also remeber doign the "switch" from 65C02 (and others) to the 68000 series too - so maybe I have some time perspective. The Phrases "Usable Tools" is very debatable. A brick can subtsitute for a hammer - but it certainly isn't what I would use to construct the wood frame for a house. And with MW out of the picture, now we have no choice in what development tools we use - other than switching platforms. Milton Aupperle www.outcastsoft.com > And with MW out of the picture, now we have no choice in what > development tools we use - other than switching platforms. But you still have IBM's XLC compiler for PowerPC, and you will shortly have Intel's for their chips. I have little doubt that both are excellent. Alwyn > > And with MW out of the picture, now we have no choice in what > > development tools we use - other than switching platforms. > > But you still have IBM's XLC compiler for PowerPC, For Carbon, there's also Motorola's superb MrC (in MPW). > and you will shortly > have Intel's for their chips. I have little doubt that both are > excellent. And gcc continues to improve. > Alwyn > > I don't recall debugging 68k code on a PPC machine? I do recall 68k-specific > > bugs that did not show up in PPC testing. And I sure don't recall Apple [quoted text clipped - 10 lines] > And with MW out of the picture, now we have no choice in what > development tools we use - other than switching platforms. I used to write a lot of shareware in 680x0 assembly on a beige G3. Worked great w/ Jasik's Debugger (anyone else miss that?) Last time Apple (and their pals at Symantec) very nearly destroyed the company by providing *no* way for people who couldn't afford RS6000 workstations to create PPC applications for the first year. MW gets most of the credit for Apple's survival, if you balance their much-vaunted 68K emulator against the sheer idiocy of whoever let the tools fiasco happen. This time around they've at least learned from that mistake. For all my grumbling about XCode, it certainly qualifies as usable - not quickly or pleasurably, but usable. It's just a shame that my entire former toolchain (CW, Constructor, Resorcerer, Jasik's, a neat little British assembler) has all been rendered obsolete through no fault of its own, and in favor of significantly inferior alternatives produced by Apple and only Apple. > ... > And with MW out of the picture, now we have no choice in what > development tools we use That's MW's fault, not Apple's. Apparently they couldn't stand the heat. But CW was definitely showing its age. They would have needed to be a front-end to gcc eventually. > - other than switching platforms. > > Milton Aupperle > www.outcastsoft.com > That's MW's fault, not Apple's. Apparently they couldn't stand the > heat. But CW was definitely showing its age. They would have needed to > be a front-end to gcc eventually. Huh? The compiler is and has always been (and will be for years) way ahead of the pile of junk called "gcc". Very good when it comes ISO C++ conforming (even compared to the new gcc C++ parser), significantly faster compiling (if configured correctly), much superior optimisation and really good standard C++ libraries. Not to mention that Apple i.e. has to patch on basic features like a working inline assembler (what gcc needs natively inline is augmented, unreadable "assembly" code, and they refused Apple's offer to provide a serious inline assembler, see gcc mailing lists about a year or so ago). Intel's compiler on the other hand is really good of course (EDG frontend after all). I will have to see what their Mac version will cost in two or three years (unless we unswitched by then)... Thorsten > > That's MW's fault, not Apple's. Apparently they couldn't stand the > > heat. But CW was definitely showing its age. They would have needed to [quoted text clipped - 9 lines] > they refused Apple's offer to provide a serious inline assembler, see > gcc mailing lists about a year or so ago). I wasn't commenting on the 'quality' of CW's compiler. My comment was motivated by the endless series of flaming hoops CW was required to leap through, to stay approximately compatible with OS X's evolving runtime. I would guess that was a factor in MW's loss of interest in the platform. > Intel's compiler on the other hand is really good of course (EDG > frontend after all). I will have to see what their Mac version will > cost in two or three years (unless we unswitched by then)... > > Thorsten froe...@googlemail.com wrote: > > > And that speaks volumes about how much support PPC Mac owners will get > > > in 18 months time. No PPC Macs from Apple - no PPC support at all. [quoted text clipped - 6 lines] > to the next and not even provide suitable development tools or support. > The 68K to PPC move was done properly, this one is just a rush because No. This one is not a rush. The two things you're overlooking are: * OS X and everything above it is portable (Carbon in particular was designed for this very purpose - to be architecture independent). When developers ported to Carbon - which practically everybody is by now - they were effectively 97% ported to "Carbon on any future architecture". That's a much more comfortable situation than the 68K/PPC transition (which I agree, was managed very well). * This is not a rush - because Darwin and OS X have been running on Intel for years. But nobody pays any attention until Steve does a keynote about it. > Steve Jobs never liked IBM in the first place. Apart from that, anybody > who has not noticed that Apple has been treating developers like sh.t > in the past five years (and far worse than ever before!) has clearly > not been paying attention. Compared to whom? We now have one of the best and most flexible development environments available anywhere. If you don't like Xcode (and I'm not crazy about it), use Eclipse... > Thorsten > No. This one is not a rush. The two things you're overlooking are: > * OS X and everything above it is portable (Carbon in particular was > designed for this very purpose - to be architecture independent). Actually, in some of the last E.T.O. CDs (IIRC, might have been some seed cds, that was a long time ago) there were preview universal interfaces for Copland that had i.e. many of the low memory globals already marked in much the same way as later appeared in Carbon universal interfaces. >> who has not noticed that Apple has been treating developers like sh.t >> in the past five years (and far worse than ever before!) has clearly >> not been paying attention. > > Compared to whom? Currently? Well, even Microsoft: The just-released VS 8 still runs on Win 2K for example. Try to get *natively-running* development tools for Macs that still work on any operating system shipping back when Win 2k shipped. Remember, that was Mac OS 9! And never mind that even VS 8 still supports development for Windows 95. With supported Apple tools, I can go back as far as, wow, 2001, but only if I use an ancient and buggy gcc compiler (or stick to plain ANSI C). And sure enough M$ would have the power to force developers to move. Sadly, with Apple behavior, it eventually becomes more economical to jump ship (not for me, in my day-job I did that four years ago - Mac programming is just my hobby these days). >* This is not a rush - because Darwin and OS X have been running on > Intel for years. But nobody pays any attention until Steve does a > keynote about it. Well, the Rhapsody developer previews included an x86 version on a separate CD... > We now have one of the best and most flexible > development environments available anywhere. If you don't like Xcode > (and I'm not crazy about it), use Eclipse... Sure, a slow Java hog. No thanks! ;-) And no, I don't like XCode. tried twice, burned badly twice, never again. Rather going back to makefiles like in the good old MPW days :-) Thorsten > > No. This one is not a rush. The two things you're overlooking are: > > * OS X and everything above it is portable (Carbon in particular was [quoted text clipped - 23 lines] > day-job I did that four years ago - Mac programming is just my hobby > these days). The frequently underrated and overlooked MPW (yes, on Classic, big deal) can build code for System 6 through OS X Carbon, if I cared to. Its compilers are also better than both gcc and CW. Yes, I too am disappointed that Apple does not 'support' it. I would like to see its source released, and/or ported to Carbon. > >* This is not a rush - because Darwin and OS X have been running on > > Intel for years. But nobody pays any attention until Steve does a [quoted text clipped - 8 lines] > > Sure, a slow Java hog. No thanks! ;-) Works fine for me. > And no, I don't like XCode. tried twice, burned badly twice, never > again. Rather going back to makefiles like in the good old MPW days :-) > > Thorsten > > > And that speaks volumes about how much support PPC Mac owners will get > > > in 18 months time. No PPC Macs from Apple - no PPC support at all. [quoted text clipped - 5 lines] > is OK to just dump a major platform change on developers from one day > to the next An 18-month transition period starting roughly a year post-announcement counts as dumping a major platform change from one day to the next? > and not even provide suitable development tools or support. > The 68K to PPC move was done properly, this one is just a rush because > Steve Jobs never liked IBM in the first place. Apart from that, anybody > who has not noticed that Apple has been treating developers like sh.t > in the past five years (and far worse than ever before!) has clearly > not been paying attention. So I'm guessing you missed the Sculley years. The CEO it took Apple a decade to recover from largely because of how much he pissed off the developer base. G SignatureGoal 2005: Convincing James Hetfield to cover the Strawberry Shortcake "Are You Berry Berry Happy?" song. > An 18-month transition period starting roughly a year post-announcement > counts as dumping a major platform change from one day to the next? Where is the mixed mode? Of course, switching endianness makes it hard, but the differences between 68K and PowerPC were not that much worse. And the real issue it *how* it was announced: Just a day before porting to Alitvec was actively promoted by Apple. Now all that code can be thrown away (you cannot just copy and replace it with SSE2 tweaks, SSE2 is extremely difficult to optimise, even for Intel's compiler, certain things need to be carefully arranged by hand). > So I'm guessing you missed the Sculley years. The CEO it took Apple a > decade to recover from largely because of how much he pissed off the > developer base. While he surely mismanaged many things, back then you could get a competent answer from DTS within less than a week. And there were early seeds of Copland. Now seeds are so well hidden in the fear of leaks, one could get the impression the Apple management is paranoid. One the development "history" of Mac OS X? How many turns did it take now? I stopped counting! Thorsten Seeds are not hidden if you have a seed key. You may have had early Copland seeds, but without *late* seeds, who cares? Copland never even got close to being a shipping product. I like the current way better than early seeds for something that was little more than vaporware. I don't think they're any more paranoid than any other business that deals in intellectual property. In fact, your first access to most software is when it's released unless you're a beta tester. As for getting a competent answer from DTS, I suspect it was easier back then. Mac OS X is only marginally documented and has historically been very buggy. Add to that what seems to be a lot of people at Apple now who don't even have a Mac background and it's no surprise that DTS has its hands full. ;-) Larry > > An 18-month transition period starting roughly a year post-announcement > > counts as dumping a major platform change from one day to the next? > > Where is the mixed mode? Of course, switching endianness makes it hard, > but the differences between 68K and PowerPC were not that much worse. If you have a suggestion for how mixed mode could be implemented between PowerPC and Intel without requiring that every function call be tagged in some interface definition language with a full description of its arguments, I'd love to hear it. And even that wouldn't be enough, by the way. That's only the first problem you'd hit. In other words, switching endianness makes this impossible, not hard. -Eric SignatureEric Albert ejalbert@cs.stanford.edu http://outofcheese.org/ > If you have a suggestion for how mixed mode could be implemented between > PowerPC and Intel without requiring that every function call be tagged > in some interface definition language with a full description of its > arguments, I'd love to hear it. Well, the PowerPC to Intel way would certainly be possible for various calls that pass direct arguments. Remember that the initial arguments are passed by register on PowerPC, so you know type (and and 32 bit int in converted to either endianness will work even if it just conatined a one byte variable, floats and doubles are no different). Of course, structures and other compound constructs that are passed by just a pointer are a lot more tricky, and indeed there are many impossible cases. But this is precisely what I was getting at by saying it is a rushed transition. With IBM Apple still had some little control over the hardware (maybe Apple should also have worked harder to keep the AIM alliance alive, but that is another issue and in the past, so too late now). With Intel, Apple has no control whatsoever. intel releases a new processor, Dell sure will have it on the production line at the time it is announced to the public. And Apple? Remind me, how has this historically worked in the past seven years? Surprised at Mac World and WWDC, or currently media events. So what do we get, no control for Apple over the hardware, no easy transition for developers any more? Sure, who decided this again? Ah, yes, the same guy who bans a whole publisher for having a biography in its lineup that doesn't please said guy. And I am supposed to believe that same guy makes solid, fact based, rational decisions? - I won't. But of course, everybody has a different view, and I don't think we will ever agree :-) Thorsten >So what do we get, no control for Apple over the hardware, Not quite. The hardware is a lot more than a processor. Okay, so Apple may not have as much influence in CPU development, but apparently after considering all the options they felt that one advantage was not worth what is was costing them. And frankly, given the stagnated speeds of the G4 processors (the latest PowerBook release didn't offer any speed bump at all) I think I can see their reasoning. >no easy >transition for developers any more? Sure, who decided this again? Ah, >yes, the same guy who bans a whole publisher for having a biography in >its lineup that doesn't please said guy. And I am supposed to believe >that same guy makes solid, fact based, rational decisions? - I won't. You certainly have the option of deciding what you want to believe, but whether you like his decisions or not (and I don't always like them myself), I haven't seen him do anything that's turned out to be bad for the company. I think his reasoning is that while cold-turkey transitions can be harder for developers, they will be better for the platform in the long run because they avoid the baggage involved in trying to provide a lot of backward compatibility. It may not be the path you believe you would take if you were in his shoes, but it's certainly a rational path. And for what it's worth, I think this transition won't be so terribly bad for most of us because our products will run fine under Rosetta. Mine does, so I can provide native Intel support when it's convenient for me. I know that's not an option for everyone, but it will be for a lot of us. >But of course, everybody has a different view, and I don't think we >will ever agree :-) Well, you definitely sound like you've made up your mind. ;-) Larry > And for what it's worth, I think this transition won't be so terribly > bad for most of us because our products will run fine under Rosetta. > Mine does, so I can provide native Intel support when it's convenient > for me. I know that's not an option for everyone, but it will be for a > lot of us. Except if you need 3rd party drivers or components. Any device using a KEXT's needs to be re-written, as does most FireWire and USB drivers. The same applies for All QuickTime components and all Plugins (i.e. PhotoShop, TWAIN etc.) - they have to be the same endianess and Rosetta does not address this at all. This is markedly different from the 68K to PPC transition as you could acces 68K plugins from PPC - you can't in MacTel. This means that if end users are using the MacTel version of PhotoShop, then they have to use the MacTel PhotoShop plugins or PPC PhotoShop with PPC Plugins vice versa, but you can't "mix and match". The problem goign forward with PPC support when Apple doens't offer any PPC boxes is self evident. Milton Aupperle www.outcastsoft.com > > And for what it's worth, I think this transition won't be so terribly > > bad for most of us because our products will run fine under Rosetta. [quoted text clipped - 13 lines] > use the MacTel PhotoShop plugins or PPC PhotoShop with PPC Plugins > vice versa, but you can't "mix and match". The original comment admitted that there was no hurry to port to Intel, which is why I'm wondering about Photoshop getting ported. On the one hand, they have a working system on both platforms that will hopefully be faster on whatever Intel can supply a year from now. On the other, they have to port EVERYTHING to Intel to support a platform that will be tiny for the first year or two at best (can they sell enough copies to cover even the QA costs?) and users still may not have their favorite 3rd party plugins. Considering how long it took Adobe to move to PPC and then to OSX (neither of which were all or nothing changes), I suspect we'll wait a while for a true PS-Intel. This doesn't bode well for drivers, either, considering how well most hardware makers support Mac's anyway. >Except if you need 3rd party drivers or components. Any device using a >KEXT's needs to be re-written, as does most FireWire and USB drivers. >The same applies for All QuickTime components and all Plugins (i.e. >PhotoShop, TWAIN etc.) - they have to be the same endianess and Rosetta >does not address this at all. Understood, but are most people writing Mac software in this boat? Larry > >Except if you need 3rd party drivers or components. Any device using a > >KEXT's needs to be re-written, as does most FireWire and USB drivers. [quoted text clipped - 5 lines] > > Larry What I'm saying is that you can't rely on Rosetta for very long. Once Apple stops selling PPC Macs (and what I've heard is they have basically no engineers left doing PPC HW development), drivers/plugins/components for new products will largely x86 endian (well they can asume they work under PPC, but can't test or debug them) and your Rosetta apps will not be able to use them. So at best you've got maybe two or three years life left to completely re-write your apps if you rely on drivers, QuickTime components or Plugins with your App. And of course Apples docs on FireWire, USB or PCI for MacTel are currently non existent and it's all trial and error work. For our IIDC FireWire camera code, that means re-writing about 600,000 lines of our 8 and 16 bit imaging code for x86 endian and also re-thinking it. Most of it is optimized for G4 processors (i.e. using 23 of the available 32 integer registers and avoiding cache access) or relies on Altivec especially Permute which SSE has nothign equivalent to. And the accelerate framework is basically useles for us for YUV444, YUV422, YUVC411 and Mono 16 and RGB48 processing goes. People underestimate just how slow it is to convert U16 to floats each time you need to process it and that fact that the Accelerate framework will de-interlace RGB streams into indivduals and then re-combine them afterwards. That has a major perfromance hit. Milton aupperle www.outcastsoft.com > And the accelerate framework is basically useles for us for YUV444, > YUV422, YUVC411 and Mono 16 and RGB48 processing goes. People > underestimate just how slow it is to convert U16 to floats each time > you need to process it and that fact that the Accelerate framework will > de-interlace RGB streams into indivduals and then re-combine them > afterwards. That has a major perfromance hit. I think you should have a look what a graphics card can do for you. In article <christian.bau-20F940.22263610112005@slb-newsm1.svr.pol.co.uk>, > > And the accelerate framework is basically useles for us for YUV444, > > YUV422, YUVC411 and Mono 16 and RGB48 processing goes. People [quoted text clipped - 4 lines] > > I think you should have a look what a graphics card can do for you. Nope- OpenGL don't handle 16 bit per pixel RGB48 or Mono16. And for the YUV formats, you also have to be in the correct byte order, using correct sign extensions and follow ITU-R BT.601-4 format (ie clipping Luma and Cb/Cr in the right range of unsgined values). It simply doesn't cut it. If your talking about using the GPU as another processor, that's just as bad as writing x86 Assembler or targetting SSE. You also have to be ware of whose GPU you are targetting too, ATI's NVIDIA or maybe Intels built in on board stuff - so writing and maintaining 3+ sets of code is ludicrous. We already devloped it for Altivec, but we are not going to get burned twice by Apple by going "Low Level" again. Apple can come out with it's 8 gighz dual core Pentium M processor for your laptop in 5 years to replace what we currently get with Altivec today. And people that doubt what Altive offers for perfromance should check out http://www.pixelglow.com/stories/macintel-faster-than-altivec/ especially the CW 9.5 benchmarks against GCC 4.0 and the Intel Pentium comparsions. Milton aupperle www.outcastsoft.com >> Understood, but are most people writing Mac software in this boat? >> Larry >What I'm saying is that you can't rely on Rosetta for very long. Once >Apple stops selling PPC Macs (and what I've heard is they have [quoted text clipped - 7 lines] >PCI for MacTel are currently non existent and it's all trial and error >work. I realize you're in the worst possible position on this, but most of us aren't. I don't rely on drivers or plug-ins. Even if I did, two or three years is way more than enough time for me to make this transition, and I suspect that's the case for a lot of developers. That gives me plenty of time to look over the Intel Macs, pick one that makes sense as an upgrade from my current Mac (as opposed to spending $1000 to rent a transition kit), buy it, and then do the conversion. I'm currently identifying places where I need to address endian issues as I work on the next release of my application. Next I'll need to switch to Xcode, and then once I have an Intel Mac I can turn on the Intel switch and duck. ;-) Larry > > An 18-month transition period starting roughly a year post-announcement > > counts as dumping a major platform change from one day to the next? [quoted text clipped - 4 lines] > to Alitvec was actively promoted by Apple. Now all that code can be > thrown away .... [cough]Accelerate.framework[cough] > > So I'm guessing you missed the Sculley years. The CEO it took Apple a > > decade to recover from largely because of how much he pissed off the > > developer base. > > While he surely mismanaged many things, back then you could get a > competent answer from DTS within less than a week. I still do, and it costs me less now because Apple is no longer treating developers like a direct revenue source. I wasn't kidding about the decade. It took that long for the number of active Mac OS developers to get back to where it had been before the developer program was overhauled. > One the > development "history" of Mac OS X? How many turns did it take now? I > stopped counting! I might respond to that if I knew what you were actually saying, but typos and/or dropped words render interpretation difficult for me. SignatureGoal 2005: Convincing James Hetfield to cover the Strawberry Shortcake "Are You Berry Berry Happy?" song. >[cough]Accelerate.framework[cough] Remind me, how does this help anybody whose algorithm isn't covered by it? Ah, yes, not at all! > I still do, and it costs me less now because Apple is no longer treating > developers like a direct revenue source. Last time I paid, prices hadn't changed - in many, many years. >> One the >> development "history" of Mac OS X? How many turns did it take now? I >> stopped counting! > >I might respond to that if I knew what you were actually saying, but >typos and/or dropped words render interpretation difficult for me. Replace "One" with "And". And yes, editing in tiny boxes in Google Groups is difficult :-) Thorsten > >[cough]Accelerate.framework[cough] > > Remind me, how does this help anybody whose algorithm isn't covered by > it? Ah, yes, not at all! This response says to me that you aren't actually familiar with what Accelerate.framework provides. You should read up on it. Yes, Apple evangelized SIMD. They still do. But they weren't necessarily arguing in favor of writing directly against specific vector units "the day before" the x86 announcement as you claimed. > >> One the > >> development "history" of Mac OS X? How many turns did it take now? I [quoted text clipped - 4 lines] > > Replace "One" with "And". Still not getting it. What are you asking about the development history of OS X? What counts as a "turn" as you're using the word? G SignatureGoal 2005: Convincing James Hetfield to cover the Strawberry Shortcake "Are You Berry Berry Happy?" song. >> Remind me, how does this help anybody whose algorithm isn't covered by >> it? Ah, yes, not at all! > > This response says to me that you aren't actually familiar with what > Accelerate.framework provides. Believe me, I am familar with what it offers. It doesn't have the algorithms I need, period. > But they weren't necessarily arguing in > favor of writing directly against specific vector units "the day before" > the x86 announcement as you claimed. Then you clearly missed (even) the public Tiger developer documentation released in May. All pushing G5 features, 64-bit, new gcc Altivec integration* and so on; always specifically mentioning the G5 Macs. All links point to the Altivec differences in the PPC 970 comapred to the PPC 74X0. Or, how about the last update to <http://developer.apple.com/performance/g5optimization.html>, on April 29th? Basically, to the public there was no indication whatsoever that a major platform change would take place any time soon. > Still not getting it. What are you asking about the development history > of OS X? It was a *rethorical* question! Thorsten * Did you follow how much work Apple put into getting the Altivec programming model supported in gcc? If not, you missed something. the same goes for Apple trying to support a CW-style inline assembler for PowerPC. > >> Remind me, how does this help anybody whose algorithm isn't covered by > >> it? Ah, yes, not at all! [quoted text clipped - 4 lines] > Believe me, I am familar with what it offers. It doesn't have the > algorithms I need, period. Have you filed bug reports with Apple about this? Presumably the team in charge of the Accelerate framework would be interested in hearing about areas where their APIs aren't meeting developers' needs. > * Did you follow how much work Apple put into getting the Altivec > programming model supported in gcc? If not, you missed something. the > same goes for Apple trying to support a CW-style inline assembler for > PowerPC. Presumably Apple will put a lot of effort into improving SSE/SSE2 in gcc. And perhaps there'll be some work on the inline assembler for Intel, too. -Eric SignatureEric Albert ejalbert@cs.stanford.edu http://outofcheese.org/ > Have you filed bug reports with Apple about this? Presumably the team > in charge of the Accelerate framework would be interested in hearing > about areas where their APIs aren't meeting developers' needs. Nope. I am not talking algorithms solving generic/common problems. And some are not even for Apple to see. > Presumably Apple will put a lot of effort into improving SSE/SSE2 in > gcc. And perhaps there'll be some work on the inline assembler for > Intel, too. Writing x86 assembler? No thanks! ;-) And whatever effort Apple puts into improving gcc, I don't care - I get direct support from Intel for their compiler :-) Thorsten > Have you filed bug reports with Apple about this? Presumably the team > in charge of the Accelerate framework would be interested in hearing > about areas where their APIs aren't meeting developers' needs. Nope. I am not talking algorithms solving generic/common problems. And some are not even for Apple to see. > Presumably Apple will put a lot of effort into improving SSE/SSE2 in > gcc. And perhaps there'll be some work on the inline assembler for > Intel, too. Writing x86 assembler? No thanks! ;-) And whatever effort Apple puts into improving gcc, I don't care - I get direct support from Intel for their compiler :-) Thorsten > >> Remind me, how does this help anybody whose algorithm isn't covered by > >> it? Ah, yes, not at all! [quoted text clipped - 11 lines] > Then you clearly missed (even) the public Tiger developer documentation > released in May. Nope. Saw it. But you're missing the point. > All pushing G5 features, 64-bit, new gcc Altivec integration* and so on; All of which makes sense given that PowerPC Macs are going to be a market reality for Mac OS developers for years. If you're pushing SIMD, you'd like the developers to be able to use it as easily as possible regardless of which vector unit is actually there. So again: I don't see them advocating that developers WRITE DIRECTLY AGAINST specific vector units. > always specifically mentioning the G5 Macs. All > links point to the Altivec differences in the PPC 970 comapred to the > PPC 74X0. Or, how about the last update to > <http://developer.apple.com/performance/g5optimization.html>, on April > 29th? Basically, to the public there was no indication whatsoever that > a major platform change would take place any time soon. That's because it won't. The first availability of x86-based Macs will be over a year after that update. That's not "soon" in this industry. The product line isn't intended to be completely transitioned for another 18 months after that - there will be people buying new PowerPC-based Macs through 2007. Given the life cycle of Macs, PowerPCs are likely going to comprise the majority of installed machines until around 2010 and still be significant for another year or two. So why would developers (including Apple) _not_ want the knowledge and tools to leverage them as much as possible over that time? > > Still not getting it. What are you asking about the development history > > of OS X? > > It was a *rethorical* question! Ah. Um. How was I to know that? G SignatureGoal 2005: Convincing James Hetfield to cover the Strawberry Shortcake "Are You Berry Berry Happy?" song. > That's because it won't. The first availability of x86-based Macs will > be over a year after that update. That's not "soon" in this industry. Maybe you write code to throw it away in three years, I don't. Thorsten > That's because it won't. The first availability of x86-based Macs will > be over a year after that update. That's not "soon" in this industry. Maybe you write code to throw it away in three years, I don't. Thorsten > > That's because it won't. The first availability of x86-based Macs will > > be over a year after that update. That's not "soon" in this industry. > > Maybe you write code to throw it away in three years, I don't. I frankly haven't got a clue how that comment is at all relevant to any part of the post to which it was allegedly in response, let alone the specific excerpt quoted. I do note, though, that you've studiously avoided responding to any salient points. Well played, sir. Let's try again, simpler this time: I see no indication despite your claim to the contrary that Apple was advocating the practice of writing code directly against a specific vector unit. I see that Apple _has_ made a specific effort, well-predating the announcement of the migration to x86, to abstract away the details of the vector unit for common applications. VMX/AltiVec/Velocity Engine is likely to remain relevant to the subset of developers for whom it is currently relevant for several more years. Given that, it makes sense that Apple would have put effort into improving support for it in their tools for both their own direct benefit and the indirect benefit from having developers also use it. G SignatureGoal 2005: Convincing James Hetfield to cover the Strawberry Shortcake "Are You Berry Berry Happy?" song. > > > That's because it won't. The first availability of x86-based Macs will > > > be over a year after that update. That's not "soon" in this industry. [quoted text clipped - 4 lines] > part of the post to which it was allegedly in response, let alone the > specific excerpt quoted. Well, he has, to my mind, a legitimate squawk, or at least it would be legitimate if Apple changed their processors regularly every three years. Apple have promoted Altivec on PowerPC, and now they seem to be abandoning PowerPC in favour of x86-style Intel processors. Said processors do not have Altivec, so any low-level code written for Altivec needs to be rewritten. The Accelerate framework covers many but by no means all the uses to which Altivec may be put. Frölich and Aupperle seem to have found it necessary to write low-level Altivec code for the algorithms in their software, and now they face the prospect of having to rewrite them altogether for the new processors Apple has announced it will be using. I can well understand their frustration, can't you? Alwyn In article <dt015a1979-2178C9.21014911112005@text.news.blueyonder.co.uk>, > > > > That's because it won't. The first availability of x86-based Macs will > > > > be over a year after that update. That's not "soon" in this industry. [quoted text clipped - 10 lines] > Apple have promoted Altivec on PowerPC, and now they seem to be > abandoning PowerPC in favour of x86-style Intel processors. Apple has encouraged adoption of SIMD in general. Certainly they have talked about AltiVec specifically, because that's the SIMD unit that's been available to Mac OS for the last 5 years, but they have not in recent memory actively advocating writing straight to the SIMD unit when not required and have made efforts to reduce the number of scenarios in which such practices _are_ required. > Said > processors do not have Altivec, so any low-level code written for [quoted text clipped - 6 lines] > Apple has announced it will be using. I can well understand their > frustration, can't you? I can understand individual developers being personally frustrated. I can't understand or agree with the way that personal frustration has grown into completely hyperbolic arguments about the impact, timeframe and nature of this change and incorrect claims about the OS vendor's behavior prior to the announcement. G SignatureGoal 2005: Convincing James Hetfield to cover the Strawberry Shortcake "Are You Berry Berry Happy?" song. > Apple has encouraged adoption of SIMD in general. Certainly they have > talked about AltiVec specifically, because that's the SIMD unit that's > been available to Mac OS for the last 5 years, but they have not in > recent memory actively advocating writing straight to the SIMD unit when > not required and have made efforts to reduce the number of scenarios in > which such practices _are_ required. OK, I've sat back and read a lot of this passively but your statements are factually false. Apple has most certainly advocated writing code directly for the Atlivec unit. Have you attended any Apple performance tuning workshops recently (pre-WWDC)? I have attended many. I would venture to guess that you didn't even attend WWDC this year. At every Apple performance workshop prior to the Intel announcement they advocated writing directly for the PPC Altivec unit. In fact, I can remember off the top of my head that at this year's WWDC session, Swimming with Shark, Apple advocated writing Altivec and even SSE code directly, not using the Accelerate Framework. They even demoed how to do it and showed what they had done. None of it using the Accelerate Framework. Apple's first position was always to advocate writing for the Accelerate Framework (vDSP, vImage, etc.). They advocate this first because there's no reason to reinvent the wheel if you don't have to. However, they were quick to acknowledge that the Accelerate Framework does not provide everything that you might need and that you very often need to write your own SIMD code directly. Up until WWDC this year that was always Altivec code and Apple encouraged you to write it. > I can understand individual developers being personally frustrated. I > can't understand or agree with the way that personal frustration has > grown into completely hyperbolic arguments about the impact, timeframe > and nature of this change and incorrect claims about the OS vendor's > behavior prior to the announcement. Your claims and position is factually false. Please stop trying to rewrite history. > > Apple has encouraged adoption of SIMD in general. Certainly they have > > talked about AltiVec specifically, because that's the SIMD unit that's [quoted text clipped - 5 lines] > OK, I've sat back and read a lot of this passively but your statements > are factually false. Which of those statements are false, please? There are 4 functional assertions above, and every one of them is verifiably true. Oh, wait. You continue... > Apple's first position was always to advocate writing for the > Accelerate Framework (vDSP, vImage, etc.). They advocate this first > because there's no reason to reinvent the wheel if you don't have to. [And because it simplifies moving to another SIMD unit that might not be a proper superset of those available so far.] > However, they were quick to acknowledge that the Accelerate Framework > does not provide everything that you might need and that you very often > need to write your own SIMD code directly. Up until WWDC this year > that was always Altivec code and Apple encouraged you to write it. So, basically, what you're saying is that Apple has advocated using the abstraction layer provided by Accelerate.framework when it's sufficient and falling back to writing directly against specific SIMD units when necessary. That looks to me an awful lot like what I said but which you declared false. > > I can understand individual developers being personally frustrated. I > > can't understand or agree with the way that personal frustration has [quoted text clipped - 4 lines] > Your claims and position is factually false. Please stop trying to > rewrite history. Please _start_ trying to read what you've written before hitting the Post button. SignatureGoal 2005: Convincing James Hetfield to cover the Strawberry Shortcake "Are You Berry Berry Happy?" song. > > And that speaks volumes about how much support PPC Mac owners will get > > in 18 months time. No PPC Macs from Apple - no PPC support at all. > > No, I think it speaks volumes about Apple's (and FWIW my) opinion about the > foolishness of trying to develop for PPC without testing on an actual PPC. Well, if you have an application written with CodeWarrior, that you never ported to XCode and MacIntel, then three years from now you can _still_ use CodeWarrior to make a change, compile it and test it on a MacIntel box, as long as you know exactly what change you want to make. You just have to keep a Mac PowerPC for debugging. > > > It's worth noting that debugging Rosetta applications isn't supported > > > from within Xcode. Given that, I wouldn't expect it to work with [quoted text clipped - 5 lines] > And that speaks volumes about how much support PPC Mac owners will get > in 18 months time. No PPC Macs from Apple - no PPC support at all. Developers new to the Mac once the transition starts are likely to focus almost exclusively on x86. Established developers with any kind of installed base would already _have_ their test machines and are, one hopes, generally smart enough not to simply abandon the users they have at the instant the architecture change becomes real. G SignatureGoal 2005: Convincing James Hetfield to cover the Strawberry Shortcake "Are You Berry Berry Happy?" song. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.