> Andreas, now that you've had time to look a the preliminary data on the new
> AMP T4240 with its e6500 multihreading core, what do you think?

I think that for our purposes the QorIQ T5 with its fewer, higher clocked, single-threaded e6500 core(s) would be better suited than the QorIQ T4.

> Is the PPC dead?

Power Architecture is definitely alive.

> Is this device unsuitable for desktop use?

Technically, I'd say the T4 is suitable for desktop use. As outlined above, even more suitable for a non-SMP OS like MorphOS would be the T5 though (preferably a T5010, which has been indicated to be planned). Economically, the suitability also depends on the price of the chips, which is an unknown factor yet.

> Without SMP, I can't see MorphOS making much use of this

Yes, that's why I'd like a QorIQ T5010 with one 2.5 GHz single-threaded e6500 core to appear. This would ensure the best exploitation of the available T5 processing power for the lowest T5 cost.

> I would like to see a Linux implementation.

Linux support for QorIQ AMP has already been announced:

http://www.mentor.com/company/news/mentor-announces-embedded-linux-platform-support-freescale-semiconductor-64-bit-processors

> Just a dual core model would allow four concurrent threads

With the T4, yes. A dual-core T5 however would only allow two concurrent threads. Four concurrent threads with a T5 would require a quad-core chip.

> Virtualization has come to the PPC in a big way with this one.

PPC has had virtualization and partitioning capability also before the e6500, namely with the PPC970MP, PA6T, POWER4/5/6/7, PPC A2, e500mc, e5500.

> Maybe some clever tweaking of Quark could allow multiple copies of MorphOS
> to run at the same time.

From a user's standpoint I don't see much sense in running several ABox instances in parallel, but for developers this could come in handy, i.e. developing in ABox #1 on core/thread #1 and testing the software in ABox #2 on core/thread #2 (which could run a virgin installation of the ABox and wouldn't require rebooting the other ABox in case of a crash).

Quote:

Me too. It was surely the best they could do, given the situation were they woke up one day to see all desktop/laptop HW manufacturers suddenly leave PPC behind.

But I think most people understands that this current path is about to reach its end. There aren't coming any more PPC Mac's, and nothing else to replace them either.

I think we will see a MorphOS Powerbook release. I honestly *doubt* we will see a G5 release. And that's pretty much it! The End!

I don't know if you have noticed the differences between Hyperion and the MorphOS developers regarding PPC? Hyperion has time after time publicly denounced the idea of migrating OS4 to a new architecture. It won't happen, possibly because they are bound (?) to PPC by their license (not that they have honored that contract to a greater extent before, but anyway).

But have you seen anyone from the MorphOS team saying that MorphOS will never migrate to a different architecture? I think not! Instead, here are some scattered MorphOS developers comments on the subject:

About choosing PPC as target architecture in the first place, one developer said something in the lines of: "if we would have known back then what we know today, we would have chosen differently" (not an exact quote)

In a response to the comment "I only regret that again we have an announcement about old hardware", a developer said: "Fair enough, but don't whine if it ain't a PowerPC based box "

In a response to the comment "Due to lack of another new PPC-based hardware, I can make the only conclusion: this is the end of MorphOS ", a developer said: "IMHO Apple hardware is the only target that makes sense for PowerPC MorphOS at the moment." (and no, the emphasis was not put there by me, but by the dev himself)

