Another round of Bulldozer and Bobcat articles and news

« A quick round of links | News from Intel's IDF, AMD and the resurrection of 3DNow! »

Another round of Bulldozer and Bobcat articles and news

by Dresdenboy ^Pro @ 2010-09-05 – 11:00:15 pm

David Kanter published his Bulldozer article at Real World Technologies, with many details you won't find anywhere else.

Anandtech published a Sandy Bridge preview of a CPU model with the top bin integrated GPU (containing 12 EUs).

Hiroshige Goto published two articles about Bobcat (Japanese/English) and Bulldozer (Japanese/English).

AMD indirectly presented a photoshopped Orochi die photo at GlobalFoundries' tech conference:

The lower modules seem to look more like an original layout. The likely 2M L2 caches and L3 cache blocks have a significant area difference. So they might have been scaled during the photoshopping or use different SRAM macro cells. I'll come back to that later.

Another die shot, which has been presented, is Bobcat's. Hans de Vries compared it to a Pineview die shot at the same scale:

A recently published paper (with some relation to AMD) describes the effect of workload phase prediction in frequency boost techniques. You can download it here. It shows the potential of knowing in advance, when performance will be needed and where.

Recent checks for further engineering sample activities (as I did in the past) were successful:

Ontario 1
Ontario 2

Sandy Bridge 1 (stepping 3, 2.1GHz)
Sandy Bridge 2 (stepping 3, 2.2GHz)
Sandy Bridge 3 (stepping 3, 2.6GHz)
Sandy Bridge 4 (stepping 5, 2.2GHz, Geekbench)
Options:
- Comments (51)
- Recommend / Bookmark Facebook Twitter Email
Tags:
- amd
- bobcat
- bulldozer
- die photo
- sandy bridge

51 Comments to Another round of Bulldozer and Bobcat articles and news

Leave a comment

Hide subcomments

- Wielkie G (Visitor)
- 2010-09-07 @ 10:59:48 pm
Please, fix your last links, because they're broken.
- Reply to comment
- Permalink
- muziqaz (Visitor)
- 2010-09-08 @ 02:13:44 am
Yes, sandy bridge links are down. And H. Goto Bulldozer translation to english comes up with error in the link(yahoo translate). And when you copy/paste the link to google translate it comes up with the same article as Bobcat translation. should it be that way? Are they two separate articles with separate URLs or are they one article?
- Reply to comment
- Permalink
- Dresdenboy ^Pro
- 2010-09-08 @ 08:05:05 am
Ah, thanks. Fixed all of them (I hope).
Most were a copy paste error from here:
http://www.semiaccurate.com/forums/showthread.php?p=66150#post66150
Didn't notice the "..." shortened URLs.
- Reply to comment
- Permalink
- Krish (Visitor)
- 2010-09-08 @ 09:32:37 pm
Hi Dresden boy,
How do you know that bobcat is running at 1.6Ghz ? it may be 18W sample with much higher frequency also (like 2.2 Ghz)
any comments
- - Dresdenboy ^Pro
  - 2010-09-08 @ 10:50:15 pm
  I didn't estimate any frequency. I wrote, that in a particular benchmark the Ontario sample is as fast as a Phenom II clocked at that frequency.
  - Reply to comment
  - Permalink
- Poper (Visitor)
- 2010-09-09 @ 06:05:37 pm
David Kanter/Hiroshige Goto

Isnt K6 a 4way processor? K6 has 4 fastpath decoders ,2x more than Bobcat.

Isnt Bulldozer integer sheduler issue rate reduced to 2 macrops? It can not be 4 macroops cuz logic per stage is reduced not increased. BD can be clocked 30% more than Llano.

K8 INT sheduler = 3macroops (17gate stage) 22FO4
K9 INT sheduler = 2macroops (12gate stage) 17FO4

BD has shared integer RF co it will use two INT clusters to run single thread (4way, runahead technique).

