Rosetta now with altivec support!

bazzler

'Tis rumoured that full altivec support is now included with latest X86 build of

Tiger. Remembering that fateful Jobs keynote, he said rosetta would 'just work' and he mentioned no caveat of altivec support being not included; maybe its taken till now to get it working, but it was always the plan?



http://www.osnews.com/story.php?news_id=12746



http://www.osx86project.org/index.ph...id=68&Itemid=2

anders

Rosetta with altivec support? The Rosetta tech sound crazy in the first place. WIth Altivec its crazy^crazy.



If its true (which I doubt very much) it may support Altivec but not at all at the speed of altivec as we know it

kim kap sol

Quote:

Originally posted by Anders

Rosetta with altivec support? The Rosetta tech sound crazy in the first place. WIth Altivec its crazy^crazy.



If its true (which I doubt very much) it may support Altivec but not at all at the speed of altivec as we know it

Definitely not at the speed that we're used to...but nice to know that 99.9999% of apps will now work.

anders

I think to have any Altivec code work on Intels is so infinitely complex and the speed penalty is so huge that 999999999 times out of a billion it is much simpler and more effective just to take it away and do without it.

chucker

Quote:

Originally posted by Anders

I think Altivec support will be so slow that in 99.999% of the cases you are better not using it.

You are saying that AltiVec emulation will cause slowdowns? At worst, it just won't offer a noticeable gain. At best, it will. But slowdowns?

anders

Quote:

Originally posted by Chucker

You are saying that AltiVec emulation will cause slowdowns? At worst, it just won't offer a noticeable gain. At best, it will. But slowdowns?

I surely isn´t an expert. But altivec code was written to a very dedicated type of hardware. To make the program run altivec code and then have a software layer translate that code into a type of code that can rum on non dedicated hardware just seems to be the long way round. Unless of course they have found a way of making that code run on Intels equivalent to Altivec (can´t remember its name), which would impress me even more, since to my knowledge the two implementations are very different.



AAs I said I may be way out of my knowledge here so anyone really informed please shread it all to pieces if not true

chucker

Quote:

Originally posted by Anders

Unless of course they have found a way of making that code run on Intels equivalent to Altivec (can´t remember its name), which would impress me even more, since to my knowledge the two implementations are very different.

I think it is safe to assume that that's what they did: find a way to translate AltiVec instructions to SSE3.



Quite an impressive feat, and yes, the two are very different, but I don't see it as being impossible.

kcmac

As a consumer, I would expect this turn of events. Apple has a lot on the line with this switch, they are hot, getting more attention from more people than ever and expectations are just as high or higher than ever.



Good news if true, but really now, seems to be a requirement.

kaiwai

Quote:

Originally posted by bazzler

'Tis rumoured that full altivec support is now included with latest X86 build of

Tiger. Remembering that fateful Jobs keynote, he said rosetta would 'just work' and he mentioned no caveat of altivec support being not included; maybe its taken till now to get it working, but it was always the plan?



http://www.osnews.com/story.php?news_id=12746



http://www.osx86project.org/index.ph...id=68&Itemid=2

Well, maybe its better to under hype then over hype, only to find that one can't deliver - then again, to the average person, they wouldn't have been watching WWDC anyway, hell, most don't even go to the trade shows; these are geek only affairs.



Maybe they were also waiting to hear what was in SSE3 and whether a translation layer from AltiVec could be done, without massive TLC? what ever the result, hopefully it'll mean adequate performance for PPC applications on x86.

lundy

Yes, it all depends on what they mean by "support Altivec".



- Does it mean that the Rosetta interpreter/JIT compiler can translate Altivec machine code to SSE machine code? If so, how does it translate the Permute instructions, since SSE has no Permute?



- Or does it mean that Rosetta now "knows" how to emulate the hardware of the Altivec unit, so that PPC Altivec assembler code will at least run, if orders of magnitude more slowly than before? This emulation would only be necessary if the app in question would not run on a G3 - in other words if it had hard-coded Altivec instructions.

towel

Quote:

Originally posted by lundy

Yes, it all depends on what they mean by "support Altivec".



- Does it mean that the Rosetta interpreter/JIT compiler can translate Altivec machine code to SSE machine code? If so, how does it translate the Permute instructions, since SSE has no Permute?



- Or does it mean that Rosetta now "knows" how to emulate the hardware of the Altivec unit, so that PPC Altivec assembler code will at least run, if orders of magnitude more slowly than before? This emulation would only be necessary if the app in question would not run on a G3 - in other words if it had hard-coded Altivec instructions.

I'm guessing it's the second, because they surely would have been hyping the heck out of the first to developers, if they had figured out how to do it. Seamlessly translating SSE<->AltiVec would let them put generic vector routines in XCode that would abstract away the need to specifically code for either system - and maybe from having to code specifically for vector processing at all. It seems like that would be a pretty big deal.

placebo

Good to hear, but I still think that there really weren't many G4-optimized apps that weren't either Apple-developed or developed by large companies (Adobe for example) which have millions of dollars of budget money for the very purpose.

hiro

Quote:

Originally posted by Towel

I'm guessing it's the second, because they surely would have been hyping the heck out of the first to developers, if they had figured out how to do it. Seamlessly translating SSE<->AltiVec would let them put generic vector routines in XCode that would abstract away the need to specifically code for either system - and maybe from having to code specifically for vector processing at all. It seems like that would be a pretty big deal.

You just cited the purpose for vecLib.framework. The current version is already installed in OS X at System/Libraries/Frameworks. One consistent API call, and the appropriate Altivec/SSE implementations can be linked as needed depending on which platform you are compling against. Not everything in Altivec will have an SSE implementation, but enough will, and those things that don't can still have a non-vector based implementation so you only need to code it once for both platforms when absolute-max-performance is not your goal.

lundy

Quote:

Originally posted by Hiro

You just cited the purpose for vecLib.framework. The current version is already installed in OS X at System/Libraries/Frameworks. One consistent API call, and the appropriate Altivec/SSE implementations can be linked as needed depending on which platform you are compling against. Not everything in Altivec will have an SSE implementation, but enough will, and those things that don't can still have a non-vector based implementation so you only need to code it once for both platforms when absolute-max-performance is not your goal.

You're both right. If one is coding from scratch, use the veclib (accelerate.framework). The binary gets Altivec or SSE, taken care of by the framework.



But the question is, what happens to a hard-coded Altivec binary under Rosetta?

hiro

If you already have a framework abstracting the vector unit, the translator (Rosetta) would just need to select the appropriate native framework call and put that in the execution stack. My point is, the work done for vecLib.framework is the essentially the same work you would need to do for the back end of Rosetta Altivec emulation.

kaiwai

Quote:

Originally posted by lundy

You're both right. If one is coding from scratch, use the veclib (accelerate.framework). The binary gets Altivec or SSE, taken care of by the framework.



But the question is, what happens to a hard-coded Altivec binary under Rosetta?

Well, the assumption could be that they're going to use SSE3 to accelerate the over all emulation - and as for altvec processors, it'll just run slower, not run at all; all it'll mean is that the 'fake processor' simply supports altvec, but it doesn't mean that the underlying processor will actually accelerate those altvec commands in native mode using SSE3.