> PowerPC is a dead end, with the only two producers already migrating
> their focus away from it into other ventures.

That's not true, for none of the "only two producers" IBM (Cell, upcoming PPC476 and PPC A2), Freescale (e200, e300, e500 (esp. upcoming QorIQ)) and AMCC (PPC460, hopefully upcoming Titan (not cancelled yet)).

There is a certain cool factor with a netbook, but I really don't see a positive outcome in uprooting the small community we have in forcing a complete change in direction. It might be something to consider on a long term road map.

If MorphOS were available and running on Mac Minis right now, I'd purchase one (and a new license) just for the speed boost. (My Peg 1 works well for most tasks, but there are occasions where I wish it were faster.)

I think a good move (short term) would be to assemble a team of people together to promote a mac mini friendly MorphOS realease by spreading the "good word" on Mac sites and generate possible interest in the people who have not switched to faster machines. That could possibly increase our user base and also possibly increase our pool of developers. (When such a release happens.)

If an architecture move didn't include losing what we do have for software right now it wouldn't be such a big deal. Starting from scratch with what little resources we have to rebuild it just seems like a bad idea.

Quote:

This is one of the best things I've heard lately. MorphOS is already an independent product, self contained, call it what you like. Our hardware dependency is a shame, and it should be avoided.
What should MorphOS Team do? Build a hardware team (yea, easy!). And, if that route is taken, imagine what would be easier: Building a PowerPC based computer, with all the provider problems we all know, or go the ARM route, with a much broader base of suppliers, and best of all, licencing schemes: We could even have our "own" CPU. And, as "Downix" says, if we had problems with our CPU supplier, we could switch no another one with little drama.
Of course, the CPU is only part of the computer, but the key here is that building your own ARM based computer is indeed a possibility.
And I like PowerPC a lot. But also realize that:

1.- There are clever indeed chips out there that are not PowerPC.
2.- Huge power from x86 doesn't make sense in MorphOS.
3.- ARM has very big momentum now.
4.- It's about time to give freescale the answer they deserve: Quit.
5.- Control of our destiny. Also in hardware, as in software, the Team already has.

By the way, "Downix", are you Nathaniel Downes, formerly related to Genesi? Your first words about Matt Sealey are interesting...

I have written this before, but I will repeat it again. What we need more than new hardware, or a switch to a different CPU/platform is more users and developers and applications in this tiny community of MorphOS users. I think the quickest route to that goal is to take advantage of as many PPC Mac models as the team can quickly get MorphOS3.x working on. Then hopefully there will be more users and more new programmers creating content and applications for MorphOS and if the team will accept new members to develop MorphOS itself, then maybe they will be able to find those extra coders to help port MorphOS to a different architecture faster. This will also make it more cost effective to sell any new hardware that may eventually get created for MorphOS as a bigger user base means more potential buyers will want to upgrade to the new hardware.

Maybe I am wrong about the size of the MorphOS user base, but it seems to be very small to me. I am trying to learn more programming so I can contribute by helping others work on new programs, porting existing programs from other OSes, or creating new programs myself.

Quote:

For which market? There is virtually none, not even if multiplied by 10 or 50. At least none that would justify or sustain production of your own silicon. There is much, much momentum inside the processor market. Powerful processors are mostly driven today by Intel, Intel and again Intel. *They* dominate the market and they will continue to do so. So, *if* breaking with a big endian processor and leaving the niche under this nice stone called ppc, then it seems wise to me to go the most popular way. the way with the most benefit.
x86 based computers are everywhere and will continue to be everywhere (at least for a long, long time). You don't get yourself in some weird dependency. Support x86 and you will never ever (next 50 years at least) again have a hardware shortage.
ARM will dominate the mobile phone other 32 bit emebedded market, but I don't want MorphOS neitehr on my mobile nor on my navigation device or the dishwasher (well, that one probably conatins a 8051, but I guess it is clear what is meant).
Anyway, one step after another. First lets get the Mac Mini port, and then we will see what comes next. But I doubt neither x86 nor ARM will be a good option for MorphOS. Both architectures will yield to a binary incompatible fork from MorphOS PPC. If ARM would fully support big endian mode, I'd have voted for ARM. But since it is de facto little endian I don't see much benefit in ARM over x86.
But, okay, if breaking with binary compatibility anyway and do the required changes in MorphOS it would be wise to change the OS to maximum portability anyway. Then it could easily support ARM and x86. but this would be some kind of different OS (because it would be stupid then not to take teh oppartunity to change some annoying internals of MorphOS which are still in there for legacy reasons). Then you could straightly turn to Anubis (which I think is an interesting attempt with a good approach).