And this MMX unit. Shouldnt it be a 128bit IMAC? FMAC FPU also can operate on MMX registers so there is no point to call IMAC as a MMX unit cuz it can operate also on XMM registers.
- - Dresdenboy ^Pro
  - 2010-09-09 @ 06:53:24 pm
  K6 doesn't decode to MacroOps. It decodes x86 code to up to 4 RISC86 ops per cycle, where an ALU op with mem operand would result in at least 2 RISC86 ops.
  
  Correct, BD int scheduler can schedule up to 2 "MacroOps" or better said, up to 2 ALU plus 2 AGU ops per cycle, while those don't necessarily be part of the same 2 MacroOps, actually maybe of even 4 different ones.
  
  BD doesn't have shared IRF and isn't able to run 1 threads on 2 clusters at once. Do you have sources for your statement?
  
  Sure, MMX could be 128bit IMAC. This would at least make sense. MMX registers would only be mapped to the FPRF. I also don't know, why it's called MMX.
  - - Fruit (Visitor)
    - 2010-09-09 @ 09:15:18 pm
    The same ("mmx") units will likely run integer SSE too.
    - - superrugal (Visitor)
      - 2010-09-10 @ 08:52:35 pm
      Maybe the MMX unit can be regarded as "Integer SIMD Unit".
      - Reply to comment
      - Permalink
