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.

In article <1131494440.193395.131...@g49g2000cwa.googlegroups.com>,

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

--
Eric Albert         ejalb...@cs.stanford.edu
http://outofcheese.org/

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

In article <1131494440.193395.131...@g49g2000cwa.googlegroups.com>,

[cough]Accelerate.framework[cough]

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.

I might respond to that if I knew what you were actually saying, but
typos and/or dropped words render interpretation difficult for me.

--
Goal 2005: Convincing James Hetfield to cover the Strawberry Shortcake
"Are You Berry Berry Happy?" song.

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.

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.

Well, you definitely sound like you've made up your mind. ;-)

Larry

In article <1131518434.747011.279...@f14g2000cwb.googlegroups.com>,

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

news:091120051155195885%spam@mustdie.com...

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.

Remind me, how does this help anybody whose algorithm isn't covered by
it? Ah, yes, not at all!

Last time I paid, prices hadn't changed - in many, many years.

Replace "One" with "And". And yes, editing in tiny boxes in Google
Groups is difficult :-)

    Thorsten

In article <1131574603.615052.205...@g49g2000cwa.googlegroups.com>,

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.

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

--
Goal 2005: Convincing James Hetfield to cover the Strawberry Shortcake
"Are You Berry Berry Happy?" song.

Believe me, I am familar with what it offers. It doesn't have the
algorithms I need, period.

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.

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.

In article <1131594788.250274.82...@g43g2000cwa.googlegroups.com>,

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.

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

--
Eric Albert         ejalb...@cs.stanford.edu
http://outofcheese.org/

Understood, but are most people writing Mac software in this boat?

Larry

In article <1131594788.250274.82...@g43g2000cwa.googlegroups.com>,

Nope. Saw it. But you're missing the point.

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.

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?

Ah. Um. How was I to know that?

G

--
Goal 2005: Convincing James Hetfield to cover the Strawberry Shortcake
"Are You Berry Berry Happy?" song.

In article <1131599393.108836.283...@f14g2000cwb.googlegroups.com>,

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

In article <101120051051424693%s...@mustdie.com>,
 Milton Aupperle <s...@mustdie.com> wrote:

I think you should have a look what a graphics card can do for you.

Nope. I am not talking algorithms solving generic/common problems. And
some are not even for Apple to see.

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

Maybe you write code to throw it away in three years, I don't.

    Thorsten

In article
<christian.bau-20F940.22263610112...@slb-newsm1.svr.pol.co.uk>,

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

In article <1131665323.353249.256...@g14g2000cwa.googlegroups.com>,

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

--
Goal 2005: Convincing James Hetfield to cover the Strawberry Shortcake
"Are You Berry Berry Happy?" song.

In article <uce-EF1AEC.20285510112...@comcast.dca.giganews.com>,
 Gregory Weston <u...@splook.com> wrote:

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.21014911112...@text.news.blueyonder.co.uk>,

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.

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

--
Goal 2005: Convincing James Hetfield to cover the Strawberry Shortcake
"Are You Berry Berry Happy?" song.

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

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.

Your claims and position is factually false.  Please stop trying to
rewrite history.

In article <1132076099.277353.93...@o13g2000cwo.googlegroups.com>,

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...

[And because it simplifies moving to another SIMD unit that might not be
a proper superset of those available so far.]

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.

Please _start_ trying to read what you've written before hitting the
Post button.

--
Goal 2005: Convincing James Hetfield to cover the Strawberry Shortcake
"Are You Berry Berry Happy?" song.