Quote:
The one and only.

Quote:
ARM does support Big Endian, so I am quite perplexed by your comments there. Only the XScale model does not. That eliminates 1 series out of dozens. And nobody is proposing that we get silicon, at least, not at this time. But having the option, should it present itself, would be a worthly long term goal.

But porting to the PPC MacMini, you realize that you are insisting on focusing all effort on a machine that was discontinued over 3 years ago? The existing models are aging, and will be that much older when we are ready for it. That is my concern. I would note, I own a PPC Mac myself that would likely be able to run MorphOS with a MacMini port, so I would directly benefit from the effort, and I'm the one saying it is not the wisest investment in time and energy at this stage in the game. Our market is too small to gamble and waste energy on dead ends.

> It's about time to give freescale the answer they deserve: Quit.

You mean refusing to support Freescale's ARM (i.MX)?

> "Downix", are you Nathaniel Downes, formerly related to Genesi?

http://www.amiga.org/modules/newbb/viewtopic.php?topic_id=24205&forum=21#forumpost308291
http://www.amiga.org/modules/newbb/viewtopic.php?topic_id=24205&forum=21#forumpost308434

;-)

@ downix

Indeed, now I am quite confused. I read somewhere that ARM's big endian mode would basically just be the possibility to load big endian data correctly (i.e. e.g. word order is correct), but addresses themselves, representation of internal states and counters would be in little endian schem. Now I read the "programmer's model for Big_Endian ARM" from arm.com and from that document I understand it that way again, I originally thought it would be.
ARM >= ARM6 can be operated in true big endian mode. But as said, I *am* confused now.
My take on it is as follows:
What would happen if a 68k app running on a hypthetical MorphOS ARM with transparent 68k emulation would try to access, say, 0x00000004? Would it get a pointer to exec base or would it get elsewhere? If it gets some other than the exec base pointer, then I guess a 68k (or ppc) emulation is in some serious trouble. If it works, fine, then there is no endianness problem. But I was not able to disentangle this problem myself. I cannot predict the behaviour of ARM from the docs I read (I definitely don't claim to have fully understood what I read!!).
If you or someone else can enlighten me in this case, that would be appreciated very much.

> I think i got it now. ARM chips are able to load and process big
> endian data, while addressing und such stuff are always little endian.

Don't jump to conclusions about ARM's endianess(es) ;-) I just wanted to point out that there's a difference between just "endianess" and "true endianess".
Given the existence of a (non-official) big-endian ARM (ARMeb) port of Debian there must be true bi-endian ARMs able to operate in true big-endian mode.

Hint: Don't believe everything Neko is telling. He is not only wrong about ARM generally being non-true big-endian but also about Power Architecture generally being non-true little-endian.

Quote:

The way to look at it is this way: ARM replaced multiple BE architectures in the past, from the 6502 to the 68k itself, in multiple machines, all with minimal performance impact. See the Palm for prime example. Palm's OS is, frankly, even simpler than MorphOS or the Amigas OS, yet it did the transistion pretty smoothly, wouldn't you agree, and during a period with far weaker CPU's than we have today.

And what you you mean Power being non-true little-endian? **eyes his OS/2 for PPC CD, pure LE PPC baby!**

> what you you mean Power being non-true little-endian?

Misunderstanding? It's definately not me meaning this. Quite to the contrary. Read Neko's comments here and here. This is what I and obviously Zylesea/[ujb] refered to.

Quote:
I know, I was trying to join in the comments.

@r1vver

I don't think the team has plans to port to ARM anytime soon.

MorphOS on ARM would require a decent 68k emulator and llvm support to make any sense.

ARM cpus are pretty weak compared to PPC and despiting the fact that PPC desktop market is dying I don't see ARM desktop market flourishing (I don't need to run MorphOS on my Cellphone or my clock).