- Arlington (Visitor)
- 2010-09-10 @ 02:43:41 am
Poper Boy:
Why do you insist in calling BD K9?
K9 was a different project from AMD that never saw the light of day. (Source: http://en.wikipedia.org/wiki/AMD_K9).

The blog owner changed this comment on 2010-09-10 09:15:36 am
- Reply to comment
- Permalink
- Poper (Visitor)
- 2010-09-10 @ 05:21:39 pm
@Dresdenboy
K6 doesnt decode to macroOps but its 4way processor. It can decode 4 x86 instructions per cycle not 2 x86 like Bobcat. According to AMD:
89% of x86 instructions is decoded to single microOp
10% of x86 instructions is decoded to macroOp
<1% of x86 instructions is handled by vectorpath decoder.
For example: 4 fastpath decoders (K6) can decode 20 x86 instructions but 2 fastpath macro decoders (Bobcat) can decode only 12 x86 instructions in the same time.

Speaking about shedulers look at this diagram:
http://pc.watch.impress.co.jp/img/pcw/docs/390/769/html/09.jpg.html
You can see that there are two shedulers (dual ported address sheduler and dualported integer sheduler). How do you want execute ALU op if you send macroOp to address sheduler?

Integer RF is shared cuz there are 12 read and 8 write ports. Enough to support 4ALU and 4AGU. Without shared integer RF such techiques as eager, runahead are not possible.

This "MMX unit" is for sure 128bit IMAC. Its fully pipelined unit cuz BD can decode integer SEE 128bit instructions as a one Op.

@Arlington
BD was supposed to have 8gate stage but latter it was changed to 12gate. Its still the same project(K9) but extended to 12 gate. Perhaps there were some elements that they couldnt pack to 8 gate or to run in one cycle.
- - Vithren (Visitor)
  - 2010-09-12 @ 01:34:26 am
  "Its still the same project(K9) but extended to 12 gate. Perhaps there were some elements that they couldnt pack to 8 gate or to run in one cycle."
  What a pile of...
  K9 was different project, AMD's try with SMT. And no, BD is not the same project and no, it never was - and for god sake it wasn't "extended" in any way.
  Naming BD, AMD family 15h, K9 won't make it one.
  
  End of troll feeding, that was the last time -_-
  - Reply to comment
  - Permalink
- - mmarq (Visitor)
  - 2010-09-17 @ 11:26:24 pm
  "" K6 doesnt decode to macroOps but its 4way processor. It can decode 4 x86 instructions per cycle not 2 x86 like Bobcat. According to AMD:
  89% of x86 instructions is decoded to single microOp
  10% of x86 instructions is decoded to macroOp
  <1% of x86 instructions is handled by vectorpath decoder.
  For example: 4 fastpath decoders (K6) can decode 20 x86 instructions but 2 fastpath macro decoders (Bobcat) can decode only 12 x86 instructions in the same time. ""
  ------------------------------
  
  I believe K6 used a different RISC interpretation than the one that is prevalent since K7 called RISC 86
  http://www.freepatentsonline.com/5926642.html
  http://www.freepatentsonline.com/6336178.html
  I believe i'm not wrong... look at the patents dates... but if i'm wrong its only a manner of interpretation of uOP and Mop
  
  So it might very well be that K6 decoded 4 x86 cycle but only those that decode into a single uOP single fast-path... those that decoded to double fast-path or what in K7 was called a Macro-op needed microcode in K6.
  
  K6 III already used RISC 86 but K6 I and II not.
  
  Bobcat.. nevertheless is equivalent to K6 II and III in the number of uOP decoded per cycle... meaning Bobcat is capable of 4 uOP cycle, but can execute only 4 uOP cycle or equivalent to 2 x86 instructions( in most cases) if those are ALU + AGU(LS)
  
  K7/8/10 (hound family) is capable of decoding 6 uOP cycle or equivalent to 3 x86 instructions( in most cases) if those are ALU + AGU... but not whit a direct correspondence with LS operations, because this family is only capable of 1 load + 1 store per cycle, i.e., forwarding mechanisms load <-> store permitted to take more advantage than K6, from the higher decode bandwidth.
  
  Llano with full o-o-o LS operations must take much more advantage from the 6 uOP decode bandwidth (probably what was originally intended for "Barcelona")... Like the rest of K# family, Llano doesn't have the LS units coupled to the "INT Scheduler" so this "Goto" blog is a crude and WRONG simplification...
  
  BD decode 8 uOP cycle(including microcode), that can be parted by the 2 cores of a module, or can be directly affected to 1 core if the module is only crunching 1 thread... dynamically, ON-THE-FLY, permuting between the 2 modes in a very fine grained situation... cycle by cycle if must be... in a situation when there can only be 1 decode slot for 1 thread and 3 for the other in 1 cycle, passing to the situation when there can be 2 decode slots for each thread in the next cycle, finally to the situation when there will be 4 decode slots only for 1 thread in the next cycle... DYNAMICALLY altering to any situation cycle by cycle ... and DECODING O-O-O... AND THIS IS THE SECRET OF THE EFFICIENCY OF THE SHARED FRONT-END in POV (or too many patents are making me ill)
  
  a)There is nowhere saying that the decode slots are POWER administrated 1 by one, i.e., there can be decode slots shutting down when there are only 1 thread per module... the front-end decode block is a monolithic block(yet dynamic).
  
  b)Like the previous K#(hound) family BD doesn't have any LS unit coupled directly to the INT Schedulers
  
  c)There is at least 1 LS unit per core/cluster, because only 2 AGen units are not capable of 2 loads + 1 store cycle per core... and IT CAN'T BE 2 loads + 1 store per module or per 2 cores, because it would give 1.5 LS operations cycle per core against 2 LS operations cycle per core of Bobcat... meaning Bobcat would have more ILP IPC than BD in many code sequences when there are only a sequential single thread( AMD completely absurd)
  
  d) its possible that BD takes an hybrid approach to the LS operations between Bobcat and K#(hound)... where the AGen(s) are responsible for the Load operations and the LS or better a STORE unit is responsible for the stores(not coupled to the INt scheduler).. using a "memory file" analog to the Memory Order Block(MO of Nehalen/Westmere http://upload.wikimedia.org/wikipedia/commons/6/64/Intel_Nehalem_arch.svg
  
  **this goto blog seems in the crapish side**
  
  So BD is capable of decoding 8 uOP cycle or equivalent to 4 x86 instructions( in most cases) if those are ALU + AGU... DYNAMICALLY parted by 2 cores cycle by cycle.. but not whit a direct correspondence with LS operations, because this new arch is only capable of 2 load + 1 store per cycle per core, i.e., forwarding mechanisms load <-> store does indeed permitted to take more advantage than K#(family), from the most probably a little higher decode bandwidth per core attending to the dynamic situation... mneaning its possible to retire the equivalent to 4 x86 inst per cycle per core (but probably, in average, in a much less amount of consecutive cycles than K#(hound) is capable of 3... if only 1 thread is active per module)
  
  Bottom line, by throughput BD should have higher ILP IPC than K#(hound)family PER CORE, begging the question then if its only capable of 2 uOP cycle in execution, then that higher throughput is a huge waste... unless those AGen are capable of simultaneous ADD or MOV and BD is capable of executing 6 uOPs per cycle like K#(hound) family, but in a much more efficient way.
  
  My GUESS, at least BD is more 20% in ILP IPC than K#(hound)family PER CORE
  - - mmarq (Visitor)
    - 2010-09-18 @ 02:31:29 am
    I'm answering to my self because i forgot to mention a very important detail... AMD is tight lipped about many details...sensibly i'm afraid...
    
    But one detail that i'm most curious is the fact of BD having extensive Data Prefetch... mostly with a "stride" method.
    
    Stride Method is the preferential method (in some microarch implementations a lot of academia exercises)... and patents are there, old but exactly that method... stride-based data address prediction structure
    
    A very strong point, stride based prefetch is inexorably intertwined with stride base address prediction... the first only needs a table to get the second.
    
    Stride-based data address prediction structure
    http://www.freepatentsonline.com/6079006.html
    
    Data address prediction structure and a method for operating the same
    http://www.freepatentsonline.com/6604190.html
    
    So the data prefetch engine (stride) is responsible for "speculative data address generation" only needing an earlier or "base" address generation that could be provided by the stack engine for return addresses
    
    Superscalar microprocessor configured to predict return addresses from a return stack storage
    http://www.freepatentsonline.com/6269436.html
    Microprocessor including return prediction unit configured to determine whether a stored return address corresponds to more than one call instruction
    http://www.freepatentsonline.com/6973563.html
    Determination of current stack pointer value using architectural and speculative stack pointer delta values
    http://www.freepatentsonline.com/7685406.html
    
    and by the decode slots themselves upon decoding memory operations instructions
    Conditional early data address generation mechanism for a microprocessor
    http://www.freepatentsonline.com/5813045.html
    Apparatus and method for microcode patching for generating a next address
    http://www.freepatentsonline.com/6141740.html
    Uni-stage delay speculative address decoder
    http://www.freepatentsonline.com/7257045.html
    
    to those earlier or "base" addresses are calculated and joined the strides...
    
    So its quite possible that the AGen units with the store units are responsible for the "non-speculative" addresses, supplying that way the correction to the stride tables...
    
    ... and if those "speculative" data values corresponding to the predicted addresses are already in the "Memory File"(to Intel MO or in the Register File (which has a speculative 'shadow' file) it can proceed with "speculative execution" quite ahead of what is normal when waiting not only for LS resolution but also ahead of what is possible with LS load<->store forwarding schemes(having disambiguation correction later)...
    
    So the possibility of executing 6 uOP per cycle peak in BD, but with more restrictions than upon the K#(hound) family, should instead give more effective performance in BD.
    - Reply to comment
    - Permalink
  - - mmarq (Visitor)
    - 2010-09-18 @ 03:53:10 am
    I'm tired... really
    
    "" Bottom line, by throughput BD should have higher ILP IPC than K#(hound)family PER CORE, begging the question then if its only capable of 2 uOP cycle in execution, then that higher throughput is a huge waste ""
    
    Should read 4 uOP per cycle in execution
    
    But according to Macro-ops (Mops), and if AMD definition of a Mop is a AL + AG(LS) operation then BD is only capable of 2 Mop per cycle... confusing ??
    
    I say its capable of 6 uOPs cycle, but of those 6 uOPs, at the max only 4 uOPs can correspond to Mops, and that will be 2, because there are only 2 AG units per core... it got clear my point
    
    2 Mops + 2 discrete uOPs per cycle per core BD doesn't have a "op packing" stage like K#family because make much sense... specially with extensive speculative execution
    
    So BD has a little more restrictions upon executing those 6 uOPs than the K#(hound) family, and it could very well be one those is that 4 uOPs 2Mops are the MAX normal execution that everybody is talking about, and the additional 2 are restricted to "speculative execution".
    - Reply to comment
    - Permalink
- AMDK11
- 2010-09-18 @ 11:06:19 am
89% of x86 instructions is decoded to single microOp
10% of x86 instructions is decoded to macroOp
<1% of x86 instructions is handled by vectorpath decoder
--->
K10 exec up 6 microOp per cycle with macroOp (2 microOp)
but K10 exec only 3 microOp per cycle with macroOp (1 microOp)
BD exec 4 microOp per cycle.
- - Wielkie G (Visitor)
  - 2010-09-18 @ 12:11:20 pm
  Most of the macroOps (2 microOp) is ALU with memory (ALU+AGU). It's estimated, that *half* of x86 instructions has memory reference.
  
  And BD can exec only 2 ALU ops per cycle.
  - - AMDK11
    - 2010-09-18 @ 03:54:01 pm
    1. Intel Core can't exec macroOps but better than K10. Why ?
    2. In K10 arch, Only 2 AGU can exec most of the memory ops.
    3. fp macroOps (2 microOp): 1 for FPU, 1 for AGU.
    - - Wielkie G (Visitor)
      - 2010-09-18 @ 05:07:52 pm
      1. Intel Core *can* execute macroOps (they do that through microOp fusion, which delivers two microOps simultaneously to two ports).
      2. Yes, because there are only two read ports and two write ports (which are also 2x narrower), and only 2 can be used at time.
      3. Yes, you're pretty right here. But in INT-only code, with 50% of instructions having memory operations, BD can execute only 2 such instructions per cycle per core, while Phenom can 3 (1.5 AGUs, which is below available 2).
      
      Of course these are only peak values. Having unified sheduler, better prefetchers and OoO L/S may increase BD's IPC in total relative to Phenom. However, there still will be some cases where BD is slower than Phenom. And undoubtly slower than Core derivatives (Nehalem, S.
      
      But... IPC is not all This is the actual preformance which matters. I hope clock will improve much.
      
      PS. This 50% estimate is from Mitch's message.
      - AMDK11
        
        2010-09-18 @ 05:32:10 pm
        
        Now, we only can speak wind but can't see. When BD are out , we will know, what is faster in most of case?
        I think BD will faster K10 in all of case !
        
        Reply to comment
        
        Permalink
      - mmarq (Visitor)
        
        2010-09-19 @ 12:38:29 am
        
        "" PS. This 50% estimate is from Mitch's message. ""
        
        Meaning comparatively with a 6 core "Thuban"(choose it because it has more advanced power features)that is at 3.2Ghz then a 8 core (4module) BD should be at 4.8Ghz ?
        
        Reply to comment
        
        Permalink
      - mmarq (Visitor)
        
        2010-09-19 @ 01:09:55 am
        
        "" 2. Yes, because there are only two read ports and two write ports (which are also 2x narrower), and only 2 can be used at time. ""
        
        You mean in here K10 and to the LS access address/data buses ?
        
        And why should/could there be more ports?
        ( in K10 there are only 2 LSU and K10 is only able 1 load + 1 store cycle )
        
        IF BD can do 2 load+1 store cycle per core, than is quite different of K10... but if those 2+1 is per module(2 cores) =worst= why in the well the need to retire 4 instructions per cycle (it would never be attained by the 2 cores) ?
        
        Reply to comment
        
        Permalink
  - - mmarq (Visitor)
    - 2010-09-18 @ 04:04:08 pm
    well i don't know exact numbers, but i believe you are correct...
    
    up to 50% can decode to Mop(but not quite)...
    
    i believe that in this percentage are already some of the simpler vector instructions... and possibly Mop fusion results
    
    up to 50% can decode to uOPs(but not quite)...
    
    less than 10% use the vector paths...
    this accounting with the big push with INt and FP vector instructions of SSE# + AVX
    
    Now this begs the question... can BD only execute 2 ALU ops per cycle... i really DON'T KNOW... or can it execute 4 ALU ops per cycle per core(including here are some of the simpler SSE INt instructions)... matching in the total 8 ALU ops = > equivalent to 4 x86 instructions; and equivalent to what BD can decode at peak ??
    - - mmarq (Visitor)
      - 2010-09-18 @ 04:14:59 pm
      To reason in this doubt, is why i foreseen that 2 of those ALU operations per core are speculative, which addresses are not calculated by the AGen(s) units, but much earlier(speculatively).
      - Reply to comment
      - Permalink
- - mmarq (Visitor)
  - 2010-09-19 @ 01:28:39 am
  What about K10 exec 4 microOp... only with macroOp(2 microOp) ?...
  
  and K10 exec 5 microOp... with 2 macroOp(2 microOp) + 1 microOp ?
  
  BD exec 4 microOp per cycle(core?).. non-speculative ?
  (8 per module - > retire 4 x86 instructions cycle(~=8uOP))
  - Reply to comment
  - Permalink
- Poper (Visitor)
- 2010-09-19 @ 01:11:54 pm
@mmarq
Who told you that Core2/i7 can execute macroOPs? MacroOps are only possible in K8 integer core cuz you have ALU/AGU units (3 operand units and queues). Intel CPUs cant execute macroOps cuz ALU/AGU units are on separate slots.
- - Wielkie G (Visitor)
  - 2010-09-19 @ 01:52:51 pm
  @Poper
  Who told you that Core2/i7 *cannot* execute macroOps? It's simply called MicroOp Fusion, and creates possibility to issue one MicroOp bound to *two* ports (e.g. add instruction and memory read). You can easily call this MicroOp "MacroOp".
  
  However, what is interesting, Core2/i7 can execute only one read op and one write op per cycle. It is very similar to BD, but BD can execute also 2 read ops per cycle (without any write op).
  - - AMDK11
    - 2010-09-20 @ 05:50:02 am
    Core arch only issue one MicroOp bound to *one* port !
    - - mmarq (Visitor)
      - 2010-09-20 @ 04:11:21 pm
      Yet Intel x86(macro) fusion... and specially microOp fusion can be a little more powerful than AMD Mop (AL+AG), they are very similar in functionality(core2/i7 also have 6 execution ports like K10(hound))... there isn't nothing so extraordinary about it, neither a miraculous performance enhancing...
      
      x86 (macro) fusion
      http://abinstein.blogspot.com/2007/06/decoding-x86-from-p6-to-core-2-part-3.html
      
      Intel MicroOp fusion
      http://abinstein.blogspot.com/2007/05/decoding-x86-from-p6-to-core-2.html
      
      Where core/i7 are clearly superior are in memory operations ... i believe this archs buffer store operations, not only that, at least i7 also does "speculative execution" if i'm not mistaken, so it doesn't have to go that much to the access address/data buses... it goes for the RF on those...
      
      Llano also does 'only' 1 read and 1 write operation cycle, yet it should be at least 10% over K10 in ILP = > IPC ... so i'm convinced that Llano should have a performance very close to i7...
      
      Where does that leave BD ?...
      
      BD and SB, if i'm not mistaken, can do 2 read operations and 1 write operation cycle per core, and BD also buffer store operations and should have more extensive "speculative execution" than SB... so their ILP = > IPC should be very close also ( though i'm willing to concede a little more to SB (very small) do to BD tradeoffs...).
      - mmarq (Visitor)
        
        2010-09-21 @ 07:26:15 pm
        
        "" Llano also does 'only' 1 read and 1 write operation cycle, yet it should be at least 10% over K10 in ILP = > IPC ... so i'm convinced that Llano should have a performance very close to i7... ""
        
        Of course this is WITHOUT "turbo" tricks... the major fountain of performance advantage of i7 over the 'static' K10(hound) family... "Thuban" has already revealed a much more leveled playing field... and Llano Desktop, it can even tilt the game to the other side... i wouldn't be surprised...
        
        No wonder Intel is like a maniac trying to bring SB as earlier as possible.
        
        Reply to comment
        
        Permalink
