Excitement about NatAmi

[SamuraiCrow]

I don't know the answer to that one.  The speed of the memory may be fast enough without a clock bump.

[SamuraiCrow]

Benefit to whom? Most multiprocessing hardware you are likely to see is geared towards SMP. Having identical processor cores, preferably all on the same die, helps simplify everything from hardware cache coherency up to software kernel design.

There was at one time an effort to create a "Robin" core for the NatAmi.  It was to be a 4-threaded RISC machine with 64-bit SIMD clocked at 200 MHz (50 MHz per thread).  We were expecting to be able to use this core for audio mixing and vector processing.

Since we've switched from the LX to the MX design for the mainboard an alternative sidekick core will likely be more conventional and symmetric than first expected due to the capacity of the Cyclone IV being greater and allowing us to reuse some code from the main CPU design.  It won't be pure SMP but will be a more conventional ASMP core than the Robin core was slated to be.  We won't know how to build it until the initial N68050 tests are run on the MX prototypes.

[SamuraiCrow]

I don't think NatAmi will need an SMP aware OS for a while. First step is the 68050. Next step is the 68070. After that maybe they will want to add in SMP capability to the core - but that's surely several years and a hardware revision away?

SMP will not come to the NatAmi at this time.  ASMP (asymmetric multiprocessing) is quite likely, however.  It may no longer be called the Robin core but it will run AHI drivers for mixing and other functions.  I'm hoping for a hardware matrix solver before too long since that would come in handy for many functions but priorities lie on the N68050 and the SuperAGA cores.

@Karlos and Hattig
The NatAmi's processor softcore is the N68050 to differentiate from the discontinued Motorola 68050 chip.  Likewise the sequel to it is called the N68070 to differentiate it from the Phillips 68070 chip.

[SamuraiCrow]

This is one thing that AmigaDE had right in concept.  We have seen this actually implemented with graphics cards.  I don't know if it still has it, but at one time, any features of DirectX that were not implemented in the graphics card would be emulated in software.  We already have very effective AMP in most systems with one processor running graphics, and a completely different architecture running the rest of the code.

As long as there is a fall back virtual machine, the effort to port to new platforms should be trivial in comparison to porting the entire OS.  New platforms would require a small (in comparison) effort to get the base system up and running, and then anything after that would be optimization.

I suspect that in the short run, this would have a performance hit, but in the long run, it would keep the system from being tied to any one system.  It would also allow for an unprecedented level of backward compatibility, as you could always run the old system as a subsystem of the new one.

As an AROS developer and LLVM supporter you should know about this PDF.  It's an attempt to run Google Native Client apps in the browser regardless of what processor it has.

[SamuraiCrow]

For legacy support, Google wants to have C++ LLVM.

LLVM-GCC is being dropped in favor of Clang if that's what you're referring to.  For up-to-date status as of a month or so ago, there's an MP4 outlining the PNaCl project at the LLVM Developers' Conference 2010 web site.