Talk:Cell (processor)/Archive 1

message: See above. Does the Cell have this? If so, to what extend? I am interested in this point but couldn't find it adressed. I think it's an important topic, and even if the Cell does not feature something like that, it should be mentioned somewhere. Thank you. Karoschne 23:25, 11 February 2006 (UTC)
thread_title: Power Saving Capability

message: There are a number of recent news articles on the web which claim the cell will be used in the PS3, as Sony originally intended. Unless we can find an official statement from Sony I will assume that the authors of those claims have gotten their info from a quick web search where the PS3 Cell claim can be found many places.  says clearly that cell will not be used in the PS3. Thue | talk 21:34, 10 Jul 2004 (UTC)
replies: text: I called Sony, and they say it will indeed use the Cell chip. Thue | talk 09:37, 21 Jul 2004 (UTC)
thread_title: Cell in the PS3

message: Can someone find a source on Cell, that says it lacks a dynamic brancher on the SPE subcores?
Answer: 
SPE and PPE are "in order" processing units. In order execution, typically means, no branch prediction. ~ Niall Sandy 11:53pm April 5, 2006
Answer #2: 
An in-order core tends not to support speculative execution, though many early processors would drop partially executed instructions on the floor to recover from a late detected fault of one kind or another.  There's no reason an in-order core can't predict branches dynamically to hint the instruction prefetch logic, without getting ahead of itself by executing those instructions prior to confirming whether the branch was taken/not-taken and correctly/incorrectly predicted.  However, the Cell SPUs do no such thing.  They support a branch hint mechanism under program control.  Because of the way that memory accesses take priority over instruction line fetches, a program with a very heavy stream of memory operations can starve instruction prefetch leading to a big stall when the instruction stream runs dry.  It's sometimes necessary for the program stream to issue an explicit ifetch cycle.  This was all in the reference which allowed me to deduce VMX floating point capabilities.  I also read something about the design of the IBM XL compiler out of Toronto I think with respect to automatic VMX/SPU code generation that touched on these subjects. MaxEnt 05:51, 9 April 2006 (UTC)
thread_title:  Dynamic Branching 

message: Ey e'rr body, im just really curious about the acronyms stated in the Acronyms section. can someone with a really big heart define them for me? the thing is, wikipedia uses REALLY big words that i cant really understand. so can someone break down these definitions for me? especially the SPE:
* EIB: Element Interconnect Bus [27]
* LS: Local Storage (SPE's local memory) [28]
* MIC: Memory Interface Controller [29]
* PPE: Power Processor Element [30]
* SPE: Synergistic Processing Element [31]
* SPU: Streaming Processor Unit [32]
* STI: Sony Computer Entertainment Inc., Toshiba Corp., IBM
thx in advance :D KittenKiller 04:31, 13 September 2005 (UTC)
thread_title:  The Acronyms 

message: I'm not an electrical engineer or anything, but is the Cell a 64-bit or 128-bit processor (think AMD Athlon 64-type bits)? Pardon the ignorance, I'm still learning.
:It's both.  When dealing with stream/vector processors (and stream processor look-alikes like Cell), it's somewhat useless to slap a general "bit width label" on the thing. -- uberpenguin 19:48, 26 October 2005 (UTC)
thread_title:  128-bit processor? 

message: IBM has suddenly started calling Cell "CBE" (or "Cell Broadband Engine," or "Cell BE" -- but never "Cell" alone). What is the policy on honoring the use of this kind of preference for one name over another from a corporation? Redirect ? :)
:: Cell is an generic name, used by Sony and the press. --Brazil4Linux 09:23, 28 November 2005 (UTC)
replies: text:  Actually, isn't that supposed to be BPA?  The PPC kernel fork that was written at IBM cites "Broadband Processor Architecture".  On the IBM site they say "CELL - also known as the Broadband Processor Architecture (BPA) - is an innovative solution whose design was based on the analysis of a broad range of workloads...." IBM --Trent Arms 06:36, 7 March 2006 (UTC)
thread_title:  it's not "Cell" it's "CBE" 

message: Near the beginning of the article it is mentioned that the PlayStation 3 will have 1 PPE clocked at 3.2 Ghz and 7 SPEs (six useable), also at 3.2 MHz. However, under Console videogames the chips are said to run at 2.0 GHz.
:The specified clockrate was increased on the design board sometime in 2005. Collabi 23:11, 5 April 2006 (UTC)
thread_title:  Conflict in PlayStation 3 Specifications 

message: The article states that "At 3.2 GHz, each SPE gives a theoretical 25.6 GFLOPS of performance".  This seems to directly contradict the previous statement that "An SPE can operate on ... 4 single precision floating-point numbers in a single clock cycle."  If an SPE can operate on 4 single precision floating point operations per cycle (presumably using a single SIMD instruction), then at 3.2 GHz, it's peak performance is 12.8 billion floating point operations per second (GFLOPS), not 25.6.  With double-precision floating point calculations, it would be 6.4 GFLOPS.
:The SPE can issue two instructions per clock, and has Odd / Even instruction pipelines.  The Even pipe handles basic integer / fp arithmetic, and the Odd pipe handles permute, load / store and branch instructions.  Thus, a maximum thoroughput of 25.6 GFLOPS, and a maximum arithmetic thoroughput of 12.8 billion per second.  Also, the double-precision units are not optimized like the single-precision units, so utilizing double-precision drops thoroughput by about 10x (estimated 1.28 billion arithmetic operations per second).  See this page on Real World Technologiesfor more details.--Defaultuser 18:50, 7 March 2006 (UTC)
replies: text: Highly technical IBM papers I've slogged through indirectly clarified floating point capabilities.  See my copious rantings below.  MaxEnt 18:57, 8 April 2006 (UTC)
replies: text: A single multiply-accumulate instruction is probably considered two "ops".  —Ryanrs 05:21, 9 May 2006 (UTC)
thread_title:  Floating Point Performance Claims 

message: I'm suprised no one has commented on the similarities between the 256kB local memory on the SPEs and program memory in a Harvard architecture - although not exactly the same thing part of the implementation is the same. Surely one of the (if not the main reason) reasons for having the SPE local memory is to reduce bandwidth usage to the main memory. Could this be worth inclusion in the text discussing the overall architecture? (possibly in 'architecture compared').
The article although reasonably good at the moment seems to give no real reason for Cell's choice of architecture - the data is there but the analysis is lacking. Does anyone agree?HappyVR 20:45, 13 March 2006 (UTC)
replies: text: Quite so.  I had been meaning to redo this article myself, but got distracted with other pursuits.  I doubt anybody would object to your reworking parts of it. -- uberpenguin 22:44, 13 March 2006 (UTC)
replies: text: On a second reading of this page I noticed that the article is quite/pretty good. Better than I originally thought - but it could do with 'redoing' for readability. Not an easy task given the amount of (new) technical stuff that needs to be got across.HappyVR 10:36, 14 March 2006 (UTC)

text: er yes - I've commented that out for deletion (or change if someone else wants to) - thanks for spotting that - I thought I'd changed that a long time ago.HappyVR 11:26, 14 May 2006 (UTC)
thread_title:  local memory 