- - mmarq (Visitor)
  - 2010-09-20 @ 05:29:05 am
  where is written by me that core2/i7 can execute Mops ?
  
  ...the only mentions to Intel archs i made in this thread was about a Memory Order Buffer... and memory operations are always uOPs...
  
  where did you read it , or got the idea ?
  - Reply to comment
  - Permalink
- Poper (Visitor)
- 2010-09-19 @ 01:27:11 pm
Only integer instructions in K8 are decoded to macroOps. On average 10% of x86 instructions is decoded to macroOps. 2 OPs are only fused if mem and alu ops are separate (there is no dependency) so one macroOp can be executed simultaneusly by AGU/ALU pair.
- Reply to comment
- Permalink
- Poper (Visitor)
- 2010-09-20 @ 05:17:51 am
Errata
"2 Ops are only fused if mem and alu ops are separate (there is no dependency)

if they are not separate (there is dependency)

http://support.amd.com/us/Processor_TechDocs/40546-PUB-Optguide_3-11_5-21-09.pdf
Appendix C
Decode Type:
1.Direct Path Simple decodes:
-MicroOps(2operands)
-MacroOps(3operands)

@Wielkie G
Core2/i7 can not decode to 3 register operand macroOps cuz AGU/ALU units are separate(you need special ALU/AGU unit) and on diffrent shedule slots. You just can not split fused 3 operand instruction into 2 separate ops cuz its already fused.
- - mmarq (Visitor)
  - 2010-09-20 @ 04:34:37 pm
  @ poper
  " Errata
  "2 Ops are only fused if mem and alu ops are separate (there is no dependency)
  
  if they are not separate (there is dependency)"
  
  Isn't exactly the contrary... the alu op and the mem op are from the same instruction, so they are intrinsically dependent. At least in K10 it is so. The purpose of the idea is to save entries in the ROB and the schedulers, and so permit a wider instruction window without additional complexity and 'footprint'...
  - Reply to comment
  - Permalink
