Main CELL core is a MIPS design

[maven]

Regular
http://www.dekorte.com/blog/blog.cgi?do=item&id=1353

Today at the 2nd day of the Lua Workshop, Bret Mogilefsky (who I think works at Sony) mentioned that the Cell, although being manufactured by IBM, is not a modified PPC - It's a MIPS. He said they got the IP via Toshiba (Cell was a joint project between Sony, IBM and Toshiba) who appearently now owns MIPS. Maybe this has been mentioned on Slashdot or Ars before, but I certainly don't recall reading it.

Another interesting tidbit that I heard there that I don't remember hearing elsewhere is that the 3 core PPC chip being used by XBox360 has it's out-of-order execution logic removed (to make room for the extra cores)

I implicitly assumed PPC as well, but this makes emulation of PS2 much easier (if the instruction sets match).
 
Again hasn't all the previous information confirm it's a PPC? Unless SONY switched to a MIPS core at the last minute which would really upset IBM.
 
This, indeed, doesn't make sense. IIRC, Sony talked about having the PPE at the E3 conference, so most likely this is just a mistake?? However, it has already been discussed numerous times that if STI wanted to they could replace the PPE to make the CELL x86 based or mips based even; many configurations were possible. Still, doesn't make sense though.
 
Maybe the PPE core has some MIPS like instructions or some sort of hardware emulation? (Is that even possible? -- I'm not really sure on the archetectural differences between MIPS and PPC).

Seems to me that Steve Dekorte misunderstood or something. A straight up MIPS core as the PPE seems to go against everything that has been mentioned about the Cell since it's public unveiling.
 
I think there might have been a mixup along the way. If I recall from other articles on the "history" of cell, IBM's main contributing idea was the PPU (in fact, they proposed a 4-core PPU design), and the SPUs were Toshiba's idea..and then they all just worked together on everything.

edit - also, the quoted part of the article above does not say the PPU specifically is a Mips design
 
Hmmmm, MIPS cores using the PPC ISA huh? Sounds like major bunk to me. That first comment doesn't raelly make sense anyway. Cell is neither 'modified PPC' or 'modified MIPS'. It's a clean sheet design (according to the IBM team that creted it) using the PPC ISA and obviously design elements they've learnt from PPC - no need to reinvent the wheel.

Perhaps, if I'm feeling generous, I could let them get away with claiming the SPE's are MIPS based, in that the design of the vector unit or something may be similar to that of a MIPS, but as the SPU's work differently and use a different ISA, I wouldn't even be comfortable accepting that.
 
I don't really understand this thread -- if the processor follows MIPS ISA, it's a MIPS processor. If it uses PPC ISA, its a PPC processor. How can a "MIPS processor" use the PPC ISA?

*Confused*
 
I think in a thread recently it was the SPE's that were determined to be MIPS based, the source being the IBM interview on the Linux effort.

EDIT: Nevermind, I scanned the article (The Bergmann interview) and couldn't find 'MIPS.' I'm just going to re-read it now and see if I can find the earlier post from this forum also. I guess disregard my original sentence though.
 
The PPE is short for Power Processing Element, so Im going to go out on a limb and say that it aint no MIPS. The ISA for the SPE whatever it resembles is neither PPC nor MIPS, for the very simple reason that neither would work with the register file.
 
Well, that's very much true. Maybe the confusion all started from the hardware load/store instructions able to translate little-endian into big-endian?

Between that and the all the interviews out there about how at one point a MIPS-friendly design was on the table for Cell (to facilitate EE emulation), I could understand how some people out there could mistakenly think 'MIPS!' every now and then; even though it's been stated before that Cell is not bi-endian, some might still be confused.
 
IBM clearly states that the POWER architecture is used in Cell, we know that the SPEs are not related to any other IBM ISAs, therefore the PPE have to be a POWER or PPC core.
 
MfA said:
The ISA for the SPE whatever it resembles is neither PPC nor MIPS, for the very simple reason that neither would work with the register file.
I thought it shared the same ISA as the PPE. I sure that's what was said many moons ago. Dunno who by or when though.
 
Shifty Geezer said:
I thought it shared the same ISA as the PPE. I sure that's what was said many moons ago. Dunno who by or when though.
It was probably a simple speculative comment, because I don't remember anyone saying that the SPE used the PPC ISA, actually I remember the opposite.
 
Vysez said:
Shifty Geezer said:
I thought it shared the same ISA as the PPE. I sure that's what was said many moons ago. Dunno who by or when though.
It was probably a simple speculative comment, because I don't remember anyone saying that the SPE used the PPC ISA, actually I remember the opposite.

I recall this being said in some presentation..I think it might have been Mark Deloura in the GDC presentation but not sure.
 
The exact specification of the SPE’s ISA hasn’t been released yet but it appears to be a cross between VMX and the PS2’s Emotion Engine. It doesn’t contain the full VMX instruction set as some stuff was removed and other stuff added. According to IBM using a subset of the VMX “intrinsics†you can compile to both the SPEs and standard VMX, the only difference is the local stores. The actual code is different at the binary level so existing AltiVec / VMX code needs to be recompiled before it will run [CellLinux] .
http://www.blachford.info/computer/Cell/Cell3_v2.html
Here is a roundup of what is currently known of the SPE’s Instruction set (this should not be considered an exhaustive list):



Based on VMX / AltiVec - some instructions added, some removed.

Includes some (all?) of the PS2’s Emotion Engine ISA.

Supports vector or scalar operations.

Includes loads, stores, branches and branch hints.

8, 16, 32 and 64 bit integer operations.

Single and dual precision floating point.

Saturation arithmetic for FP (not integer).

Simplified rounding modes for single precision FP.

IEEE 754 support for double precision FP (not precise mode).

Logical operations.

Byte operations: Shuffle, Permute, Shift and Rotate (Shift / Rotate per Qword or slot).

128 x 128 bit Registers.

Local Store DMA I/O (to / from any address in system).

Commands for mailbox access, interrupts etc.
This is from a version 2 Cell documents, apparently uploaded 20th July. Perhaps this info isn't yet common knowledge.
 
Well, here's the relevent part from the Bergmann interview, since we're on ISA's now:

dW: How close to VMX instructions are the SPU instructions?

Bergmann: Some of the instructions are very similar; and the SPUs have some additional instructions that go far beyond what you can do with VMX. And there are a small number of instructions in VMX that don't have a counterpart on Cell. The biggest difference is that the SPUs don't actually use PowerPC instructions. The instruction format itself is different, even though the assembler or the C intrinsics might be very similar.

dW: So, are VMX opcodes and SPU opcodes the same? Will VMX optimized code have to be rewritten to take advantage of SPU?

Bergmann: Unlike VMX code, the SPU has a complete instruction set to execute self-contained binaries. The opcodes that are used are very different on the assembly level but can be used in similar ways from high-level languages.

dW: So then the compilers have to be rewritten to include the opcodes for the SPUs, is that correct?

Bergmann: Yes. We have a special GCC port, and you can have other compilers as well that are targeted at the SPU, instead of targeted at the host instruction set. So if you want to compile the program for the SPU, you need to use this cross-compiler.

Article
 
Back
Top