> I am in full support of porting to the G5 and it wasn't my intent
> to make it sound like I'm not in support of faster hardware

To quote you: "More powerful processors only encourage more half a**ed coding."

As far as I can tell, G5 is more powerful than G4, and G4 is more powerful than G3 and G2 (where MorphOS started on). So why is it that you think your 'rule' applies to faster x86 processors but not to faster PPC processors?

> What I intended to convey is that moving to a CISC or other RISC
> architecture is undesirable as it would require rewriting of critical
> portions of the OS, Trance, and require a set of new drivers.

Yes, that's what I already said I understand well, with only one objection: new drivers would also be required for the G5 Mac port as well as for any port to any future PPC platform. So that doesn't have anything to do with ISA change per se. What I still don't understand is how an ISA change obligatorily leads to "increasing complexity and slowing it down".

> a PPC compatibility layer will probably be needed

Yes, that would be obligatory to run PPC executables. But as I said, I don't think that would slow down the OS as I believe that the m68k emulation layer and the PPC emulation layer would run alongside, not the m68k one on top of the PPC one.

> A CISC platform also processes less efficiently per hz available

I won't comment on that claim directly but will only say that RISC code is less dense than CISC code, which speaking of bloat means that RISC code needs more storage and more memory than CISC code :-P

> Therefore the speed of the CPU must increase to compensate and so must the
> RAM and bus speed. In effect this only encourages less optimized coding

But this effect won't occur with the G5's higher CPU, RAM and bus clock speeds compared to G4? And it didn't occur with the G4's and G3's higher CPU, RAM and bus clock speeds compared to G2?
Besides, I think your logic is flawed to begin with. You say that CISC must be clocked higher to deliver the same performance as RISC. So why should higher clocked CISC delivering the same performance as lower clocked RISC "encourage less optimized coding" then? Or is it that higher clocked CISC actually delivers *better* performance? Then I could somehow understand how it "encourages less optimized coding". G5 is usually higher clocked *and* better performing than G4, so if I was to follow your 'rule' from above I'd say that going G5 would increase the "half a**ed coding" in MorphOS, whereas a higher clocked processor with *same* performance wouldn't.

I should probably stay out of this discussion (argument?), but my crystal ball shows that eventually, in the far, far distant future, MorphOS will end up on x64 hardware running via emulation like WinUAE, but with PPC JIT translation or a virtual machine of some kind.

Of course, by then, if the MorphOS Dev. Team doesn't do the switch to PPC JIT on x64 themselves, they will have gotten bored with MorphOS and will have either disbanded, or moved on to something bigger and better and the above may never happen by anyone other than the Dev. Team, if there is not enough continued interest to make it happen. A lot of people thought that WinUAE would never amount to anything in the beginning (while others thought it was the Anti-Christ that would kill off the remaining interest in "Real" Amigas).


[ Edited by amigadave on 2011/3/20 13:10 ]

> my crystal ball shows that eventually, in the far, far distant future, MorphOS
> will end up on x64 hardware running via emulation like WinUAE, but with
> PPC JIT translation or a virtual machine of some kind.

There're already ambitions to achieve exactly that:

https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=7289&forum=3&post_id=82389#82389

So far it seems the MorphOS Team is resisting this idea.

With good reason.

> With good reason.

Yes, absolutely.

That is why my prediction is for the distant future, when the Dev. Team either has no other good choices, or doesn't care anymore and lets someone (or a group of someone's) do it instead of the Dev. Team.

I don't blame the Team for the current license model, as no one has suggested anything better that still allows for an acceptable degree of security from piracy and is not a horrendous problem to administrate.