ARM vs. PPC (why continue the PPC path?)

[SamuraiCrow]

Since getting PPC performance up to snuff requires compilers with cache hints and other tricks, I see no reason to continue the PPC path.  It was a temporary kludge.

ARM is the cuts a lot of cruft out of other instruction sets including the x86.  Though the AMD64 has better developed software that Amiga cannot use, ARM looks more promising.

Going back to 68k is more promising, for that matter.  Since the N68050 is slated to contain some of the same features as modern ARM processors, it just is a matter of finishing it up and getting it on the market so we can work out more bugs and get it mass-produced someday.  If the N68070 cannot beat the performance of a 68060 per clock cycle, it might make sense to switch to AROS for ARM.

I look forward to the Raspberry Pi, even if it doesn't run much Amiga software.

[SamuraiCrow]

What graphics should go with it?

The Raspberry Pi has a SoC so it comes with the OpenGL-ES graphics core on the same chip as the CPU.  Since OpenGL-ES can support fixed-point maths, it might be tricky getting some Mesa support since that requires floating-point maths.  We'll see how it goes.

[SamuraiCrow]

Exactly, why add yet an other architecture, on an already small and divided market?

In a word:  Cost!

The original post of this thread reveals that ARM based netbook can plow the streets with a SAM 460 yet cost much less.

Personally, I'm holding out for the NatAmi MX and the Raspberry Pi.  I've got a Micro-A1c but I'm not going to shell out that kind of money ($1400 for a complete system) again.

[SamuraiCrow]

@CommodoreJohn

There was BBRV's blog post about a new Efika MX model coming sometime this year.  It might not be so powerful as what you're looking for, but it should be a bit faster than the existing Efika MX.

[SamuraiCrow]

Re:x86 vs. ARM performance vs. others

I was planning to use the 32-bit little-endian target being introduced into the Clang compiler by Google for use with their PNaCl virtual machine in conjunction with AROS.  It would be a statically compiled virtual machine (install time compile instead of JIT).  This way recompiled apps could be installed on ARM or x86-32 bit machines with equal ease.

It also wouldn't be too hard to add a big-endian 32-bit target to the compiler by modifying the other little-endian one.  This would allow PPC and any other big-endian machine such as the N68050 will be able to run the same code.

The big limitation is that running the code from these VMs on anything 64-bit would require a 32-bit emulation sandbox.  For Google's purposes, that's fine because their PNaCl browser plugin for Chrome will include a sandbox, but running a 64-bit version of AROS will also require a sandbox.

Another option would be to have a third and fourth file format that support 64-bit architectures in big-endian and little-endians respectively.  In my opinion this is a pain.