- Poper (Visitor)
- 2010-09-23 @ 08:49:03 pm
Intel CPU can not decode to macro-ops. Look at the diagram:
http://www.realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=5

You have simple decoders (1 uop). Where is your micro fusion?
- Reply to comment
- Permalink
- Wielkie G (Visitor)
- 2010-09-23 @ 10:35:37 pm
Micro-op fusion is *in* decoders. This means that the simple decoder can decode two uOps while micro-fusing them.
- - AMDK11
  - 2010-09-24 @ 06:41:37 am
  3 Simple + 1 complex decoder.
  Complex decoder can but simple can't.
  - - Wielkie G (Visitor)
    - 2010-09-24 @ 03:01:40 pm
    You're wrong. Simple decoders just *can*. Source:
    
    Agner's optimization manual, part 3: The microarchitecture. Look at the microarchitecture of Core2 (and Pentium M too).
    
    http://www.agner.org/optimize/
    - Reply to comment
    - Permalink
  - - Poper (Visitor)
    - 2010-09-24 @ 03:06:15 pm
    Complex decoder is AMD only. Intel doesnt have any complex decoders.
    
    Intel: 4 simple decoders + ucode engine
    AMD: 4 complex decoders + ucode engine
    
    Intel: 4 simple decoders can decode 4 uops per cycle.
    AMD: 4 complex decoders can decode 4 mops per cycle(8 uops).
    
    AMD decode capability 2x more than Intel!
    - - Wielkie G (Visitor)
      - 2010-09-24 @ 03:14:18 pm
      Again wrong... I'm tired now. Just RTFM and don't confuse people. Useful source above (Anger's manual).
      - Reply to comment
      - Permalink
- - Poper (Visitor)
  - 2010-09-24 @ 11:59:01 am
  I see that Intel simple decoder can decode 1 uop per cycle. Where do you see two uops per cycle?
  
  MicroOp= 1 operation
  MacroOp= 2 operations
  Intel simple decoder = 1 uop per cycle
  AMD directpath decoder = 1 mop per cycle (2 uops per cycle)
  
  AMD decoder can decode 2x more uops than Intel decoder.
  - - Wielkie G (Visitor)
    - 2010-09-24 @ 03:11:55 pm
    You also are wrong.
    
    Simple decoder can decode only one single uOp per cycle, but it may be a micro-fused one. It's still one uOp, but contains two operations to two different ports. For example, load and calculation in something like 'add eax, [ebx]'.
    
    Note that, the microarchitecture is flawed by a drawback that one not-fused uOp can only have 2 inputs. However, write instructions have 3 at most. Look at this: 'mov [eax + ebx], ecx'. All three registers are inputs. Because of that, there are two write ports: write address port and write value port, one calculating memory address and second writing to this address. Micro-op-fused uOps can have 3 inputs, so one can fuse these two operations. However, something like add [eax], ebx still uses 2 uOp, i.e. it's not totally merged (unlike AMD's solution, which MacroOp is more powerfull AFAIK).
    
    So I'm not saying, which solution is better. I'm just saying that Intel processors can also decode these "complex" instructions using one of the simple decoders.
    - Reply to comment
    - Permalink
