Switching architectures would necessitate some changes to the operating system itself, increasing complexity and slowing it down. Yes it has a long way to go, but we can never be too cautious.

@Andreas

My reasoning lies in watching BeOS go from the BeBox to intel. I had the chance to test drive a rare BeBox once and BeOS was noticeably faster than it was on my intel P2 system. I really was disappoointed too, that later versions of the system became excessively complex. I aim to keep things as simple as possible. Our path for now is clear, and I'm sure we will soon find a solution without needing a HW switch.

[ Edited by Dreamcast270mhz on 2011/3/18 7:31 ]

> Switching architectures would necessitate some changes to the
> operating system itself

So far, so good.

> increasing complexity and slowing it down.

That's what I still don't understand. Could you go into more detail please?

> My reasoning lies in watching BeOS go from the BeBox to intel. I had
> the chance to test drive a rare BeBox once and BeOS was noticeably
> faster than it was on my intel P2 system. I really was disappoointed too,
> that later versions of the system became excessively complex.

I could as well argue that this is just the way BeOS went, regardless of the architecture switch, so that it would have followed the same trend if it kept to PPC, going the way from G2 to G3 to G4 and finally to G5. Besides, you cannot generalize from one example. MorphOS could just as well be a counter-example. Following your logic, MorphOS shouldn't go the G5 Mac route. After all, G5 is faster than G4, automatically leading to the OS getting more bloated due to "more half a**ed coding", right? And ask yourself if MorphOS really got more bloated on its way from 200 MHz G2 (PowerUP) to 1500 MHz G4 (Mac mini).

> I aim to keep things as simple as possible.

Me too, but for the software side, not for the hardware side. Else I wouldn't have switched from a Pegasos I to a Mac mini G4.

> I'm sure we will soon find a solution without needing a HW switch.

If by "HW switch" you mean "ISA switch", then yes, it would be ideal without it. But that would require a hardware switch (or rather move) to another (and preferably faster) PPC platform after G5 Mac. I hope that such platform will arise, suited to run a desktop OS like MorphOS, even if it would obligatorily mean that MorphOS becomes more bloated ;-P

Quote:

I like it a lot!

I'm using it a lot more than my Atom based HP Mini netbook!

Here is my "first encounter" report, with photos:

http://www.amiga.org/forums/showthread.php?t=56984

I think the HW as such is rock solid! As far as I can tell, there are still things to do on various driver/HW-acceleration.

But I'm very happy for it, and I use it many times a day!

Sure, having MorphOS on it would be a dream...

Quote:

I own 2 BeBoxes and they are still rather cool systems. BeOS is still very nice. I may have to sell one BeBox though one day so I can afford more Amiga stuff if that is the direction I go.

tj

@macsociety

Let me know if you plan to some day, because I or a ton of people I know would kill to have one


@Andreas

You could see my arguement that way, definitely. But, for the purpose of this discussion, I will use BeOS as an example of MorphOS. 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, because the G5 is definitely a good move. 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. In addition, a PPC compatibility layer will probably be needed or else all software will need recompilation in order to work. A CISC platform also processes less efficiently per hz available, evident in the fact a 1.6ghz Pentium 4 runs slower than a 867 mhz G4 in many critical areas. 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 and thus this is why my old 3ghz pentium 4 failed to run Doom 3 at more than 10fps whereas my Powerbook G4 does it at a constant 30fps.

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