Nah, it does not have internal RAM like the SPE. Cache would serve a CPU better. The SPE is different because all it is supposed to do is crunch data, it's not made to work with many things a general purpose CPU has to deal with. The internal RAM on the SPE sounds to me like a dumbed down cache from what i've read.

Hm... any examples of processors that use such internal RAM?

Uses ARM7/9/11 cores. ARMs are traditionally cacheless.

Again, the RAM is not internal to the actual processing core itself. The 68HCxx are 8-bit (`05, `08) or 16-bit (`11, `12) parts.

There are several pretty obvious differences between these chips and the PPE that's being discussed. Most of the time these ICs are self-sufficient. Program code is stored on, and run directly from ROM/EEPROM. Unless they are performing exceptionally data hungry tasks, the internal SRAM is all the memory they will ever use. In such cases, cache is largely unnecessary.

Rather than to leave it hanging just like that, a conclusion should be in order:
The PPE is a processor core. Microcontrollers like the examples given are built around cores.

The last of the 68K series was the 68332, after which Motorola/Freescale evolved the architecture into the ColdFire series. You just used "68HC". The 8 and 16 bit freescale MCU families are commonly called by "HCxx", eg, HC05, HC12, etc.

A RTOS only needs as much RAM as necessary for a process table and storing context information (Instruction pointer, stack pointer, flags, GP Registers) for each process. Applications code can still be loaded direct from non-volatile storage like Flash ROM. Application heap space may be in external RAM. I admit we are seeing more lower end phones being able to run user installed programs, namely java games, but for the bare essential workings of a phone, larger RAM is unnecessary.

Quite a logical definition, but perhaps a bit narrow. For physically small or resource limited systems, this rings true. However, once certain criteria of performance (CPU/RAM) and user interface are met, an embedded system is entirely capable of self-hosting its development environment. For instance, one needs a decent method of character input, a screen that displays a reasonable amount of text, and storage for the source files and compilation tools.  My example of the "embedded PC" above could be one such system.

Oooi...why no debate here last few days one?? Must be running out of rumours and news and steams liao...

btw, to all those techie gurus, i just wanna ask this:

Why do you think the PS3 CELL has 1 "redundant SPE" and runs 25GFlops(theorotically) less?? IMO, redundant means FAULTY. SONY must be having headache trying to get enough good yield to get all 8 SPE working and thus probably getting a high % of literally.."half baked"..sillicons with one SPE still "uncooked"(or toasted...whichever u prefer...hee-hee).

I remember previously that SONY mentioned that the CELL will not be ready in time for the PS3, but obviously they squeeze the chip development schedule ahead to make the CELL ready for the PS3, but in turn have to sacrifice some time to further fine tune and improve the design and also the time needed for the manufacturing process to get mature to have high % of good yield.

So their best bet would be going for 7 SPE, which in their opinion is achievable without throwing away too many CELL chips (those < 7 SPE working).

Maybe a year or two later, they'll have a good enough manufacturing process to get enough good yield for 8 working SPE, then we have an 8 SPE PS3?

As for XBOX360, I think ATI unified shader is very interesting and certainly sounds a lot more flexible than Nvidia "Dual SLI GT6xxxx on a chip". But there's a rumour that the shaders can only do EITHER pixel or vertex shader PER CYCLE, meaning it's not as flexible as it seems, anyone have any more info about this?

Okay...finally the PS4!! Okay, i'm a bit far ahead, but if the CELL proves successful,  in another 6 years time, the manufacturing process will be good, the design has improve and they can make lots of CELL chip at rock bottom prices. And since the CELL is all multi CPU ready. The # of SPE can also increase per CELL CPU by then. By just packing in a couple of cheap CELL chips, they'll have the next PS a real powerhouse at a cheap price...which i think that's when their CELL hardware investment really pays off.(but of course, the PS3 would have guarantee them some ROI in terms of software royalty and other potential electronic products(TOSHIBA washing machine!!! Oh yeah, the next TOSHIBA washing machine will have a GIGABIT network port and linkable to your PS3!! Maybe you can control the swirling motion of the water from your PS3 BATARANG!! J/K) might give some cash back also)..after all, the according to IBM/SONY/Toshiba, the CELL was designed to cater for the next 10 years or so.