Even if switching to other cpu architecture was an easy thing and the m68k emulator was already available it would cause a lot of confussion to the users. Some kind of LLVM abstraction would be desirable before jumping to other cpu architecture.

The number of MorphOS/amigaOS users is pretty pathethic, do you really expect developers compiling versions for each MorphOS flavour? I have seen what happened with AROS-PPC/AROS-x86_64/AROS-x86/OS4/MorphOS/OS3 and I don't see many developers creating binaries for so many architectures.

Even if ARM sounds cool x86 machines make much more sense for desktop usage, users can get x86 based hardware easily.

If MorphOS left PPC it would have to jump to the x86 ship. But PPC ship still floats

I don't care if G4 Mac Minis stopped being sold 3 years ago as it's a kickass machine -in amigaos terms- that will run rings -in terms of speed- around any ARM machine for at least 3 years. It has been produced in millions of units and it's cheap. Pegasos/Efika are much more expensive compared to Mac Mini.

The only reason we stick to PPC is because MorphOS runs on it. We would prefer that our hardware was cheaper and easily available. It's a pity MorphOS didn't run on Mac Mini when it was released but it's the most affordable machine we can get ATM. MorphOS on Mac Mini can play 1080p videos so I think it's decent ATM.

Quote:

ARM doesn't support Big Endian in anything but a bullet-point feature sense.

The same is true of PowerPC processors which supposedly support Little Endian operation.

The basic promise made in supporting these features is that it reorders bus transactions so they fit the right data format - memory is laid out in Big Endian, but when you load it into a register, it is flipped automatically and in the register on your Little Endian processor, you have Little Endian data.

On PowerPC, you can fudge this manually without changing modes at all if you know the data format ahead of time (stwbrx, lwbrx). I'm not sure what the equivalent is on ARM.. maybe it doesn't have it, maybe it does.

Instruction opcodes are still Little Endian in ARM whatever mode it's in. Internal registers and devices are all Little Endian. All that changes is how it routes data from memory into the cache and then the register. It is a limited subset.

