Split-core, 64-bit processor.
Had this idea for a while, need some feedback from someone knowledgeble in processor design, since I?m not.
Since the 64-bit PPC ISA still uses instructions that are 32 bits long, but it allows the processor to handle 64-bit data and adresses. Why not build a 64-bit PPC that can opt to process two 32-bit instructions simultaneuosly, Instead of one 64-bit instruction. Im talking about spliting the core and all execution units (exept vector unit, possibly) in half, so they can work independently on two different 32-bit threads. The upper and lower halfs of every register are also accessed independently, of course. (again with the possible exeption of vector regs.) If the split is handled by the context switch (like on current 64-bit PPC?s. They are natively 32-bit compatible after all. They just waste a large portion of their power in 32-bit mode. So many transistors that just sit there unused when processing 32-bit code), and combined whith hyprthreading, it ought to increase 32-bit performance almost 100% with very few added transistors. Even without hyperthreading, it should boost performance significantly.
The 64-bit PPC has been around for quite a few years now, so why hasn?t this been done? What?s the catch here?
Programmer, d?ya hear me?
Since the 64-bit PPC ISA still uses instructions that are 32 bits long, but it allows the processor to handle 64-bit data and adresses. Why not build a 64-bit PPC that can opt to process two 32-bit instructions simultaneuosly, Instead of one 64-bit instruction. Im talking about spliting the core and all execution units (exept vector unit, possibly) in half, so they can work independently on two different 32-bit threads. The upper and lower halfs of every register are also accessed independently, of course. (again with the possible exeption of vector regs.) If the split is handled by the context switch (like on current 64-bit PPC?s. They are natively 32-bit compatible after all. They just waste a large portion of their power in 32-bit mode. So many transistors that just sit there unused when processing 32-bit code), and combined whith hyprthreading, it ought to increase 32-bit performance almost 100% with very few added transistors. Even without hyperthreading, it should boost performance significantly.
The 64-bit PPC has been around for quite a few years now, so why hasn?t this been done? What?s the catch here?
Programmer, d?ya hear me?
Comments
Think about how these elements are all connected together instead of how much content they have. You could do what you are saying, but each half would have to perform the same instructions at the same time (i.e. it would be SIMD). If you want to have them do different things then you need to duplicate all of the control logic, which happens to be quite a bit of the logic (if not most of it).
Hyperthreading works by having a completely seperate context (i.e. registers) and its own decoder that issues additional instrucions to the same set of execution units.
Thanx P! Knew I could count on ya!
<starts working on his next great, great idea>
[ 11-19-2002: Message edited by: LowB-ing ]</p>
<strong>I was aware it would require additional decoding/instruction ordering resources, but those make up a fairly small part of the total amount of transistors AFAIK. Didn't realize the control logic was such a large part of the processor, though. Was under the impression that most of the transistors were doing the actual calculations. So i guess that's that then. <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" />
</strong><hr></blockquote>
Well you need to make a distinction between the decoding/instruction ordering, as opposed to the actual structure of the pipeline(s). The calculations done by an execution units aren't really seperable from the pipeline of that execution unit. You might be able to take a pair of 32-bit execution units and tie them together tightly to make a single 64-bit execution unit, but going the other way would take a whole lot of work (and extra transistors).