Still, currently, the CELL as it is, sounds good ( the multi SPE) but at the same time, it's a IN-ORDER CPU (like the XBOX360 PPC CPU also), which is much less complicated than Intel/AMD CPU's for PCs which is OUT OF ORDER CPU. I think OOO CPU is more powerful as it can predict instructions and acts accordingly while, IO CPU is simplistic and just acts on whatever it's fed.

Of course the benefit of the IO CPU is reduced size, meaning less HEAT and faster requency...so you can't exactly compare a PPC or Intel chip running at 3.2Ghz to a 3.2Ghz CELL.

Thus in order to fully utilize the CELL CPU, the PS3 archictecture have to have a huge bandwidth and streamline the instructions to the SPE via the Power PC core(what do they call that? PPE?), I've no idea how are they intending to overcome the shortcoming of the in-order instruction sets, but most likely, like it's predecessor, the EE and GS chip, by some the force of raw brute bandwidth, which hopefully is enough to feed it optimally.(the CELL is sorta evolution and further improvement from the EE/GS combo me thinks).

Finally a stab at the SPECS. All those bally-hoo about 2 TERAFLOPS ...but no mention on whether it is single precision or double precision..no mention of how the benchmark was done...same for MS. Basically, both are crappio marketing scheme.

I believe the CELL will be adequately powerful, but i don't buy it to be THAT powerful...just like the EE/GS back in it's time. But i think the real payoff of the CELL is not now, but the next 5 years, when the manufacturing process has improved and design has been further finetune and when multiple cheap CELLS are easily available and linkable in a single motherboard to power the washing machine, TV, fridge,steam iron and whatelse...PS4..

Okay guys...shoot away.

Thanks to Silkworm and Ray for some explanation....i don't pretend to understand everything Silkworm put up there...maybe 30% , but good enough for me.

So that means the PPC and CELL has "branch prediction" which achieves similar results to OOO execution, rite?
9 SPE? No, i was saying 7 SPE. It is in the official PS3 SPECS all over the web. It's mentioned "1 SPE reserved for redundancy" or something like that.

Added:

Here's a nice link for reading the CELL...haven't finish reading it myself...hurts my head...LOL.

http://www-306.ibm.com/chips/techlib/techl...icle-021405.pdf

We can have a peek at the Linux "model" of programming the SPEs in these kernel patches released a couple of months ago. SPEs exist as "files" in the filesystem and that's how program code and data are transferred onto it. The SPEs are idle until a DMA "kick" command is sent to it, after which it looks like it's controlled by the standard POSIX threading API. At least, that's what I've managed to glean from the raw patch data. I'd need to actually patch the full kernel source to see the context of some parts, like the interrupt controller and the memory management unit.

One might also gain insight on the programming model of Cell from the archived presentation/webcast linked from Power.org, from the Barcelona Power conference held last week. I haven't had a chance to view it yet and the webcast isn't downloadable for offline viewing.

Take it easy, the host thread is stalled, not the entire PPE. The SPU/SPE is going to be encapsulated into a Pthread, as you will see in the "bpathread.c" module.

The PPE got a bump up in size in the "DD2" revision of the Cell, but there hasn't been any concrete explanation as to what was changed, just more speculation. Anyway, more goodies for the technically minded: papers at IBM research

The TRE demo paper is a good one.

I think you might have gone off-track somewhere. The round-robin scheduling is applied to the four regions being processed within each SPE, not SPE-to-SPE. There is a significant delay in DMA fetches, but that is being hidden by the double-buffering of input and output per SPE. As they explain further down, at any one time an SPE is calculating the ray intersection and downloading data for the next cut into LS. I believe they are doing it in this way to leverage the fact that the SPE is capable of issuing a SIMD arithmetic op and a load/store/DMA channel op per clock.