In a response to the comment "Were MorphOS to be rewritten in X86 machine code, program code compiled for MorphOS would have to be specific to MorphOS", a developer said: "First, assembler code is rarely used for the PowerPC-compatible versions of MorphOS." (Insinuation that PPC versions aren't the only ones?)

OK, all this is highly speculative from my side of course. But I have yet to see *any* MorphOS developer publicly rejecting the thought of an architectural migration the rabid way Hyperion does. For all we know, someone could very well have been working on a non-PPC version of MorphOS for a long time already.

Or maybe not, who knows...?

Quote:

I think these processors will perform great in the various network communication applications where they will be used. I don't see Apple *or anyone else* using them to rebuild some kind of new PowerPC based desktop market though. Do you? The 8641 was also a very "suitable" CPU. And the 8610. And the 8640. Genesi had plans to build a new Pegasos and a Netbook based on these, they had some development work done, Matt Sealey (8641D) and Konstantinos Margaritis (8610) had the reference boards and had software up and running, etc. But eventually they shelved it. No-one else did it either, despite them being great CPU's back then (and still are, to a degree). I think they have been used in lots of applications. But not in general desktop computers, despite their "suitability". Ask yourself this question: Why?

@ takemehomegrandma,

I don't think we really have a significant difference of opinion.
I like these new Freescale processors, but even if used in computers they're more suited to a server role.
Andreas has mentioned the one that would be suitable for MorphOS (the T5010), but if it has the same PCIe limitation as the P5010 then we're stuck with X8 & x1, X4 X4 & x1, or X4 X4 &x$ (i believe, Andreas could correct me on this). It's better than an Acube motherboard would have, but its still not as good as the defunct PA6T.
A move to ARM would not present that much difficulty. As most ARMs support either endian solutions, emulating a 68K would be easier and more efficient then with an X86 (as would PPC code, but I don't anticipate emulating PPC code).
The boards are alrady available and the processors are becoming more powerful each year.

I've already mentioned the Pandaboard here and Andreas has pointed out other ARM based SBCs. Compared to a lower end Powermac or an Efika, these systems already have a performance edge.
If, as you believe, we don't see G5 support, then the natural next step would be something like the Cortex A9 or its successor.

Btw - I too looked at the 8641/8640. It just wasn't fast enough to make sense building boards with (not when cheap G4 Macs were available).
While I do like the T5010, I can't imagine limited production with it would be much cheaper then the X1000. This makes the ARM boards with their low prices really attractive.

> possibly because they are bound (?) to PPC by their license

Since the 2009 settlement agreement, which took over from the 2001 contract, with Amiga Inc. they're allowed to port OS4 to whatever they want, including other ISAs than Power Architecture.

"an ARM/X-Scale version of AmigaOS 4.x is perfectly possible."
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=33800&forum=25&start=40#618192

> not that they have honored that contract to a greater extent before

In terms of the settlement agreement there is no "before" the settlement agreement.

> Andreas has mentioned the one that would be suitable for MorphOS (the T5010)

*Most* suitable. Current MorphOS users with dual-G4 PowerMacs don't seem to care too much that their second G4 CPU lies idle :-)

> if it has the same PCIe limitation as the P5010 then we're stuck with X8 & x1,
> X4 X4 & x1, or X4 X4 &x$ (i believe, Andreas could correct me on this).

It's 'x8' or 'x4 x4 x1 x1' with SATA or 'x4 x4 x4' without SATA*.

https://morph.zone/modules/newbb_plus/viewtopic.php?forum=3&topic_id=7183&start=177

> its still not as good as the defunct PA6T.

QorIQ P5 can dedicate up to 12 SerDes lanes to PCIe 2.0. The PA6T provides up to 24 half-speed (compared to PCIe 2.0) SerDes lanes for PCIe 1.0 and GbE, which makes up to 23 half-speed lanes available for PCIe 1.0. So I'd say they're about on par overall. The only clear advantage of the PA6T in that regard is its better flexibility, as it can power one x16 PCIe 1.0 slot (which equals one x8 PCIe 2.0 slot) and some more slower PCIe slots whereas the QorIQ P5 can power either one x8 PCIe 2.0 slot and no more PCIe slots or just x4 PCIe 2.0 slots and some more slower PCIe slots.

> most ARMs support either endian solutions

Do we know for sure by now that ARMv7-A supports true big-endian?


* Edit: The SATA constraint may only refer to Freescale's P5020DS board and may not necessarily be there in other boards built around the P5 chip.

> here are some scattered MorphOS developers comments on the
> subject: [...]

And here's another one:

"Question is really is it worth of it. PPC is big endian platform allowing easy integration of old Amiga software to modern (in Amiga terms) PPC native operating system. With little endian systems that integration would be lost although it was more relevant ten years ago than it is today."
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=33868&forum=2&start=40#620205

>The only clear advantage of the PA6T in that regard is its better flexibility, as it can power one x16 PCIe 1.0 slot (which equals one x8 PCIe 2.0 slot) and some more slower PCIe slots whereas the QorIQ P5 can power either one x8 PCIe 2.0 slot and no more PCIe slots or just x4 PCIe 2.0 slots and some more slower PCIe slots.

yep, its definitely an advantage to have other slots than one dedicated to video (unless you're willing to go with an X4 compromise like Acube).

>It's 'x8' or 'x4 x4 x1 x1' with SATA or 'x4 x4 x4' without SATA.

I knew you'd tweak that one.

>Do we know for sure by now that ARMv7-A supports true big-endian?

No, I don't know about that.

I'd still favor a PPC solution, which is why I keep following these developments.
You've been right on top of all this for some time now, Andreas.
You must admit that things are looking more encouraging then they have for quite a while.

> unless you're willing to go with an X4 compromise like Acube

Just want to add that the x4 PCIe slot on the Sam460ex is first generation PCIe, so an x4 PCIe slot on a QorIQ P5 board (like this solution, which btw seems to be able to provide three active x4 slots and two active SATA controllers at the same time) would still provide twice the bandwidth, equalling an x8 PCIe 1.0 slot.

> No, I don't know about that.

Pity. Your statement made it seem like you'd know more in that regard.

> You must admit that things are looking more encouraging then they
> have for quite a while.

Yes, they do to me, mainly thanks to Freescale's decision to bring back AltiVec. Between January 2009 when I learned of the discouraging fact that there'll be no more new e600 based chips and September 2010 when Freescale announced its pleasant decision to have AltiVec back (this time in the QorIQ), the situation regarding Power Architecture looked worse, yes. Now I don't mind anymore the scrapping of the e600 based chip line. The e6500 core is probably no worse than what the e700 core with AltiVec would have been, and consequently the QorIQ T5 is probably no worse than what the MPC87xx would have been. It only gets a little embarrassing when you see how long it took Freescale to eventually realize what they had on the roadmap originally no less than 7 years ago ;-)
And on a side note, Nintendo's announcement to use Power Architecture in the Wii U is encouraging for the Power Architecture ecosystem as well. Whether any of those recent developments has the potential to benefit future MorphOS releases in any way remains to be seen, though.

Quote:

They handle big-endian data.


What is "true" big-endian? And why does it matter?

> They handle big-endian data. What is "true" big-endian?

That's the second time you ask this same question to me. And it's now the second time that I will answer it, or better: refer you to my answer from 5 months ago:

https://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=6726&start=119

:-)

> why does it matter?

https://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=6726&start=90

Quote:

That takes me to a page with links to another page with links to...

Couldn't you just answer the question?


I think you mean running code in big-endian mode. But, AFAIK how the code run is not important, it's the data ordering that is important and ARM does that fine.

The only time I think code ordering would make a difference is when you want to emulate something (e.g. 68K or PPC), but even there the emulator would handle that transparently, there might be a performance hit but that's not likely to be very big. OTOH a JIT based emulator would do the conversion once and so it shouldn't make any difference.

> Couldn't you just answer the question?

That would mean simply quoting what Neko wrote anyway. And if you hadn't ignored my answer from 5 months ago it would have been one step less now ;-)

> I think you mean running code in big-endian mode.

Yes, that's what it's all about when we're talking about running m68k code transparently, which is what Jim and I did here.

> The only time I think code ordering would make a difference is when you
> want to emulate something (e.g. 68K or PPC)

Err, that's exactly what this discussion has been about, i.e. running existing m68k code transparently on MorphOS/ARM the same way existing m68k code is transparently running on MorphOS/PPC right now.

> the emulator would handle that transparently

I doubt that's possible within a singular address space OS that is based on message passing concept like AmigaOS or MorphOS' ABox. There could be a way around this, though:

http://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=7771&forum=3&start=15

But that's an idea laire doesn't seem to like too much:

"Either you run everything as big endian with some x86 68k emulation and allow "native" code with some butt ugly compiler byte reordering thowing performance away. Some may argue that this might still be faster than existing ppc systems and this might be even true but there are things which are so ugly you just don't do them."
http://moobunny.dreamhosters.com/cgi/mbmessage.pl/amiga/126048.shtml

OK, I did a bit of reading and found a few posts that talk about the processor being able to read big-endian data but other parts of the system will be little endian.

These are usually promptly followed by "but this doesn't matter to MorphOS".

If you're moving to a different system you're going to need new drivers for all the hardware anyway so this makes no difference.


Being a Mac user I did the true big-endian to true little-endian switch some years ago. It went without a hitch, to the end user the switch was completely invisible and I can still run PPC software to this day.

> These are usually promptly followed by "but this doesn't matter to MorphOS".

Whether transparent m68k backwards compatibility matters is a matter of individual perspective I'd say ;-) If MorphOS was going to abandon it anyway it could as well be ported to x86 instead of ARM.

> If you're moving to a different system you're going to need new
> drivers for all the hardware anyway so this makes no difference.

Huh? What have drivers to do with transparent backwards compatibility to m68k applications and libraries?

> Being a Mac user I did the true big-endian to true little-endian switch some
> years ago. It went without a hitch, to the end user the switch was completely
> invisible and I can still run PPC software to this day.

That's because contrary to AmigaOS or MorphOS' ABox, Mac OS X is not a singular address space OS that is based on message passing concept.

To clear things up, if you say that ARMv7-A can't operate in true big-endian mode (did I understand you right here?) it seems that I had misread you there:

https://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=6726&start=92

In my book it is not a question of drivers, but a matter of shared structures and the issue that in this case address and data endianess should be the same.
I.e. if a big endian application points (BE data format) to 0x00000004 on ARM in BE mode will it get exec base or will it get some arbitrary value, because the address format may still be LE?
If the ARM chips in question don't offer a "full" big endian environment there's not much benefit over x86 IHMO.
This question (the exec one) was raised several times already and yet nobody answered it.

[ Editiert durch Zylesea 30.06.2011 - 00:45 ]

OK. I wasn't talking about 68K code other than in passing but I see the problem now.
...and the solution.

Quote:

True but... MorphOS is designed to have separate boxes.
You could run the existing A-Box in an emulated PPC environment. That in turn runs the 68K stuff.

You then have another A-Box2 that only runs ARM compiled stuff. Yes the 68K and PPC stuff will suffer but anything native will fly along.

It also means they can get rid of all those hacks and patches that they added to keep compatibility with the misbehaving Amiga apps. That'd be a much cleaner system albeit still based on a design that's over a quarter of a century old.

Ideally they'd dump the Amiga API altogether and build the Q-Box but I guess we can't expect miracles

> I wasn't talking about 68K code other than in passing

But that's what Jim who I replied to with my "true big-endian" question was talking about ;-)

> I see the problem now.

Finally ;-)

> ...and the solution.

Hear, hear :-)