message: From the document tagged pacellref I deduced the VMX single precision and double precision performance level.  Required careful reading to spot the key numbers which are given in aggregate for the octoSPUs + VMX.  
:Although the SPU double-precision (DP) floating-point is not as high as the single-precision performance, it is still good. Each SPU is capable of executing two DP instructions every seven cycles. With Fused-Multiply-Add, an SPU can achieve a peak 1.83GFLOPS at 3.2GHz. With eight SPUs and fully pipelined DP floating-point support in the PPE's VMX, the Cell BE is capable of a peak 21.03GFLOPS DP floating-point, compared to a peak of 230.4GFLOPS SP floating point.
This same document insists that the octoSPUs have a peak SP performance of 204.8GFLOPS (all figures quoted at 3.2GHz), subtracting this from 230.4 gives us 25.6 or eight SP operations per clock.  
The other subtraction works out to 1.997 DP operations per clock for the fully pipelined VMX.  I think we can safely round up.  
This doc. doesn't say if the VMX supports SP in IEEE 754 compliant mode and I don't read the PPE docs myself.  I'm a SPU man myself.  An important capability to note.  Anyone?  MaxEnt 06:51, 7 April 2006 (UTC)
replies: text: about vmx / ieee / single precision - see two sections down - the vmx are ieee compliant in single precision - (so i assume this is the standard no. 754 obviously).HappyVR 10:03, 8 April 2006 (UTC)
replies: text: This was clarified in discussions below.  The VMX supports a mode bit which enables Java-subset IEEE compliance in single prec. mode.  MaxEnt 19:00, 8 April 2006 (UTC)
thread_title:  Clarified PPE VMX capabilities 

message: I just had to add a section by that title.  The article pacellref also contains unique information regarding the EIB, including a diagram associating unit IDs to EIB participants, in ring order:  
:PPE=6, SPE1=7, SPE3=8, SPE5=9, SPE7=10, IOF1=11
:MIC=5, SPE0=4, SPE2=3, SPE4=2, SPE6=1, BIF/IOF2=0 
This might be too technical for the main article, but it does suggest that knocking out a failed SPE is not fully transparent in software.  
Cell Multiprocessor Communication Network: Built for Speed talks about the EIB in great depth (not added to refs section yet).  It clearly states that the maximum distance on each ring is six hops, so each physical SPE has a unique view of which other units it can send to on the CW vs CCW rings (which can be detected via concurrency conflicts).  
Anyone adding to the EIB portions needs to work through these two references, they paint a detailed picture, but not me tonight. MaxEnt 07:14, 7 April 2006 (UTC)
replies: text: It's a good point to make.  The place to make it, if possible, is where the PS3 Cell is described as having one of the eight SPUs disabled, since people are likely to assume this is more transparent than it is.  There will be subtle diffs from one Cell to another depending on which SPU is knocked out because of the rigid hop count semantics.  MaxEnt 19:02, 8 April 2006 (UTC)
thread_title:  Seven of Eight 

message: I've never worked with VMX, but I decided to chance wading through the VMX docs.  The doc I found does not define any double prec. operations.  Where are they?  I think it's useful to include this survey of differences because IBM has a nasty habit of adding up VMX and SPU floating point performance numbers as if the situation was far more symmetric than it really is.  It takes real work to make an algorithm perform well in both environments.  
I'm adding a lot of material helter skelter.  At some point, a larger review of content and org. will be needed. MaxEnt 08:42, 8 April 2006 (UTC)
replies: text: double precision are not there, you're right - funny - I'd got the impression that PPE VMX did double precision (I probably just assumed incorrectly) - also your table - as I see I as Java compliance is a sub set of IEEE compliance then both vmx and spe are ieee compliant - maybe the table should make it clear that VMX are ieee sp compliant or just comment that both are ieee compliant?HappyVR 10:03, 8 April 2006 (UTC)
replies: text: I haven't looked very hard yet for docs on the PPE side of the fence.  Maybe there's an extension published somewhere I haven't found yet.  In one of the paras below I define the Java and non-Java modes on the PPE side.  I could be more explicit about the non-IEEE and IEEE modes on the SPU side.  It's a battle to keep the table terse enough to read.  MaxEnt 10:19, 8 April 2006 (UTC)
thread_title:  Added the VMX to SPU comparison table 

message: There are typos, the description is unclear, and I suspect not all the figures provided are accurate.  I'll try to get back to this myself soon.  It overemphasizes the hop distance as a latency issue.  In fact, the speed is very high even in the cases with more hops between the endpoints.  The actual issue here is one of concurrency: with too many endpoints too far apart trying to talk at the same time, the EIB fails to achieve as much concurrency as it might if the hops were shorter.  MaxEnt 10:16, 8 April 2006 (UTC)
thread_title:  First pass EIB rewrite  