- Poper (Visitor)
- 2010-09-24 @ 07:01:31 pm
You are wrong.

Fused uop is not uop any more but mop.

uop= only one operation
mop= 2 operations

You just cant call uop that contains two operations as a uop cuz you have 2 operations not 1.
- - mmarq (Visitor)
  - 2010-09-25 @ 06:41:57 pm
  Also AMD64 or x86-64 in Intel confusing lingo is EM64T...
  
  Intel uOP fusion is in the decoders... they aren't that "so" simple as Intel marketing wants to make belive
  
  Here is a good explanation
  http://abinstein.blogspot.com/2007/05/decoding-x86-from-p6-to-core-2.html
  
  "" What is actually expanded is an additional XLAT PLA for each partial x86 decoder (see the diagram above, and also Part 1 article of this series), so that partial x86 decode can handle those load/store instructions that generate two micro-ops. Naturally, the performance increase won't be spectacular, and the early report from Intel is just between 2% to 5%. This is actually not that bad a result, given the technique itself is pretty localized (to the x86 decode and micro-op format), and the main point of micro-fusion is not to remove dependency or to increase execution width anyway, as will be discussed later. ""
  
  VERY SIMILAR TO AMD THOUGHT INTEL GIVES IT THE POMPOUS NAME OF "uOP FUSION"
  
  To really remove dependency and increase execution, there are techs called "operand value prediction" and "data value prediction"... which leads to increased execution and core2/Nehalem/westemere and now SB only have a form of the last "data value prediction and generation" using a Memory Order Block, and SB a very crude and rudimentary approach of the first... meaning speculative operations on Intel archs is still somehow rudimentary...
  
  AMD in current versions as none of that... Bobcat and Llano will have similar to SB or a form of the last "data value prediction and generation" using a similar to Intel Memory Order Buffer with separated load and store queues(disambiguation later)...
  
  ... and BD will have both with a "lookahead unit" in cooperation with the stack engine for "operand value prediction and generation" using a "speculative physical RF" (shadow of the architectural one)... and a more elaborated form of "data value prediction and generation" using earlier "data address prediction"...
  
  Those methods with operand and data value prediction and generation, will/must employ extensive forms of earlier address prediction which in BD are "stride based" by the data pre-fetch engine and by the decoders themselfs (that always in any case are also capable[decoders] of address generation)...
  
  value prediction and generation again using a spPRF and a "memory file" very similar to Intel MOB... meaning that in BD with earlier address (speculative) prediction and generation, perhaps "up to" 30% of addresses are not calculated by the AGen (non-speculative) if most of the speculative predictions happen to be correct...
  - - mmarq (Visitor)
    - 2010-09-25 @ 06:50:45 pm
    AMD is tight lipped, but that is my guess...
    
    BD is "only capable" of 2 Mops = > 4 uOPs per core( it only has 2 AGen units), if we do not count speculative execution... because in total it will be capable of 6 uOPs cycle per core, the same 'peak' capability of K10(hound), only that 2 of those executions are pure speculative...
    - Reply to comment
    - Permalink
