We never claimed our MMU approach was faster, in fact it most likely is slower.
(Although the net-effect will not be very important.)
That's not the point however.
The idea behind the MMU approach is to leave the ABI/API unpolluted by the emulation technology.
Once the system is fully PPC native and all your apps and games are PPC native, you'd still be stuck with your legacy baggage in the ABI/API.
This is called thinking ahead. We're not going to go for short-term fixes.
Another reason is that it obviates the need to insert emulation traps into the source-code.
Sorry, but the BS-o-meter is about to burst..
What legacy baggage are you talking about ?
The emulation-traps ? Why would they still exist
(as baggage) in a system that is fully ppc-native ?
As you have to recompile to change an exe, the traps
would be gone anyway.
Instead you have legacy-supporting baggage *in the system* to support this. Somehow I think having baggage in transition-apps is better than baggage in the new system.
About MMU-method beeing faster.. I cannot remember anyone official saying this, but Im
not sure, as that has been something floating around as an argument to use it for quite some time.
Well, anyway, it wasnt true.