Jump to content

altivec for rosetta.


  • Please log in to reply
6 replies to this topic

#1
slowdiver

slowdiver

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 164 posts
As the maxxus-oah-patch seems to be rock-stable i was thinking on a - maybe totally phantastic or silly - project.

if we could 'downgrade' the oah, we could possibly 'upgrade' it too - to altivec (G4/G5). Altivec-Code is freely available and stable, too - see the pearpc project.

is this a totaly silly idea?

i mean: look at all the progs that dont run cause of this non-altivec support.
apple has lots of infos of rewriting altivec to sse. together with pearpc there seems to be a wide basis for such a project.

and as maxxus has done this great rewritting things - maybe this could be our next great leap - the whole osx86 community then could develop in a more linux-sense. look: we are writing device-drivers by now. if the system-mods go with the actual speed we surely have an 'open-source' osx-derivate soon - derivating the existing system....

but back: is it totaly illusory, this altivec-thing? Jens of pearpc is such a great guy - maybe we could put the 'branches' together...?!?

#2
cwestpha

cwestpha

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 151 posts
  • Gender:Male
  • Location:USA
Altivac emulation in Power PC is not perfect. You can see this by trying to run OS X 10.4 with G4, it doesnt work. This could easily distabilize OS X86
We should first work on getting video, more networking, etc going before we try to re-invent rosetta.

#3
blahsucks

blahsucks

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 182 posts
I agree.

There is one reason reinventing rosetta is not a good idea - Optimization. Rosetta is a heavily supported, heavily funded, heavily optimized product. It can run apps at near native speed, which is nothing short of amazing.

Most of the AltiVec apps are going to run very slow under this, and it will be a step back for the apps we can run in Rosetta already. iMovie and such will be totally unusable.

#4
sHARD>>

sHARD>>

    All we are is dust in the wind...

  • Retired
  • 976 posts
  • Gender:Male
At altivec -> SSE translator would be immensely complex. Unlike SSE3 -> SSE2 they are completely different standards. If Rosetta doesn't have it you can imagine just how hard it is. And don't bring up the fact that Rosetta doesn't support SSE2, it was never meant to anyway, it uses SSE3 functions because they are faster than any SSE2 similars.

#5
cwestpha

cwestpha

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 151 posts
  • Gender:Male
  • Location:USA
actualy for the record emulated altivac is faster then emulated G3. Simply because a G4 is basicly a G3 processor with altivac (ok there are more differences then that, but thats the primary difference). If you have Altivac codes being flaged and then send directly into a SSEx translation path this is actualy faster then having code identified in software without hardware support.
From what it looks like Rosetta sends PPC code through an interpreter and then decides what to do. What calls that can be accelerated with SSEx is then done (after some translation of course) such and what cant is just run regularly.
Adding G4 would be kind of like adding flags to code that could idealy be translated to SSE3 calls. With the advent of SSE2 and 3 lets not forget that Intel has mostly caught up with Altivac for semi-equivilent functions.

HOWEVER, adding G4 would make Rosetta fatter and much more complex. While speed and application compatability would be improved it is not easy to corectly translate all calls from Altivac to SSE3 (or less) 100% of the time. This could cause crashes and make Rosetta harder to make.

PearPC does a good job implementing Altivac to SSE2 translations (granted nowhere near optimized) however not everything apears to be implemented and perfectly translating all of time time. You cant just ignore code wanting to be executed and expect a good stable experince.

Perhaps in a future version of Rosetta Altivac emulation will be added, but until then its just not worth the investment. If Apple, the company that knows Altivec like the back of their hands, thinks its to complex to implement right now then it probebly is.

#6
judy

judy

    InsanelyMac Protégé

  • Members
  • PipPip
  • 98 posts

actualy for the record emulated altivac is faster then emulated G3. Simply because a G4 is basicly a G3 processor with altivac (ok there are more differences then that, but thats the primary difference). If you have Altivac codes being flaged and then send directly into a SSEx translation path this is actualy faster then having code identified in software without hardware support.

You're talking about PearPC here, right? And what do you mean by hardware support? All this translation happens in software. The x86 cpus don't have hardware support for translating foreign instruction sets.

From what it looks like Rosetta sends PPC code through an interpreter and then decides what to do. What calls that can be accelerated with SSEx is then done (after some translation of course) such and what cant is just run regularly.
Adding G4 would be kind of like adding flags to code that could idealy be translated to SSE3 calls. With the advent of SSE2 and 3 lets not forget that Intel has mostly caught up with Altivac for semi-equivilent functions.

What Rosetta does is basically look up every ppc instruction it encounters in a big translation table, and execute the corresponding x86 instruction(s) instead. If it encounters something it doesn't know, eg. an Altivec instruction, well, bad luck. It isn't like it checks if some code can be accelerated with SSE3 or not - it's simply taking "this" x86 instruction for "that" ppc instruction. No questions asked. :D If "this" instruction happens to be an SSE3 one, fine. Sure, this whole process is highly optimized and I bet it in fact does consider the context of any particular instruction, but I think it's pretty static nontheless.

Adding Altivec support would involve working out what Altivec instruction maps to what x86 instruction (which doesn't necessarily have to be an SSE instruction), and adding them to the translation table. But you have to keep in mind that no one but Apple has Rosetta's source code. And trying to patch something of this magnitude into an unknown binary is pretty hopeless.

#7
bonehead

bonehead

    InsanelyMac Protégé

  • Members
  • Pip
  • 19 posts

What Rosetta does is basically look up every ppc instruction it encounters in a big translation table, and execute the corresponding x86 instruction(s) instead.


I think it's a bit more complex than this. From Transitive (the contributors of Rosettas core technology):

Dynamic Binary Translation - The dynamic binary translator in QuickTransit is a breakthrough technology that uses a modular architecture consisting of three key components. The front-end decoder reads blocks of instructions from the foreign applications binary and decodes them into an intermediate representation. The intermediate representation allows QuickTransit to understand the higher-level semantics and intent of the code.

The optimizing kernel reads the intermediate representation and optimizes the code. At first, simple optimizations are performed. In most applications, however, a 90/10 rules holds where 10% of the code is executed 90% of the time. The optimizing kernel looks for blocks of code that are executed often, spends increasing amounts of time improving the optimization of this code, and then stores this optimized code in memory. Each time a frequently used block of code needs to be executed, the highly optimized code stored in memory is used instead of optimizing that block of code again. Because the blocks of code that are executed change frequently, the optimizing kernel flushes old optimized blocks and generates new ones. The optimizing kernel produces superior code optimization compared to static binary translators or compilers. It optimizes code based on how an individual user is using that application and does not need to optimize code for the general case.

The back-end code generator outputs code for the target processor. Different RISC, CISC and VLIW back-ends provide different ways of performing register allocation, instruction selection and operand addressing modes to take advantage of the distinct features available in a particular target processor.


Adding Altivec support would involve working out what Altivec instruction maps to what x86 instruction (which doesn't necessarily have to be an SSE instruction), and adding them to the translation table. But you have to keep in mind that no one but Apple has Rosetta's source code. And trying to patch something of this magnitude into an unknown binary is pretty hopeless.


More than hopeless. If it was just a "translation table", the change may not be that hard - but it's much more than that.

What we may see is a third party Rosetta replacement, like the "Speed doubler" that replaced the 68030 emulator in the 68K->PPC migration... but even this is doubtful, since most PPC apps that need Altivec will probably get an x86 native port in short order, or they'll be OS9 based and you'll need to run them under Sheep Shaver.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy