Sideband Stack Optimizer

Intel's very first Pentium M introduced a feature Intel called its dedicated stack manager. As its name implies, the dedicated stack manager was used to handle all x86 stack operations (i.e. push, pop, call, return). The purpose of the stack manager was to keep those stack operations, which are frequently used with function calls in code, separate from the rest of the x86 instruction stream sent to the CPU. The dedicated stack manager would handle decode and "execution" of these operations so that they wouldn't clog up the processor's decoders and execution units later in the pipeline. Intel essentially "widened" the core by offloading some operations to separate hardware.

With Barcelona, AMD is introducing a similar technology it is calling a Sideband Stack Optimizer. Stack instructions no longer go through the 3-way decoder and stack operations no longer go through the integer execution units, effectively widening Barcelona at minimal cost. The Sideband Stack Optimizer, like Intel's dedicated stack manager, features its own adder that handles all stack operations. It's a small tweak that can help overall performance, and it's simply one that made sense for AMD to implement.

Faster Loads

When looking at the performance of the Athlon 64 and Intel's Core 2 processors, it's easy to understand why Intel has a strong performance advantage in applications that make heavy use of SSE. But what about applications like gaming and business apps that should greatly benefit from AMD's on-die memory controller? Is the Core 2's larger L2 cache and aggressive prefetchers all that it needs to overcome AMD's on-die memory controller?

One major aspect of Intel's Core micro-architecture advantage is its ability to allow load instructions to bypass previous load and store instructions. On average, about 1/3 of all instructions in a program end up being loads, thus if you can improve load performance you can generally impact overall application performance pretty significantly. With Intel's Core micro-architecture, it's possible for loads to be re-ordered to ensure that instructions dependent on those loads get the data they need without waiting for costly memory accesses.

Core also allowed for loads to be moved ahead of stores, which was previously not allowed due to the possibility that an earlier store could invalidate the data that was just loaded. Intel figured that the possibility of a store writing over a load ends up being very small, on the order of 1 - 2%, therefore with a reasonably accurate predictor you could correctly guess when re-ordering a load ahead of a store was possible. Intel's Core 2 based processors feature prediction logic to guess whether a store and a load share the same memory address; if the predictor determines that they won't, then it allows the load to be re-ordered ahead of the store. In the small chance that the predictor is incorrect however, the load has to be redone at the cost of a pipeline flush (similar to what happens if the processor mispredicts a branch).

AMD's K8 architecture had no equivalent scheme for allowing the out of order execution of loads ahead of other loads and stores, so even without an on-die memory controller Intel was able to execute some memory operations faster than AMD. Barcelona fixes this problem through an almost identical scheme to what Intel implemented in its Core 2 processors.

Barcelona can now re-order loads ahead of other loads, just like Core 2 can. It can also execute loads ahead of other stores, assuming that the processor knows that the two don't share the same memory address. While Intel uses a predictor to determine whether or not the store aliases with the load, AMD takes a more conservative approach. Barcelona waits until the store address is calculated before determining whether or not the load can be processed ahead of it. By doing it this way, Barcelona is never wrong and there's no chance of a mispredict penalty. AMD's designers looked at using a predictor like Intel did but found that it offered no performance improvement on its architecture. AMD can generate up to three store addresses per clock as it has three AGUs (Address Generation Units) compared to Intel's one for stores, so it would make sense that AMD has a bit more execution power to calculate a store address before moving a load ahead of it.

The out of order load execution improvements to Barcelona should prove to be even more effective than they were in Core 2 given that AMD previously couldn't do any reordering of loads before the Int/FP schedulers whereas Core Duo could do a limited amount of re-ordering.

Core Tune-up Even More Tweaks
POST A COMMENT

83 Comments

View All Comments

  • JarredWalton - Thursday, March 01, 2007 - link

    Games have quite a lot of LOAD instructions, like most programs, as well as plenty of branches (esp. in the AI routines). Most likely the boost that Core 2 gets is due in a large part to the better instruction reordering and branch prediction, although the cache and prefetchers probably help as well. Given AMD was better than NetBurst due to memory latency, through in better OOE (Out of Order Execution) logic and keep the improved latency and they should do pretty well.

    Naturally, everything at this point is purely speculation, but in the next few months we should start to get a better idea of what's in store and how it will perform. One problem that still remains is that even if AMD can be competitive clock-for-clock, Intel looks primed to be able to go up to at least 3.6 GHz dual core and 3.46 GHz quad core if necessary. AMD has traditionally not reached clock speeds nearly as high as Intel, possibly due in part to having more metal layers (speculation again - process tech and other features naturally play a role), so if they release 2.9GHz Barcelona at $1000 you can pretty much guarantee Intel will launch 3.2 and/or 3.46 GHz Kentsfield (and/or FSB1333 3.33 GHz).

    On the bright side, at least things should stay interesting in the CPU world. :D
    Reply
  • yyrkoon - Thursday, March 01, 2007 - link

    Yes, interresting indeed, but from experience, AMD has always been too vocal in what they plan on doing, especially during the times they are in a 'rut'.

    What this usually means to me, is that AMD is trying to blow smoke up our backsides, we'll see though.

    Keep in mind, my main desktop system, and my backup server for that matter, both are AMD systems. The phrase "cost effective" applies here.
    Reply
  • kilkennycat - Thursday, March 01, 2007 - link

    Yesterday, Intel announced that they were converting a fourth fab to 45nm. A great deal of confidence in that process. And a few days ago they announced desktop shipments of Penryn-based CPUs pulled forward into 2007. Looks as if AMDs 'window of opportunity' is likely to be very small. IBM has not yet announced a successful implementation of a RAM on their 45nm process. Intel had their RAM design on 45nm up and running late 2005. Reply
  • archcommus - Thursday, March 01, 2007 - link

    True but the move to 45 nm might not make a huge difference in real world performance, just like the move to 65 nm didn't for AMD. Their next full blown architecture will still be a ways off. Reply
  • Roy2001 - Thursday, March 01, 2007 - link

    Dislike AMD's move to 65nm process, move to 45nm has shown that Penryn would eats less power and runs faster thanks to its high K material and metal gate. Reply
  • smitty3268 - Thursday, March 01, 2007 - link

    Every process shows that in theory before chips are actually being made on it. We'll see what actually happens when Penryn is released, not before. Reply
  • chucky2 - Thursday, March 01, 2007 - link

    Has AMD given any indication of how probable dropping an Agena or Kuma CPU into an existing AM2 motherboard will go?

    Especially AMD's own newly released 690G or the upcoming nVidia MCP68?

    Chuck
    Reply
  • mamisano - Thursday, March 01, 2007 - link

    It has been stated in the past that AM2+ based products will run in AM2 based boards. The limitation, if I understand it correctly, will be the lack of support of the new power features.

    Someone correct me if I am wrong :)
    Reply
  • chucky2 - Thursday, March 01, 2007 - link

    Then it should be no problem for AMD to confirm through AnandTech that this is the case.

    Surely if Barcelona is this close to shipping (only a few months away), AMD must know if Agena and/or Kuma will work in current AM2 motherboards, especially their own 690 series their just about to release.

    All I'm asking for is a definite either way, it shouldn't be that hard for AMD to do at this point.

    Chuck
    Reply
  • mino - Friday, March 02, 2007 - link

    AMD stated PUBLICLY to anyone who listened that AM2+ stuff will plug into AM2, just BIOS update needed.

    Why should they react to any consumer who ask on some forum the same question every second week ?

    Most important is they said it WILL(not "may") work with AM2-spec boards to big Tier 1 OEM's.
    They can not make it incompatible therefore. They would be out of bussines in no time.
    Reply

Log in

Don't have an account? Sign up now