The SOLE reason for these features is because both ARM and PowerPC targets can and do run as device targets (e.g. on a PCI bus with another host processor doing the control) and they need to be able to interoperate with those buses. It does not magically turn your system into a Other Endian chip, it just aids interoperability - the same way that running Samba 4 on a Linux box does not mean you have a Windows 2008 Domain Controller, it just means you have a subset of the functionality which look for all intents and purposes like you do (you are basically not running Windows, so don't expect every feature of Windows!)

However absolutely NONE of this is relevant to MorphOS. MorphOS is for all practicality endian-independent - the only reason it gets thorny is trying to mimic PowerPC and/or m68k operation. So, the solution is.. drop those things in the trash where they belong. MorphOS has plenty of developer support and a huge amount of open-source software out there that can simply be recompiled. AROS is proof positive of this - it runs on x86 AND PowerPC, and it certainly does not run the PPC in little endian mode.

Do many people really still want to run 15 year old software from an A1200? Would they buy a Netbook and want this feature?

Maybe you would. The other million customers would not give a shizzle either way.

As for the bleating about "the MorphOS guys should get a hardware team together", what on EARTH have you been smoking lately? I recommend you stop. The MorphOS team, if they wanted to port to ARM and take control of an ARM license and develop an SoC core, can make a business case RIGHT NOW and Genesi and bplan will take in on for them. bplan have ALWAYS been around for the MorphOS team to do this kind of project. We have the contacts inside Freescale and ARM, ODMs standing by to produce millions of units.

> ARM doesn't support Big Endian in anything but a bullet-point
> feature sense.

Opposed to what you (and downix for that matter) claim, at least StrongARM and XScale are able to do true big-endian. Or what do you think the already mentioned Debian ARMeb, Debonaras, SlugOS/BE and Angstrom for IXP4xxbe are for?

> The same is true of PowerPC processors which supposedly support
> Little Endian operation.

No, true little-endian is supported at least by MPC8xx/e200, e300, e500, PPC4xx, (upcoming) PPC A2 and PA6T/PWRficient.

For e300 refer to page 23 of http://www.lauterbach.com/pdf/debugger_ppc600.pdf

> ARM does support Big Endian [...]. Only the XScale model does not.

XScale definitely does support true big-endian (see Debian ARMeb, Debonaras, SlugOS/BE and Angstrom for IXP4xxbe).

> The fastest ones I've seen in person have been Marvell's 1.2Ghz
> dual core model (78200).

According to the Marvell website the dual-core MV78200 maxes at 1.0 GHz. At 1.2 GHz it would rather be the single-core MV78100 or the single-core 88F6281.

Quote:
The MV78200 site clearly lists 1.2Ghz. However, then I've looked for them for sale at various vendors, I could only find the 1ghz and 800Mhz models listed as available, so we both might be right in that yes, there is an MV78200 at 1.2Ghz, but it might not be available in any significant volume at this time, nor even shipping yet.

As for the BE/LE thing about XScale, I went and dug up the reference I was using. I'd realized I was looking at a very old reference for StrongARM from DEC, and was for a prototype unit at that, so consider that statement retracted.

> we both might be right in that yes, there is an MV78200 at 1.2Ghz,
> but it might not be available in any significant volume at this
> time, nor even shipping yet.

Yes, that sounds like a probable explanation.
May I ask, where and when did you see the MV78200 at 1.2 GHz in person?


Another thing that puzzles me regarding Marvell and ARM:

According to Marvell, their Sheeva core was developed from both the Intel XScale and their own Feroceon CPU, both being ARMv5 ISA implementations. So one would assume the Sheeva to be ARMv5 ISA compliant as well. But then there is this:

"Compliant with the Cortex A8, Sheeva also supports both the ARMv6 and ARMv7 instruction sets, making it the world's first dual ARM ISA compatible CPU."
http://www.marvell.com/technologies/cpu_history/cpu_history.jsp

What's Sheeva then? ARMv5 (like XScale and Feroceon), ARMv6 or ARMv7 (like Cortex-A8)? Or a combination of these? Very confusing. Can anyone shed some light, please?


Edit:

http://www.marvell.com/files/technologies/SheevaUntoldStory.pdf from August 2008 provides some further clues:

"2009 - A new flagship CPU: Newest CPU core features multi-Ghz performance, [...] out-of-order execution, and full ARMv6 and ARMv7 compatibility"
(page 2, "Figure 1. Timeline of Marvell CPU development")

"Marvell has extended its license to cover ARM v6 and v7, the most recent version of the architecture. The company expects to sample its first ARM v7 CPU in late 2008."
(page 3)

So it seems that contrary to the statement on the Marvell "History of CPU" webpage current Sheeva core(s) are ARMv5 ISA compliant and *not* ARMv6 or ARMv7 ISA compliant but *future* Sheeva cores are supposed to be.

On a sidenote, pages 5/6 are good for some great laughter:

"Marvell's recent 88F6000 processors achieve CPU speeds of up to 2.0GHz. This clock speed [...] is faster than any [...] PowerPC processor [...] To minimize cost and power, the 88F6000 processors use a simpler CPU design than other Marvell products. This CPU is a scalar design, executing only one instruction per cycle, and it has no reordering capability."

A fabled 2.0 GHz in-order non-superscalar ARMv5 faster than for instance an existing 2.0 GHz out-of-order superscalar PPC970FX? Good one ;-)

[ Edited by Andreas_Wolf on 2009/3/23 17:28 ]

Quote:
NDA from work, sorry to say. Should be able to discuss details in the next 3 months tho, if nothing goes wrong.

> NDA from work

So you have an MV78200 running at 1.2 GHz at work while "it might not be [...] even shipping yet"? Sounds like magic to me.

Quote:

Samples shipped over a year ago, not magic to me. You stop caring so much when it's the dozenth "next-big-thing" CPU you've had to handle this month. Some days I get surprised at things which have not shipped yet, or even worse, ones that have.

Did some digging, Marvell's 88F6281 is listed as being able to be clocked at up to 2Ghz, due for release this year. The 1.2Ghz version of this chip can be found in the SheevaPlug, which is a fun thing to play with I must say.

> Marvell's 88F6281 is listed as being able to be clocked at up to
> 2Ghz, due for release this year.

We'll see. In June 2008 it was announced to be clocked up to 2 GHz, 4 months later (page 2) it was reduced to 1.5 GHz, and finally it has been released with 1.2 GHz max.