- Poper (Visitor)
- 2010-09-25 @ 07:18:46 pm
If Intel simple decoder can decode 2 operations per cycle then its like mop in AMD.

I have corrected David Kanter diagram:
http://img203.imageshack.us/img203/3673/83446401.png

AMD directpath decoder can decode 1Mop per cycle not 2Mops.
Intel decoders can decode mops like AMD decoders.
There are 4 simple decoders in Intel not 3.
Intel ucode engine can decode 3 mops per cycle not 4.
- - AMDK11
  - 2010-09-26 @ 09:11:47 am
  http://www.realworldtech.com/includes/images/articles/bulldozer-3.png
  - Reply to comment
  - Permalink
- - mmarq (Visitor)
  - 2010-09-26 @ 05:08:21 pm
  @Poper
  
  The definition of uOP in Intel is a little different from AMD... an Intel Mop corresponds exactly with a x86 instruction...
  
  Intel simple decoder can decode 2 operations per cycle only in the case of "fusion" and nothing is really "fused" but more well described has "packed"... THERE IS NO MAGIC...
  
  "" * It only works on x86 read-then-modify and operate-then-store instructions, where no dependency check is needed between the two micro-ops to be fused.""
  
  Arithmetic Logic ops, the same happens, simpler decoders decode 2 uOP, only in the case of "fusion-packing" if those happens to be easily calculated has being independent ops... dependency checking hardware in Intel is more "agile" than AMD.. thats all...
  
  "" * It doesn't change or affect the ALUs, so the same number of execution units is still needed for one fused micro-op as two non-fused micro-ops. ""
  
  So quite similar to AMD packed operations... sometimes inferior, because AMD can do it for more instructions... and the result is to have 1 ROB/reservation station entry occupied by 2 ops that will go to 1 ALU op and 1 LS op...
  
  Exactly the same effect with AMD "doubles"... but what is more advanced in Intel are LS operations...
  
  Actually its quite clear that K10 has more IPC than core2 at x86-64 operations, Phoronix test suit shows that...
  
  i7 is a different story, but without "turbo" tricks the IPC difference is ONLY a little bit above 10%... not more...
  - Reply to comment
  - Permalink
- Poper (Visitor)
- 2010-09-26 @ 10:37:24 pm
"The definition of uOP in Intel is a little different from AMD. an Intel Mop corresponds exactly with a x86 instruction."

AMD mop also corresponds exactly with a x86 instruction.

AMD mop = 2 uops.
Intel mop = 2 uops.

I dont see any diffrence.
- - mmarq (Visitor)
  - 2010-09-27 @ 07:03:18 pm
  I believe i'm not sure, but a AMD Mop is a fully pre-decoded x86 instruction... AMD pre-decodes more extensible... its L1 #I is fully pre-decoded, usually a lot bigger L1 $I than Intel L1 #I in more than 1 way...
  
  So in finer details there is a difference.
  - Reply to comment
  - Permalink
- mmarq (Visitor)
- 2010-09-27 @ 07:10:24 pm
And in the die shot above(this thread) the L3 is also quite a bit different than Intel...

It should follow an HT style packet communication between the "nodes", point-to-point with virtual channels ( not some kind of ring bus), and by the picture its a fully distributed configuration, not a SINGLE pool like in K10(hound) families... Quite advanced IMHO!

It reminds me of POWER 7!... meaning cache coherency protocol might have changed also...
- Reply to comment
- Permalink