message: :I'm confronting a bit of an impasse to continue here.  I need to return to some of the other primary sources regarding the Cell architecture and experiment with the Cell simulator to see whether the "shared multiplier" effect creates artifacts visible in software.  The purpose of this exercise is to establish some clarity in my own mind about the exact dividing line between the implementation and the architectural specification, and which one is ultimately running the show.  A VLIW influence would be to have the archicture specify the execution environment.  A more conventional approach is to begin with an accessible implementation, generalize the properties that emerge into some architectural principles which the compiler writers, etc. can take as their foundation, and then hold to this model as long as practical as the underlying implementation technology evolves.  An interesting point of comparison right now is the upcoming ARM2 architecture which hybridizes the speed/density trade-off instead of forcing programmers (or the runtime) to ping-pong between two discrete models.  It could be a few days before I'm back again with more to contribute here.  MaxEnt 20:47, 6 April 2006 (UTC)
replies: text: Surely the answer is - there are no artifacts? (since is complies to a standard), still I'll be interested to see what the answer is. I think that a lot of people might be interested in 'number of clock cycles' for specific common instructions if you're interested.(Doesn't have to be an exhaustive list.) Also I have been able to easily find anything about register interlock between odd and even pipes - I assume that if say a floating point instr. is being carried out on the even pipe and the next instr. is say a 'load/store from/to memory/register' on the odd pipe that if same register is used then there is a conflict (without pipeline 'interlocking') - probably only worth mentioning if the behaviour is unusual or non-standard. Apologies if I've totally misunderstood the architecture and my comments are gibberish.HappyVR 21:36, 6 April 2006 (UTC)
replies: text: The kind of artifact I'm looking for is generally known as a hazard, little dark corners where the nicely documented world breaks down due to hidden implementation issues.  Instruction streams intercalating SP and DP instructions are not considered to be a common workload, so a hazard might emerge there if someone looks closely enough.  It seems to be implied by the IBM docs: if the multiplier is shared, it can't serve two masters at the same time.  The Intel P6 was rife with hazards.  If two many L1 reads hit the same L1 bank, there were strange delays.  And partial register stalls abound on the P6, particularly concerning the flags registers, but you could never figure this out because Intel had put special case logic in there to fast-path the ones that showed up most often on their design sim.  IBM did this with the EIB, too.  There is a fast-path provided in one case where the request queue is presently empty.  Any chip that results from an intensively simulation driven design is packed with hazards and anti-hazards of this nature.  MaxEnt 19:03, 7 April 2006 (UTC)
replies: text: Yes, clearly in the case of dp and sp instructions being carried out sequentially there might be (probably, or ay least longer execution time) a 'stall'. In the worst case (no 'interlocking' on the multiplier) the second instruction will 'overwrite' the first producing garbage - but as both instructions only have one (the same) pipeline (so one must finish before the other can start) this seems impossible - good luck anyway finding out. It seems that for best performance code should be written or compiled to attempt to use even and odd pipelines aternatively.HappyVR 19:25, 7 April 2006 (UTC)
replies: text: Absolutely there is in an interlock to prevent anything bad from happening.  Correctness of the results is non-negotiable.  If a hazard is detected, the execution pipeline will come to a grinding halt until the hazard clears and then things will resume normally.  The only visible effect will be a small (undocumented) delay (sometimes referred to as a bubble).  MaxEnt 19:09, 8 April 2006 (UTC)
thread_title:  Artifacts 

message: Half of what I wrote in the first rehash proved wrong.  Adding the essential quotes finally shed some light into the darkness.  There is still a lingering question about my use of the word hop.  I'm not sure I've ever seen that word used by IBM.  Once again the stuggle for basic accuracy has taken prominence over ideal structure from the readership perspective.  It's so darn hard to sift the conflicting information from the primary source (take a bow, IBM) there's not much mental capacity left for worrying about structure.  MaxEnt 12:17, 10 April 2006 (UTC)
thread_title: Second EIB rehash

message: Suggest changing this:
Quadword alignment is alignment on 16B boundaries where the low four address bits are zero.
to this:
Quadword (Four times 32bit word or 128bits) alignment is on 16Byte (128bit) boundarys.Or similar - wikipedia does not actually have a page for quadword. To make it clear that in this architecture a word is 32 bits.HappyVR 11:45, 8 April 2006 (UTC)
replies: text: I hate the term word since it generally means whatever we want it to mean.  Word in this case is 32 bits.  We shouldn't try to normify quadword usage within the wiki.  We just say that our source material defines quadword as 32 bits.  Something like this "IBM's VMX tech. defines a word as 32 bits and a quadword as 128 bits.  Quadword alignment implies alignment on 16B boundaries where the lower four bits are all zeros."  Give it a shot, I'm tired of it.  I encourage changes.  There will be many passes before we decide what works best.  MaxEnt 19:43, 8 April 2006 (UTC)
replies: text: ok changed the wording - I'm really looking for somewhere in the article to state clearly "In this architecture a word is defined as 32 bits" - perhaps putting "both PPE and SPEs use 32 bit length instructions - consequently in this architecture a word is defined as being 32 bits long." but whereHappyVR 20:23, 8 April 2006 (UTC)
replies: text: All the IBM/Sony manuals begin with a ten page blob of architectural defs that make my eyes water because I've seen 99% of it before 9999 times.  My vote is to quietly slip some normalized vocabulary into the VMX to SPU comparison table.  Keep the specialist terminology close to the ground.  We're not necessarily writing for people with spare mental buffers to carry around a lot of jargon.  Make it prominent enough to notice when it matters to the reader.  I'm going to make an edit to the table.  See what you think.  20:35, 8 April 2006 (UTC)
thread_title: Quadwords

message: In the section (2) Architecture, before section (2.1) Power Processing Element I want to insert a sub section 'overview'Couple of reasons - firstly I've noticed the article pretty much jumps straight in to the dirt - easy to miss this because most people coming here will already have a good idea what it's all about - however to the 'uninitiated' it will be confusing - they'd have to piece together the info. to find out what it is all about.Secondarily an overview might/should help to stitch together section 2 and also prevent having to repeat any concepts in the text.Thirdly if basic concepts are explained in 'overview' the subsections can jump right in with more detailed info.I think various things should be included:It's a 32bit architecturethe PPE is used as a controller/mediator/task organiser/master
The PPE is compatable with other power pc procs.
The SPEs have local memory, they act as slaves (do the heavy lifting , other metaphors)
The EIB connects the SPE and PPE and external buses
Other external buses connect to memory, serial devies etc
The registers (number length), word size, addressable memory etc.I would do this but I (too) am getting tired - maybe not today - or maybe someone else will do it first - either way it can wait for now. I assume that no-one would object to a slightly explanded introductory paragraph to section 2? or would a separate section be bettter?HappyVR 20:46, 8 April 2006 (UTC)
replies: text: I'm hugely in favour of sifting introductory concepts upward and maintaining accessibility against the onslaught of complexity.  We're faced with describing a dime store supercomputer.  Keep the ideas coming.  MaxEnt 22:43, 8 April 2006 (UTC)

text: Yes, thanks for all that - I was thinking about a similar analogy for the overview myself - coachman and eight horses - I'm still thinking about the wording of the overview - trying to avoid a description that is too simple whilst keeping it succint.However it seems there is a double precision problem to sort out first (see below).HappyVR 09:41, 9 April 2006 (UTC)
replies: text: I'm learning stuff from my coherency trawl that is changing my view.  The PPE threads are very clearly in charge of the view of system memory seen by each SPU and I've noticed IBM describe the relationship from PPE to SPU as offload several times now.  One doc also stated that the PPE has preemptive task switch ability over any running SPU.  If anything goes wrong with how a SPU DMA request tries to access the address space (including translation problems due to TLB miss, etc.) the PPE gets the interrupt to fix the problem.  I'm coming to the view that it's a legal guardianship of two PPE parents over eight SPU children, teenagers who are quite independent until they get into more trouble than they can handle themselves. MaxEnt 10:04, 9 April 2006 (UTC)

text: I hope we continue to work together on this.  Every time I edit for accuracy, I end up adding technical terms such as SIMD that might not have been properly introduced yet.  Once I say that PPE has 64 and 128 bit regs and SPU has only 128 bit regs, I really need to explain that the 128 bit SPU registers are flexible in support of both scalar and non-scalar (SIMD) data types.  It's good to tackle the bit-size question early so that the reader understands that the old concept of 32-bit proc or 64-bit proc is not so simple any more.  We now have 32-bit inst., 64 bit scalars, 64 bit pointers, 128 bit SIMD, etc.   Ugh, I just checked, the SPU also defines doubleword and quadword scalars.  Must fix.  MaxEnt 09:53, 10 April 2006 (UTC)
replies: text: I wouldn't worry about SIMD - I'll change any early instances of SIMD to SIMD so that readers can look it up themselves, and do the same to other technical terms or acronyms.HappyVR 10:16, 10 April 2006 (UTC)
thread_title: Overview

message: The bitness of an architecture used to mean either the address space or the register width.  In both cases the Cell would not be considered 32 bit.  I'm sure the PPC has a virtual address space far larger than 4GB.  Also, the general purpose register set in the PPC is mostly 64 bits now IINM, with special purpose registers of 128 bits.  The SPU is even more biased toward 128 bit reg width.  In scalar mode, the SPU functions as a 32-bit processor.  All we can say is that the architecture defines a word as 32 bits.  Power originated as a 32-bit arch, there's not much left of that now.  MaxEnt 22:43, 8 April 2006 (UTC)
thread_title: Bitness

message: Absolutely.  Binary compatible.  Caveat: because Cell lacks OOO, code compiled by compilers attempting to exploit OOO in hardware won't necessarily run well.  To run well, existing code needs to be recompiled with a compiler that correctly models the PPE's superscalar constraints.  Was Power 5 OOO?  I've never been much of a Power guy.  MaxEnt 22:43, 8 April 2006 (UTC)
thread_title: PPE compat

message: Local memory is the fundamental departure from conventional designs.  It ties into the distributed DMA controllers, EIB, multiprocessor coherence model, etc etc.  It's also what makes the Cell look more like a GPU internally.  
====PPE to SPU relationship====
Depicting the correct relationship (status hierarchy) between the PPE and the SPUs is tricky.  If the system runs an operating system, the OS itself almost certainly runs on the PPE threads.  The SPUs have no protection model (priv. modes).  The virtual memory model, processes, file system code, etc. is all going to run on the PPE side.  By this view, you would say the PPE is running the show.  The situation becomes more blury for a game console where the game takes over and the OS fades into the background for long periods of time.  In Linux and BSD, many OS tasks are handled behind the scenes with worker threads (of one variety or another).  The SPU processors are sufficiently powerful running in scalar mode that the PPE could delegate OS worker thread tasks to the SPU context.  Tasks such as running through VM page lists or lists of disk buffers deciding what to keep and what to flush and what to zero out for later.  A SPU processor could also handle network packet assembly and disassembly tasks.  Or the computations involved in handling software RAID.  In fact, these applications all resemble the GPU.  High end network cards and disk controllers have long contained coprocessors designed to offload these computations from the main OS.  The SPU is unlikely to become involved in deciding which task to schedule next.  Those portions of the OS are extremely branchy in nature.  And the PPE also ends up doing some heavy lifting of its own: any Altivec kernel that requires Java semantics, or fast double precision.  
====Gone to the dogs====
Maybe the right image is a dog team that consists of a border collie and eight huskies.  Huskies aren't dumb animals, but there some things you can train a border collie to do that a husky would never be good at.  Likewise, a border collie is a hard working dog, but doesn't have the strength or stamina to pull a heavy sled through deep snow.  Both animals are general purpose work dogs, yet you have to use them differently to get your kibble's worth.  Likewise, while the collie excels at agility (hard turns) it lacks the crunching power of an Opteron (bulldog) or straight ahead speed of a Pentium IV (greyhound).  Actually the PPE is more like a pair of downsized herd dogs: perhaps the Welsh corgi.  IBM would like people to think of Cell as two bordier collies heading eight huskies.  On a bad day I might describe the Cell as consisting of two fast-footed corgis up front and eight single-minded scent-crazy beagles bringing up the rear.  In any case, the point is that the relationship is not easy to depict in role-bound terminology.  MaxEnt 22:43, 8 April 2006 (UTC)
replies: text: Yes, thanks for all that - I was thinking about a similar analogy for the overview myself - coachman and eight horses - I'm still thinking about the wording of the overview - trying to avoid a description that is too simple whilst keeping it succint.However it seems there is a double precision problem to sort out first (see below).HappyVR 09:41, 9 April 2006 (UTC)
replies: text: I'm learning stuff from my coherency trawl that is changing my view.  The PPE threads are very clearly in charge of the view of system memory seen by each SPU and I've noticed IBM describe the relationship from PPE to SPU as offload several times now.  One doc also stated that the PPE has preemptive task switch ability over any running SPU.  If anything goes wrong with how a SPU DMA request tries to access the address space (including translation problems due to TLB miss, etc.) the PPE gets the interrupt to fix the problem.  I'm coming to the view that it's a legal guardianship of two PPE parents over eight SPU children, teenagers who are quite independent until they get into more trouble than they can handle themselves. MaxEnt 10:04, 9 April 2006 (UTC)

text: I hope we continue to work together on this.  Every time I edit for accuracy, I end up adding technical terms such as SIMD that might not have been properly introduced yet.  Once I say that PPE has 64 and 128 bit regs and SPU has only 128 bit regs, I really need to explain that the 128 bit SPU registers are flexible in support of both scalar and non-scalar (SIMD) data types.  It's good to tackle the bit-size question early so that the reader understands that the old concept of 32-bit proc or 64-bit proc is not so simple any more.  We now have 32-bit inst., 64 bit scalars, 64 bit pointers, 128 bit SIMD, etc.   Ugh, I just checked, the SPU also defines doubleword and quadword scalars.  Must fix.  MaxEnt 09:53, 10 April 2006 (UTC)
replies: text: I wouldn't worry about SIMD - I'll change any early instances of SIMD to SIMD so that readers can look it up themselves, and do the same to other technical terms or acronyms.HappyVR 10:16, 10 April 2006 (UTC)
thread_title: SPE local memory

message: Maybe the right image is a dog team that consists of a border collie and eight huskies.  Huskies aren't dumb animals, but there some things you can train a border collie to do that a husky would never be good at.  Likewise, a border collie is a hard working dog, but doesn't have the strength or stamina to pull a heavy sled through deep snow.  Both animals are general purpose work dogs, yet you have to use them differently to get your kibble's worth.  Likewise, while the collie excels at agility (hard turns) it lacks the crunching power of an Opteron (bulldog) or straight ahead speed of a Pentium IV (greyhound).  Actually the PPE is more like a pair of downsized herd dogs: perhaps the Welsh corgi.  IBM would like people to think of Cell as two bordier collies heading eight huskies.  On a bad day I might describe the Cell as consisting of two fast-footed corgis up front and eight single-minded scent-crazy beagles bringing up the rear.  In any case, the point is that the relationship is not easy to depict in role-bound terminology.  MaxEnt 22:43, 8 April 2006 (UTC)
replies: text: Yes, thanks for all that - I was thinking about a similar analogy for the overview myself - coachman and eight horses - I'm still thinking about the wording of the overview - trying to avoid a description that is too simple whilst keeping it succint.However it seems there is a double precision problem to sort out first (see below).HappyVR 09:41, 9 April 2006 (UTC)
replies: text: I'm learning stuff from my coherency trawl that is changing my view.  The PPE threads are very clearly in charge of the view of system memory seen by each SPU and I've noticed IBM describe the relationship from PPE to SPU as offload several times now.  One doc also stated that the PPE has preemptive task switch ability over any running SPU.  If anything goes wrong with how a SPU DMA request tries to access the address space (including translation problems due to TLB miss, etc.) the PPE gets the interrupt to fix the problem.  I'm coming to the view that it's a legal guardianship of two PPE parents over eight SPU children, teenagers who are quite independent until they get into more trouble than they can handle themselves. MaxEnt 10:04, 9 April 2006 (UTC)

text: I hope we continue to work together on this.  Every time I edit for accuracy, I end up adding technical terms such as SIMD that might not have been properly introduced yet.  Once I say that PPE has 64 and 128 bit regs and SPU has only 128 bit regs, I really need to explain that the 128 bit SPU registers are flexible in support of both scalar and non-scalar (SIMD) data types.  It's good to tackle the bit-size question early so that the reader understands that the old concept of 32-bit proc or 64-bit proc is not so simple any more.  We now have 32-bit inst., 64 bit scalars, 64 bit pointers, 128 bit SIMD, etc.   Ugh, I just checked, the SPU also defines doubleword and quadword scalars.  Must fix.  MaxEnt 09:53, 10 April 2006 (UTC)
replies: text: I wouldn't worry about SIMD - I'll change any early instances of SIMD to SIMD so that readers can look it up themselves, and do the same to other technical terms or acronyms.HappyVR 10:16, 10 April 2006 (UTC)
thread_title: Gone to the dogs

message: There is so much to clean up, but I wanted dig into the cohernecy model before I take my next cut.  
* http://www-128.ibm.com/developerworks/power/library/pa-celldmas/
:The MFC also contains an atomic unit (ATO), which performs atomic DMA updates for synchronization between software running on various SPEs and the PPE. Atomic DMA commands are similar to PowerPC locking primitives (lwarx/stwcx).
This is a meaty sidebar: 
:The Cell BE processor -- on the other hand -- is a 64-bit processor similar to the PowerPC 970 and uses neither BATs nor segment registers. It uses Segment Lookaside Buffers (SLBs) and page tables for its address translation mechanism. There are 64 entries in the Cell BE SLB, and they form part of the process' context. SLB entries map the effective address of process address space to virtual address. Each SLB entry maps a 256MB effective address region, and so 16GB of address space of a process can be mapped at once. If a process address space is greater than 16GB, and if a particular effective address range of the currently running process is not mapped in the SLB, then DSFI/ISFI exceptions are generated. The OS should resolve this by filling in the correct entry in the SLB and replacing the suitable entry. In this way address space > 16GB can be effectively mapped using SLBs.
More vitals from the main text: 
: The MFC's MMU unit consists of the following:
:* Segment Lookaside Buffer (SLB) (managed through memory mapped input output (MMIO) registers)
:* Translation Lookaside Buffers (TLBs) to cache the DMA page table entries (option for hardware reload from page table or software loading through MMIO registers)
:* Storage Descriptor Register (SDR) which contains the DMA page table pointer (standard hashed PowerPC page table format)
:The architectures allow the PPE and all of the MFCs to share a common page table, which enables the application to use their effective addresses directly in DMA operations without any need to locate the real address pages. 
System Memory Map: 
:The Cell BE processor's system memory map consists of six distinct regions, namely SPE local store area, SPE privileged area, PPE core area, IIC (Interrupt controller area), PMD (Power Management and Debug) area, and Implementation Dependant Expansion Area (IDEA).
* http://www.crest.gatech.edu/conferences/cases2005/pdf/Cell-tutorial.pdf
p.23 corrects a mistake I made describing peak EIB bandwidth.  The 204.8 GB/s figure is peak bandwidth as seen by eight SPU processors; there are four other EIB participants that can increase this by another 50%.  
*Each SPU has an AUC which acts as a "4 line cache for shared memory atomic update" 
*BIC stands for Broadband Interface Controller 
*IOF1 is diagrammed as supporting a south bridge 
*IIC is internal interrupt controller; duplicated for each PPE hardward thread 
*IOT is I/O Bus Master Translation: bus addresses to system real addresses, two levels (256MB I/O segments; 4K,64K,1M,16M I/O pages)
*IOST cache: segment table I believe HW/SW managed
*IOPT cache: page table* I believe also HW/SW managed 
*RAG is "resource allocation group" 
*LPAR can't figure out
*RT tasks?  can't figure out
*access tokens generated at configurable rate for each alloc. group: 1 per mem bank (x16), 2 per IOIF (x2) 
*MIC does not get a RAG, but each SPE, the PPE, and both IOIF do (11 total) 
*resource overcommit interrupt 
*more than 100 outstanding DMA requests supported 
*HW or SW TLB management (that's not what the other link seems to say) 
*SPE MMU similar to PowerPC MMU: 8 SLBs, 256 TLBs, multiple page sizes, SW/HW page table walk, PT/SLB misses interrupt PPE
*isolation mode support (ick pooh) 
*PPE threads alternate fetch / dispatch cycles 
*p.36 shows the PPU execution pipes: 2 ops/cycle issue to load/store(1), fixed point(1), branch(1), and VMX/FPU queue(2)
*VMX/FPU issue queue: 2 ops/cycle to VMX load/store(1), VMX arith/logic(1), FPU arith/logic(1), FPU load/store(1)
*numbers in parens is number of ops that can be accepted by unit in one cycle
*"exploit all of Cell's 18 asynchronous engines"
  
MaxEnt 08:20, 9 April 2006 (UTC)
thread_title: Coherency

message: Posted April 18, interview with Mark Nutter and Max Aguilar: 
* http://www-128.ibm.com/developerworks/power/library/pa-fiveaguilarnutter/
Confirms my emphasis on the DMA view of system memory.  Here are the vital comments to work into the main text: 
* For reference, you may want to look at the MMU description for the SPEs, because that's the important piece, choosing, again, the same address translation machinery and storage protection machinery that the PowerPC core uses. They are fully PowerPC [ISA] compliant, so when you issue MFC/DMAs, it steps through the same address translation and protection mechanism that the PowerPC core steps through.
* Now if we take and we start with, say, the PowerPC Architecture Book III and we look at that memory model from there, where do we go differently with the Cell BE processor? So that's where to look to define the address translation model.  
* We really don't advise people to memory map local store into the PPE's effective address space
* You recommend going with the DMA?  Aguilar: Yes. The DMA is definitely the way you want to transfer, because when you access the local store it's done through MMIO, very slow compared to the MFC/DMA.  dW: That's a big clarification, that the recommended approach is using the DMA approach as opposed to the global memory mapping.
* Let's consider for a moment an application that might need to copy the content to the local store from the PPE side. One way it could do that would be to call memcpy on that memory map local storage area, and essentially copy all 256 kilobytes with any other anonymous memory chunk in the system. That would be very slow relative to the DMA engine. It would have, potentially, various side effects -- depending on the memory target where you were copying to, it would potentially displace contents of the L2, and so on. So every load and store to an MMIO region is something to be avoided, if you can do it, and certainly to avoid 256 kilobytes worth of that.
* Yes. As we mentioned before, MFC/DMA commands targeting effectively addressed memory go through address translation and protection. This is true both for accesses to regular memory and for accesses to memory-mapped I/O. MFC/DMA commands targeting another SPU's local storage area are just like any other memory access, from the MMU's point of view.
* With the GCC toolchain, what abstractions does it support out of the box?  Aguilar: It's a low-level compiler, in the sense that it compiles to the SPU or to the PPE ISA, but it doesn't do any of the higher-level abstraction or tying together of the programming model.  MaxEnt 20:41, 19 April 2006 (UTC)
thread_title: Hot New Interview about PPU

message: Added an overview - it almost certainly will need at least a bit of work later to improve readabilty etc.
My aim was to introduce the concepts (and some of the acronyms) used in the proc. as well as giving a rough idea of what it is intended for.
This should make it easier for later sections to get right down and start explaining more 'meat, skin and bones' concepts. As a result there may now be a few minor duplications in the text. I'll be coming back and reading through the entire thing slowly in an attempt ot check for this sort of thing. Hopefully it's ok for now.HappyVR 11:39, 9 April 2006 (UTC)
replies: text: Your change of the expression not autonomous initially to not fully autonomous is subtle.  It depends on what you mean by fully and when you ask.  As I was reading about the coherence model it was made extremely clear that the SPE units are helpless until the PPE sets up the view of memory, privilege model, and task assignments before kicking things off.  At this point, depending on how the PPE elected to set up the SPE units, they can be viewed as almost fully autonomous, or greatly codependent.  It's possible to create a software model where the PPE never touches an SPE again.  The SPE units are quite capable of pulling tasks off a global task queue themselves, obtaining the code and data, grinding away, then delivering the result to a global completion queue; the PPE might then pick up a signal via some autonomous synch. primitive that the work queue has new results.  That might be full extent of how much the PPE pays attention to the SPE units after system initialization phase.  In other models, it might become almost a full-time job for the PPE threads to respond to management events generated by the helpless SPE units; they can't, for example, manage faults originating from their own TLB or page-tables.  The two wordings convey different truths.  I like the other changes you've made that I looked at first.  MaxEnt 05:50, 10 April 2006 (UTC)
replies: text: Yes, it's not 100% clear, I'll try to find a way to reword to make the 'slave' status of the SPEs more clear. Perhaps something like 'although the SPEs are completely functional microprocessors they require the PPE to ..(make them do work)..' I'll try to get back to this and try to construct a better sentence.HappyVR 08:35, 10 April 2006 (UTC)
replies: text: That's a good direction to take.  I was thinking about this.  The level of supervision is largely determined by the process priv. model.  If the SPU processors are working in offload mode slurping away at OS internal work queues all tasks with the same view of memory and the same effective priv. level, the SPU processors can run largely unsupervised.  However, if untrusted user code must execute on a SPU, the PPE must do some work to set up the appropriate user process view of memory and enforce other OS protection mechanisms.  This is quite fundamental.  IBM states repeatedly in the docs that the SPU has no priv. modes.  The PPE is entirely responsible for setting up an appropriate view of memory for the level of priv. of the process offloaded.  Also, now that I'm looking for it I see IBM using the word 'offload' in many diff. docs.  The diff. is that offloading an OS internal work queue can feed a SPU forever, whereas offloading non-priv. code from userland the offloading step involves the PPE every time.  MaxEnt 09:33, 10 April 2006 (UTC)

text: Agree, I assume that the PPE 'threads' have individual decode and execute units as well as having separate 'maths' units?: (" While early superscalar CPUs would have two ALUs and a single FPU, a modern design like the PowerPC 970 include four ALUs and two FPUs, as well as two SIMD units" from superscalar).But the register set is shared.. (again assume). And the threads 'take turns' due to it being impossible for both to access memory etc.Documentation on the PPE (in a specific CBEA arch.) is a bit difficult to find - all I have (in short) is that the PPE must comply to Books 1-3 of Power 'standards' that it must have the 64bit implementation and also must have various extra maths instr. If I could assume that PPE is identical to say a PowerPC 970 (plus extra cell specific intsr.) then it would be a lot easier to expand the 'Power Processing Element' sub section.HappyVR 08:25, 10 April 2006 (UTC)

text: That's another good change: In documentation relating to Cell a word is always taken to mean 32 bits.  But again, the para in front of your edit is weak.  I'll clean that up now.  MaxEnt 07:57, 10 April 2006 (UTC)
replies: text: Yes - looking again the 16TiB was my mistake - it WAS meant to be the same as 2^64. I too am finding it difficult to find exact info on address range limit - definately I've not seen any thing above 2^64 - think the PPE is 2^62 (contiguous) up to 2^64 total from one of the refs. in the article. (No 64bit scalar in SPE either - I remember looking a long time ago and being dissapointed by it's absence).The edits are good - it's improved.HappyVR 09:43, 10 April 2006 (UTC)

text: I'm not sure about introducing the division of SPEs in to SPUs  and other functional elements in the overview. Would suggest keeping it all under the blanket term SPE. Also would suggest moving: " Note that the SPU processor can not directly access system memory; the 64-bit memory addresses formed by the SPU must be passed from the SPU processor to the SPE memory flow controller (MFC) to set up a DMA operation within the system address space."to the SPE section as it is a bit technical - the overview should address this issue though.HappyVR 10:16, 10 April 2006 (UTC)
replies: text: It's not entirely our choice.  Despite the terms bearing a superficial resemblence, the SPU is a processor core and the SPE is a fully-fledged EIB participant; the SPU has no direct view of system memory, whereas the SPE contains an asynch. DMA controller; etc, etc.  We need to say: IBM has somewhat confusingly nested similar accronyms.  The same problem exists with PPE threads vs PPE cores.  I'm thinking about added a preamble to the overview concerning the most egregious terminology.  MaxEnt 02:47, 11 April 2006 (UTC)
replies: text: an SPU is part of the SPE though, I thought it might be best to try to keep the overview couched in terms of SPE, PPE, buses and leave any breakdown of SPE into component parts for later sections.HappyVR 19:45, 11 April 2006 (UTC)

text: I've made the edits I suugested in the paragraph above. I will if possible try to add something to overview to cover main memory access method for SPEs. Possibilty something about there being an added 'abstraction layer' between SPEs and memory - will need to read a bit more about this before I can do it. Clearly SPE main memory access appears not to be similar to say 'typical common processor method'.HappyVR 15:43, 10 April 2006 (UTC)
thread_title: Overview

message: ::I'm not sure about introducing the division of SPEs in to SPUs  and other functional elements in the overview. Would suggest keeping it all under the blanket term SPE. Also would suggest moving: " Note that the SPU processor can not directly access system memory; the 64-bit memory addresses formed by the SPU must be passed from the SPU processor to the SPE memory flow controller (MFC) to set up a DMA operation within the system address space."to the SPE section as it is a bit technical - the overview should address this issue though.HappyVR 10:16, 10 April 2006 (UTC)
replies: text: It's not entirely our choice.  Despite the terms bearing a superficial resemblence, the SPU is a processor core and the SPE is a fully-fledged EIB participant; the SPU has no direct view of system memory, whereas the SPE contains an asynch. DMA controller; etc, etc.  We need to say: IBM has somewhat confusingly nested similar accronyms.  The same problem exists with PPE threads vs PPE cores.  I'm thinking about added a preamble to the overview concerning the most egregious terminology.  MaxEnt 02:47, 11 April 2006 (UTC)
replies: text: an SPU is part of the SPE though, I thought it might be best to try to keep the overview couched in terms of SPE, PPE, buses and leave any breakdown of SPE into component parts for later sections.HappyVR 19:45, 11 April 2006 (UTC)
replies: text: I've made the edits I suugested in the paragraph above. I will if possible try to add something to overview to cover main memory access method for SPEs. Possibilty something about there being an added 'abstraction layer' between SPEs and memory - will need to read a bit more about this before I can do it. Clearly SPE main memory access appears not to be similar to say 'typical common processor method'.HappyVR 15:43, 10 April 2006 (UTC)
thread_title: SPE vs SPU

message: I found more information about the EIB last night, including this patent: 
:*http://www.freepatentsonline.com/6779049.html
It's quite clear that what I said in the section above (in answer to your Harvard question) that my comments strike at the heart of IBM's original thinking about how to meld a GPU into a general-purpose offload cluster.  
The text of the patent is explicitly about managing remote TLB caches associated with DMA engines in a plurality of processing elements.  It talks explicitly about the advantage for the GPU in not having to do TLB lookups working within local store data structures.  I want to add patents to the references at some point.  
I also found a reference which clearly states the that the IBM includes an address concentrator designed in a tree structure.  Soon I'll have to come back and do EIB version 3. MaxEnt 13:43, 11 April 2006 (UTC)
replies: text: Added section about this patent, first draft.  Needs clean-up and links still.  MaxEnt 13:14, 12 April 2006 (UTC)
thread_title: TLB / DMA Patent

message: Just remembered something - SPEs use ieee standard single precision floating point storage data format - but apparently due not conform to ieee 754 standards in terms of 'numerical precision' - ie the data format is the same but calculations may not give exactly the same result as the ieee standard (havent found what exactly the difference is) - this is mentioned in cbe documentation itself - probably should add a minor note once I've convinced myself that this is right.HappyVR 19:40, 11 April 2006 (UTC)
replies: text: IEEE compliance has to do with esoteric details such as rounding modes, underflow, overflow, infinities, and invalid results.  It introduces some strange values such as -infinity, +infinity, -0, +0, and NAN (not a number); there are some strange rules about these strange quantities such as -infinity + -infinity = -infinity, but -infinity + +infinity = NAN (or worse).  I'm just going from memory here.  There are very complicated reasons why these conventions make sense.  For representation, the issue that sometimes shows up is how denormals are handled.  I've forgotten everything else I once knew.  MaxEnt 13:13, 12 April 2006 (UTC)
thread_title: ieee fp

message: Well, it's quite apparent I just added quite a lot of new material concerning IBM's patents related to Cell technology.  This kind of material can be quite dry to explain, so I supplied a certain "raising of the eyebrows" at junctures where that seemed like an appropriate response.  I was quite careful not to pass judgement on the validity or merit of the patents themselves, or to veer into a tone potentially construed as a legal interpretation.  I attempted to stress the angle of how IBM viewed the patent in the context of Cell wherever possible.  I suppose my own POV is that the bad patents do more damage than the good patents are worth; I'm undecided to what extent the patent system could be fixed.  I'm far from holding the view that IBM has any nefarious purpose in obtaining these patents.  If they don't, they expose themselves to risk from competitors who do.  The patent I most respected was the multiple DMA queue synchronization patent.    The patent I least respected was the vector permute function inter. patent.  Do they want us to use this chip, or waste our lives covering our backsides in patent research?  The patent that made me laugh was the vector/scalar subpath patent.  I guess a doctoral degree from Caltech is not worth what it used to be: when you leave the room, turn out the lights.  Claim 1: method where the light switch is deactivated.  Claim 2: method where the bulb is removed from socket.  Claim 3: method where bulb is smashed with slingshot.  Claim 4: method where nearby power pole is struck by car.  Maybe turning out the lights is a novel idea to the eggheads who study there.  Was my text too POV?  Let me know. MaxEnt 20:16, 12 April 2006 (UTC)
replies: text: I meant to also comment on formatting.  I've put the portions quoted from the patents (average of about four sentences per patent) into bold type.  Otherwise the text is just a long sequence of uniform blobs with nothing distinctive for the eye to grab onto.  At least with this formatting the eye can run down the page looking for a favorite keyword to decide where to jump in, or not to jump in, as the case may be. Most often I've quoted a statement of sentiment about the problem IBM set out to solve as they expressed it to the patent office.  I also quoted the passage about deactivating element IDs as this pertains directly to a high level attribute: the missing SPEs on consumer grade chips.  I deliberately chose many of the patents dealing with the DMA structure as I view this as being central to Cell's conception.  Other patents were selected to reflect a variety of perspectives. MaxEnt 20:31, 12 April 2006 (UTC)
thread_title: Patents

message: I've accomplished my initial goals here for now.  I would have liked to contribute a section on the coherency model, but it was impossible to work from IBM's descriptive material without writing code for the Cell simulator, so I settled for the patent analysis instead.  I'll keep an eye on the discussion page but it could be a week or a month before I'm actively contributing again.  MaxEnt 09:27, 13 April 2006 (UTC)
thread_title: Enough for now

message: I or someone else should edit this "The IBM PPE Vector/SIMD manual does not define operations for double precision floating point, though IBM has published material implying certain double precision performance numbers associated with the Cell PPE VMX technology."to read something like - the PPE double precision performance numbers are ..., these operations are not performed by the VMX SIMD unit but are implemented in the Power instruction set 'core' ie they are there but are not classed as VMX SIMD instructions - definately not SIMD anyway.?HappyVR 19:17, 13 April 2006 (UTC)
replies: text: We don't know this.  The old G5-centric VMX docs. don't necessarily reveal all features of the Cell VMX.  The double performance numbers cited for the PPE threads and SPEs in aggregate imply one double precision mul-add per PPE clock (counting both threads together).  We know that the VMX unit was enhanced between DD1 and DD2.  One scenario is that the PPE core contains one fully pipelined double prec. mul-add which is shared between both threads, and also shared between the FP execution pipe and the VMX execution pipe.  For the VMX pipe with a pair of double prec. values, the mul-add unit would be used twice and take an extra clock cycle to complete a pair of mul-adds.  It's also possible that there are two double prec mul-add units which each accept a new double prec. mul-add every second clock cycle.  The fmul instruction on the Pentium Pro was pipelined to accept a new instruction every two cycles; while the fadd was pipelined to take a new instruction on every cycle.  It's also possible that each PPE thread running double prec. SIMD floating point can only bind the FP execution unit on alternate clock cycles, meaning that the two threads would not contend for this resource.  However, that would mean achieving peak performance would require both PPE threads to be engaged in an FP intensive loop at the same time.  If I were IBM, I would have added SIMD double to VMX and pipelined it to use a single double prec. mul-add unit twice.  Then it only takes one PPE thread to achieve 6.4 GFLOPS, leaving the other PPE thread free to handle overhead (interrupts, etc).  In this model, if both PPE processors tried to run VMX double prec. they would each stall out half the time; less transparent, but better results if used judiciously.  You are trying to read too much from IBM's failure to issue an updated Cell-centric VMX specification.  MaxEnt 04:21, 14 April 2006 (UTC)
replies: text: I assumed fp figure for ppe was a result of a non-VMX extension PPE instruction - if so possiblity of two double precision fp units per PPE?HappyVR 09:33, 14 April 2006 (UTC)
replies: text: It's possible to get this performance from a single DP unit if the unit is fully pipelined to handle a mul-add on every clock cycle.  This is the cheapest approach for IBM in terms of silicon area, but perhaps this level of pipelining is hard to achieve for freq. reasons.  If so, IBM might have included two execution units that are pipelined to accept a new operation every second clock cycle.  Simpler to achieve in the freq. domain, but consumes more silicon area; the two unit design might also alleviate hot spots.   Whether this unit(s) is/are available as part of the regular Power 970 floating point instruction set, or as part of an extended VMX instruction set, or both, is not yet clear to me from any source I've uncovered.  I haven't done much coding on the PEE side, so I could have a big hole is the reference set I've consulted.  My vote is one fully-pipelined unit accessible from either instruction set with contention effects if both threads go after it at the same time, but we are not here to vote, are we?  It's possible that "fully pipelined" precisely means a new operand every clock cycle.  MaxEnt 10:19, 14 April 2006 (UTC)
thread_title: PPE double precision

message: I finally found a good reference for this searching on the term "VSU" which I noticed in a diagram:  
* http://www.research.ibm.com/journal/rd/494/kahle.html
The VSU floating-point execution unit consists of a 32- by 64-bit register file per thread, as well as a ten-stage double-precision pipeline. The VSU vector execution units are organized around a 128-bit dataflow. The vector unit contains four subunits: simple, complex, permute, and single-precision floating point. There is a 32-entry by 128-bit vector register file per thread, and all instructions are 128-bit SIMD with varying element width (2 × 64-bit, 4 × 32-bit, 8 × 16-bit, 16 × 8-bit, and 128 × 1-bit).
The model seems to be a three operand scalar mul-add every clock cycle.  Since each thread only dispatches on alternate clock cycles, each PPU thread achieves 3.2 DP GFLOPS, for 6.4 GFLOPS combined (as we know from another source).  
I'll have more material for the main article soon. MaxEnt 04:15, 20 April 2006 (UTC)
thread_title:  VSU Execution Unit 

message: I reverted the confusing attribute which came from a masquaraded IP address at the U of Singapore with no justification here in the talk page.  I agree that the article could be clarified, but the technology is complex and it's not a simple matter to obtain clarity. Help pinpointing the greatest sources of confusion would be appreciated, a ugly banner is not. MaxEnt 02:14, 2 June 2006 (UTC)
thread_title:  revert confusing 

message: In anticipation of this, I first moved the existing talk page to Achive-1.  
At this point I don't have any fixed ideas about how to best proceed.  I'm merely aware that the existing article has a number of defects that need to be somehow addressed, and I have certain intentions to add new content that won't help matters while the article remains in its present form.  
I don't wish to tackle all the issues all at once.  First, a general survey of what I see as the big fish.  
=== citation system === 
The good side is that there are lots of citations, references and links.  The bad side is that the article has sprouted no end of unsourced statements.  In my own contributions I wasn't careful to expose my citations, I tended to hide them inline as HTML comments until I could attack this problem more systematically.  
I've looked at all the Wikipedia citation methods, and none of them are issue free.  My own opinion is that the new cite.php method which inlines the citations is a bad direction.  I feel the overall framework could be salvaged with a version 2 rewrite, more along the lines of one of the bioinformatics citation systems I once saw, which it already partially resembles.  
The existing ref|note system works fine for shorter articles, but not so great for articles of the present length, and the numbering system sometimes conflicts with other things such as footnotes, if those are employed.  
Given a choice, for the more technical material, where I'm primarily citing IBM design engineers, I would lean toward the Harvard referencing style, which I find the most easy to verify and maintain while reading the text in article format; I also feel it handles a large body of references much better than the ref|note system.  
One possibility is that this article should be split, leaving the main article to keep the existing style while freeing the more technical sub-articles to adopt Harvard style.  
=== comprehension ===
Cell is a complex topic.  I tend to feel a core article is required that tries to remain light on the jargon (EIB, coherent interconnect, DMA controller, etc.) while presenting a servicable overview.  
Note that the Cell microprocessor is conceptually distinct from the Cell BE architecture.  This follows the model X86 architecture as distinct from derivative devices such as Intel 80486 or Pentium.  A first cut at improving comprehensibility would be to slice off some of the technical description of Cell as a architecture, since that is not what most casual readers are intending to pursue: they mostly wish to find out about Cell the commercial phenomena.  
I sense a third distinct article will be required to cover Cell software development methologies.  An example of this is the "porting VMX to SPU" text that I added to the main article somewhat prematurely.  There's so much more that could be said on this subject esp. pertaining the unnatural supervisory relationship between the PPE and SPE cores, the coherent DMA controllers, and how to cope with that mess.  
=== subdivision ===
I already opened this subject under comprehension because I feel that is the primary driving force in shaping the main article.  Finding natural cleavage points to simplify life for the expositors (myself among them) is secondary.  
From my present vantage point, I would probably begin by introducing a split into these three titles:  
*Cell microprocessor - the overview and device specific material 
*Cell Broadband Engine Architecture - heavy on engineering 
*Cell BE development - heavy on software development 
I chose those titles not to confuse people looking for Cell biology.  
I'll leave it off here for tonight.  Does anyone have any observations about whether this will work or not work?  More sections?  Fewer sections?  Different emphasis?  Exactly where to cut?  Please make your views known.  MaxEnt 07:54, 7 June 2006 (UTC)
thread_title:  Major Rework Proposed 

message: I already opened this subject under comprehension because I feel that is the primary driving force in shaping the main article.  Finding natural cleavage points to simplify life for the expositors (myself among them) is secondary.  
From my present vantage point, I would probably begin by introducing a split into these three titles:  
*Cell microprocessor - the overview and device specific material 
*Cell Broadband Engine Architecture - heavy on engineering 
*Cell BE development - heavy on software development 
I chose those titles not to confuse people looking for Cell biology.  
I'll leave it off here for tonight.  Does anyone have any observations about whether this will work or not work?  More sections?  Fewer sections?  Different emphasis?  Exactly where to cut?  Please make your views known.  MaxEnt 07:54, 7 June 2006 (UTC)
thread_title:  subdivision 

message: First, I familiarized myself with Wikipedia:Summary style and considered some other issues in choosing good names, and also found one about how to break up a long article in sub-articles.  
Then I started to mock up a possible approach.  Created :category:Cell BE architecture and then modeled a navbar after the one in Isaac Newton, and mocked up some text in the podlet articles.  
The sw-dev podlet could at some point split in a separate Linux on Cell article, but I think it would be best for now to keep all the development concerns in one place until it gets large enough, if that happens, to spill over.  
I'll be starting soon to move large blocks of text out of the main article into the corresponding podlets.  Any suggestions about where to draw the scalpel are welcome.  MaxEnt 23:29, 9 June 2006 (UTC)
thread_title:  subarticle navbar mockup 

message: * first reduction complete 
The main purpose thus far was to reduce the overall size of the main article and align it better with the topics designation for subarticle.  Much remains to be done.  MaxEnt 06:41, 10 June 2006 (UTC)
thread_title:  fat reduction and restructure 

message: It's hard to dial-in to the major fault lines without cleaning up the text as it already exists.  Note that the MIMD passage that bothered me so much was actually in the stream processing article, not here, as I realised again later.  MaxEnt 00:39, 12 June 2006 (UTC)
thread_title: Heavy copyedits history and overview

message: I liked the content I introduced into the lede a week ago, but the wording was a little heavy and the resulting text too blocky to read comfortably.  I split some sentences and paragraphs, added more intralinks, and fixed a bad parallel sentence construct by introducing the word favors.  
After responding to some initial criticism that my stronger vocabulary (modest, ground breaking, prowess) was too POV, I no longer feel there is any inbalance here.  My initial use of ground breaking was indeed excessive, but now that I've demoted and recast it as breaks ground and anchored the use to obtained many patents it no longer functions as a free-radical to convey an adulatory impression.  Likewise I feel that my depiction of the PowerPC core as modest is properly balanced in describing the floating point capability as prowess.  The people who hate Cell (Carmack) point at the crappy PPE; the people who adore Cell (supercomputing centers) point at the staggering floating-point subsystem; these two words together effectively flag and bookend a wide spectrum of opinion.  Likewise exotic is an effective flag for the jaded architect who only wants to know "what does Cell have that I've never seen before?"  If anyone still thinks the lede is too POV, you'll have to speak up again.  MaxEnt 02:16, 12 June 2006 (UTC)
thread_title: Copyedit lede