> MorphOS is designed to have separate boxes. You could run the existing
> A-Box in an emulated PPC environment. That in turn runs the 68K stuff.
> You then have another A-Box2 that only runs ARM compiled stuff. Yes the
> 68K and PPC stuff will suffer but anything native will fly along.

Reminds me of this proposal, only with ARM instead of x86:

https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=6570&forum=3

Having two boxes for different ISA was suggested a while ago already (for x86).
https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=6570&forum=3#66869
But who's gonna do it? It is pretty much work.

>Pity. Your statement made it seem like you'd know more in that regard.

Sorry to disappoint you Andreas. I even neglected to notice that the Cell BE was an in order processor until we started to discuss it (you have much better attention and recall of details then I do - not to mention your superior ability to locate information).

As far as ARM goes, I only recently began looking at it. This was primarily due to post on this site.ARM does have some features that hold it back (in order again, therefore zero branch prediction, etc).

As mature RISC architectures go, I still think the PPC is one of the best.

Right now, pricing and availability of suitable hardware are the main obstacles from continued use of these processors.

> I even neglected to notice that the Cell BE was an in order processor
> until we started to discuss it

Really? You mentioned that fact in what I think was your very first posting here on MorphZone:

https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=6218&forum=11

I'm not aware that we were in contact before that.

