CodeWarrior 10 on Macintel
Math1723
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?
Gregory Weston
"Math1723" <anony...@aol.com> wrote:
> 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.
--
Goal 2005: Convincing James Hetfield to cover the Strawberry Shortcake
"Are You Berry Berry Happy?" song.
la...@skytag.com
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
Eric Albert
> 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.
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
--
Eric Albert ejal...@cs.stanford.edu
http://outofcheese.org/
Scott Ribe
ejal...@cs.stanford.edu wrote on 11/8/05 12:56 AM:
> 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.
Milton Aupperle
<scott...@killerbytes.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.
Milton Aupperle
www.outcastsoft.com
la...@skytag.com
>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
Scott Ribe
sp...@mustdie.com wrote on 11/8/05 10:23 AM:
> 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.
Eric Albert
Scott Ribe <scott...@killerbytes.com> wrote:
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.
fro...@googlemail.com
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 shit
in the past five years (and far worse than ever before!) has clearly
not been paying attention.
Thorsten
Scott Ribe
fro...@googlemail.com at fro...@googlemail.com wrote on 11/8/05 11:58 AM:
> 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!
Milton Aupperle
<scott...@killerbytes.com> wrote:
> 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
Alwyn
Milton Aupperle <sp...@mustdie.com> wrote:
>
> 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
Paul
"Milton Aupperle" <sp...@mustdie.com> wrote in message
news:081120051304233949%sp...@mustdie.com...
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.
toby
froe...@googlemail.com wrote:
> Scott Ribe wrote:
> > in article 081120051023186084%sp...@mustdie.com, Milton Aupperle at
> > sp...@mustdie.com wrote on 11/8/05 10:23 AM:
> >
> > > 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
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 shit
> 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
toby
Milton Aupperle wrote:
> In article <BF964C36.36A2C%scott...@killerbytes.com>, Scott Ribe
> <scott...@killerbytes.com> wrote:
> 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.
toby
Alwyn wrote:
> In article <081120051304233949%sp...@mustdie.com>,
> Milton Aupperle <sp...@mustdie.com> wrote:
> >
> > 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
Gregory Weston
fro...@googlemail.com wrote:
> Scott Ribe wrote:
> > in article 081120051023186084%sp...@mustdie.com, Milton Aupperle at
> > sp...@mustdie.com wrote on 11/8/05 10:23 AM:
> >
> > > 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
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 shit
> 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
fro...@googlemail.com
> * 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 shit
>> 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
Gregory Weston
Milton Aupperle <sp...@mustdie.com> wrote:
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.
fro...@googlemail.com
> 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
fro...@googlemail.com
> 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
toby
fro...@googlemail.com wrote:
> > 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 shit
> >> 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).
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
> > 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! ;-)
Works fine for me.
la...@skytag.com
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
Christian Bau
Scott Ribe <scott...@killerbytes.com> wrote:
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.
toby
fro...@googlemail.com wrote:
> > 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).
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.
Eric Albert
fro...@googlemail.com wrote:
> > 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.
fro...@googlemail.com
> 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
Gregory Weston
> > 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 ....
[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.
la...@skytag.com
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
Milton Aupperle
<la...@skytag.com> wrote:
> 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
Paul
> In article <1131518434.7...@f14g2000cwb.googlegroups.com>,
> <la...@skytag.com> wrote:
>
>
> > 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 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.
fro...@googlemail.com
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
Gregory Weston
fro...@googlemail.com wrote:
> >[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
> >> 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".
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
fro...@googlemail.com
>> 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.
Eric Albert
fro...@googlemail.com wrote:
> >> 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.
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.
la...@skytag.com
>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
Gregory Weston
> >> 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.
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?
Milton Aupperle
<la...@skytag.com> wrote:
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
Christian Bau
Milton Aupperle <sp...@mustdie.com> wrote:
> 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.
fro...@googlemail.com
> 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
fro...@googlemail.com
> 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
Milton Aupperle
<christian.bau-20F...@slb-newsm1.svr.pol.co.uk>,
Christian Bau <christ...@cbau.freeserve.co.uk> wrote:
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
Gregory Weston
fro...@googlemail.com wrote:
> > 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.
Alwyn
Gregory Weston <u...@splook.com> wrote:
> In article <1131665323.3...@g14g2000cwa.googlegroups.com>,
> fro...@googlemail.com wrote:
>
> > > 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.
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
Gregory Weston
<dt015a1979-2178C...@text.news.blueyonder.co.uk>,
Alwyn <dt015...@mac.com> wrote:
> In article <uce-EF1AEC.2...@comcast.dca.giganews.com>,
> Gregory Weston <u...@splook.com> wrote:
>
> > In article <1131665323.3...@g14g2000cwa.googlegroups.com>,
> > fro...@googlemail.com wrote:
> >
> > > > 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.
>
> 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.
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
> 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?
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.
la...@skytag.com
>> 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.
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
Dave
Gregory Weston wrote:
>
> 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.
Gregory Weston
"Dave" <in...@kuwan.net> wrote:
> Gregory Weston wrote:
> >
> > 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.
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
> > 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.
Please _start_ trying to read what you've written before hitting the
Post button.