> Other than programmers that write assembly code for one
> architecture or another, I don't see why anyone would have
> any preference for one CPU type over another

If we want to retain compatibility to m68k Amiga software (rexxsyslib.library comes to mind as a necessity*, but also gtlayout.library as shipped with MorphOS is still m68k) we'll have to stay with an architecture that can operate in a true big endian mode. That's purely a technical constraint and doesn't have anything to do with personal preference. I don't know if it would be feasible to go an Amithlon-esque way though, i.e. have a big endian ABox running on a little endian Quark kernel running on a little endian CPU, part of what Zylesea outlined. That's something someone with the insight of laire would have to comment on.

* There're possible ways out of this dilemma, as discussed here on MZ: http://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=7711&forum=12

> I don't see any change of plans or direction in which platforms will be supported
> in the future. Maybe if the Team adds one or more wizards of OS development
> that know the x86, or Arm architectures expertly, then we might see a change
> in direction for the future, but until then, I don't see anything changing from what
> they have told us will be supported & hinted at with screen shots of G5 systems.

I don't think the discussion is so much about MorphOS going x86 or ARM *instead* of going G5 Mac but more about going x86 or ARM *after* having put the G5 Macs to use.

> Long term future plans are too far off to worry about

Yes, maybe we should just be looking forward to G5 Mac support and not discuss what could or should come after that ;-)

Discuss - why not? We are not forcing Team to do anything, we have no power to do that anyway ;) But until discussion is interesting then ok, other than that better be silent. Also I'm looking forward to PB support, G5 is too far away I think.

Quote:

And are you feeling, like me, that that lovely computer is in DESPERATE need for a decent operating system? The stock Ubuntu 10.10 does have a helluva lot o' functions, but doesn't take advantage of the specific hardware, thus making it very very slow.

It won't change the fact that we don't plan to expand the range of supported hardware beyond what we have already shown in public for now ....

Ok, then we can change word discussion for dreaming ;)

Oh there is another chance for new MorphOS dedicated HW. Just wait until I win lotto...

Thanks Frank. I already am satisfied with what I have . Betterr video cards woould be nice and the Powerbook support will be great. I can wait for the G5 for some time.
Don't get me wrong G5 iMac and 2,3 Powermac support would be great, but I can wait for their release,
I've already got pretty good performance with the G4 and have an X800XT. A driver for that or a 3d driver for the 9700 would be useful.
With of course the qualifiers that some of the developers previously mentioned that some hardware may not get support. If that is the case, so be it, you've already done so much.

JIN



[ Edited by Jim on 2011/3/18 18:36 ]

Without going too far into the PPC vs intel debate, I see my stance as, say a rifleman prefers his old Mosin Nagant to remington 700: The 700 has little to offer to the mosin nagant owner as he has probably become more proficient with his old rifle than any potshot with the 700.

The x86 platform consists of a CISC processing system which has been found to be inferior to a RISC platform in terms of processing efficiency. To put this in perspective, in the past many home computers were more powerful than comtemporary consoles, yet the console could run the game at a smoother framerate. The reason lies in that computers have always had more storage and to be honest more than 40% of all code in modern programs could be removed and the program optimized. More powerful processors only encourage more half a**ed coding. PPC is an optimal solution in my opinion: cheap and easy to get, moderately powerful and has a large set of IDEs and libraries available for it.

X86 or ARM is not the answer, ever. I think the community is too demanding of these devlopers who develop for very little. If we drive MorphOS into a bloated OS like Windows it will be the shame and folly of every fool who let it get to that.

My message to the people who want new hardware:

I understand, we are all born to think "new" is better. But new is not better, as a computer rapidly loses value from its original price and look at it this way:

You don't need cutting edge, that is what brought you here, you want quality and that old feel of AmigaOS (at least thats me)

Anyways a used computer isn't bad at all (they aren't going to break anytime soon), it is like people who whine why their gun is all rusted from using corrosive ammo: You didn't take care of it, anything with proper care and maintenance is will last many years.

> X86 or ARM is not the answer, ever. [...] If we drive MorphOS into a bloated OS
> like Windows it will be the shame and folly of every fool who let it get to that.

Porting MorphOS to x86 or ARM will make it a "bloated OS like Windows"? How so? I'm not exactly a proponent of changing ISA (especially to little endian one like x86), but your kind of reasoning is beyond me.

Layer upon layer of backward compatibility? It wouldn't be pretty but it'd probably still have a way to go before it gets as bloated as Windows etc.

> Layer upon layer of backward compatibility?

Let's assume a port of MorphOS to ARM (running in true big endian mode). Then we'd definitely need an m68k emulator. With that we'd have the same complexity we've now on PPC with Trance. About the necessity of a PPC emulator we could argue I'd say. But even if it was decided to have one, I think the m68k emulation layer and the PPC emulation layer would run alongside, not the m68k one on top of the PPC one. What makes operating systems slow is not the sheer amount of layers but the stacking of many layers.

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.