> ARM does have some features that hold it back (in order again, therefore
> zero branch prediction, etc).

Cortex-A9 and Cortex-A15 have out-of-order execution as well as speculative execution.

https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=6218&forum=11

Wow, now I know how minator must feel. You recalled that? You MUST be a cyborg.
I guess I just wasn't as aware of big a performance hit in-order execution creates (until you posted some comparison benchmarks).

> You recalled that?

No. I just didn't recall that it was our discussion that made you aware of Cell being in-order. So I fed the MorphZone search facility with the terms "cell" and "in-order" and guess what it came up with: it lists your very first MorphZone posting as the oldest MorphZone posting containing both those terms.

> You MUST be a cyborg.

This I am as much as I am a prophet ;-)

> I guess I just wasn't as aware of big a performance hit in-order
> execution creates (until you posted some comparison benchmarks).

https://morph.zone/modules/newbb_plus/viewtopic.php?forum=3&topic_id=6993&start=66

You mean this?

Quote:

Why do you think in-order processors have no branch prediction?
The ARM10 had it over a decade ago and that was an in-order design.

Also, in-order does not automatically mean slow. It really depends what you are running. Things like Cell and GPUs are all in-order but they're very fast processors.
In-order becomes a problem if you are trying to run "control" code at high speed. Things like "data" processing heavy (think video, image, audio processing and even games) get relatively little advantage from out-of-order, so processors focused on data processing only tend to be in-order or at best only mildly out-of-order.

e.g. The new Freescale parts designed for networking appear to be "mildly" out-of-order, nothing compared to even a G5.

Prophet? No. Cybernetic? Not really.
But truly your ARE the king of the search engines.

And yes, I'd never realized how much of a role out of order execution and branch prediction played in modern CPUs until you quoted those figures.

I really had much higher expectations of the Cell BE's performance before that.

It also points to one of the reasons most PPCs have an inherent advantage over ARM CPUs.

>Things like Cell and GPUs are all in-order but they're very fast processors.

Actually, I used to think that too. Until we spent some months discussing it (and even making some inquiries to IBM).
You see, a 3.2 Ghz Cell BE IS fast. But how powerful is it?
You need to look at the benches that Andreas re-posted the link to.
Per clock cycle, an out of order PPC is much more powerful then the Cell's core processor.
Trust me, this has been thoroughly hashed over. Many of us had high expectations for the Cell's performance.
But the PPE core turned out to be somewhat weak and programming the SPEs for maximum efficiency was about as easy as juggling running chainsaws.