Behívás, dekódolás

Gyorsítótárak

Az adatfeldolgozás az utasítás előbehívásával (prefetch) kezdődik, ahol a K10 szintén számos újítást vonultat fel. Az előbehívás során az x86-os utasítások az elsőszintű (L1) utasításcache-ből a dekódoló egységekhez érkeznek, amiből a K7/K8/K10 összesen kettővel rendelkezik. A K10-nél a cache-szervezésben és az elágazásbecslésben is komoly változtatásokat eszközöltek. Az elágazás-előrejelző puffer kibővült egy 512 férőhelyes indirekt előrejelzővel (amely a többirányú elágazások [switch, case] végeredményére tippel), és megduplázódott, 24 férőhelyesre bővül a visszatérési címverem mérete (Return Address Stack), amelyben a közeli és távoli hívások címei tárolódnak. Változott az első- és másodszintű gyorsítótár is: az egyes processzormagok két-két adatelőbehívóval (prefetcher) rendelkeznek (lapkánként összesen nyolc), melyek immár közvetlenül az L1 adatcache-be (késleltetése 3 ciklusidő) írják az adatokat, szemben a K8-cal, amely az L2 cache-be dolgozott (ez persze lassabb, késleltetése 9 ciklusidő). Ha az L1 cache megtelik, akkor a legrégebben használt adat az L2 cache-be kerül (exclusive cache). Az L1 utasítás- és adatcache mérete nem változott, de a TLB-ket optimalizálták, és nyolc bejegyzéssel bővültek is (40-ről 48-ra). A TLB, azaz Translation Look-aside Buffer egy olyan gyorsítótár, amelyben virtuális memóriacímekhez tartozó fizikai memóriacímek tárolódnak. Az operációs rendszerek a virtuális memóriával gazdálkodnak, ezért a processzor a virtuális címek alapján tudja megcímezni a fizikai memóriát. Minél több bejegyzés fér el a TLB-ben, a CPU annál gyorsabban fér hozzá az adatokhoz. Az L1 utasítás- és adatcache szélessége is megváltozott, az utasításcache immár ciklusonként két 128 bites utasítás küldésére, illetve fogadásásra képes, szemben a K8 kétszer 64 bites sebességével, és az adatcache is duplájára gyorsult: immár két 128 bites loadot vagy két 64 bites store-t támogat. Az L1 és L2 cache közti útvonal szélessége szintén megduplázódott (128 bitről 256 bitre), a másodszintű gyorsítótár mérete pedig magonként 512 kB-ban fixálódott, a TLB itt is optimalizáláson esett keresztül, illetve az adatcache kibővült nyolc 1 GB-os bejegyzéssel (nagyméretű adatokkal dolgozó adatbázis- és HPC-alkalmazásoknál jelent majd előnyt).

Érdekesség, hogy az adatmozgás útvonala a K10-ben az x86-os CPU-knál megszokott sorrend fordítottja. Ez azt jelenti, hogy a memóriából az adatok közvetlenül az L1 cache-be kerülnek, majd onnan az L2-be és az L3-ba. A másodszintű gyorsítótár úgymond „victim”, vagyis csak az L1 cache-ből kikerülő adatokat találjuk meg benne. Amikor egy L2 cache-ben megtalálható adatra van szükség, akkor az átkerül az L1 cache-be, és törlődik az L2 cache-ből. Az egyik legszembetűnőbb változás az L3 cache megjelenése: a harmadszintű gyorsítótár megosztott a négy mag között (tehát mindegyik hozzáfér), mérete pedig 2 illetve 8 MB között változhat. Az első K10-es processzorok 2 MB méretű L3 cache-sel kerülnek forgalomba. Az L3 cache az L2-höz hasonlóan victim cache, tehát csak az L2 cache-ből „kitett” adatokat tartalmazza, és majdnem teljesen exkluzív, de vannak olyan esetek is, amikor inkluzívként működik: amikor egy adat az L3 cache-ből átkerült az L1 gyorsítótárba (az L2 mindig kimarad), az adott adatok attól függően törlődnek vagy nem törlődnek onnan, hogy ahhoz egy vagy több processzormag akar-e hozzáférni. Ha egy, akkor az adat törlődik a cache-ből, ha több, akkor megmarad. Az L3 cache késleltetése változó a terhelés függvényében, kisebb terhelés mellett alacsonyabb a késleltetés, nagyobb terhelés mellett magasabb. A későbbiekben megjelennek majd olyan K10-re épülő processzorok is, melyek több L3 cache-t tartalmaznak, de olyanok is napvilágot látnak, melyek egyáltalán nem fognak harmadszintű gyorsítótárat tartalmazni.

Behívás

A behívás forrásának lehetőségeit végigvettük, lássuk magát a behívást. Először is érdemes felidézni, hogy a K8 tizenkét lépcsős futószalaggal rendelkezik, és ebben a tekintetben a K10 sem változott. A K10 32 bájtnyi utasítás behívására (fetch) képes (első két lépcső) szemben a K8-cal, melynek 16 bájt széles behívója van. Erre az újításra azért volt szükség, mert a programok az idő előrehaladtával egyre gyakrabban támogatják a 128 bites SIMD-utasításkészleteket, illetve a 64 bites kódot, márpedig ezek az utasítások hosszabbak (64–128 bit) az eddig megszokottaktól (16-32 bit), így ahhoz, hogy a feldolgozás folyamatos legyen, a végrehajtók el legyenek látva munkával, szélesebb behívókra van szükség. Egy keskenyebb előbehívóval kevesebb utasítás kerülhetne feldolgozásra, ami alacsonyabb IPC-t eredményezne.

Dekódolás

Mint már említettük, a K10 – a K8-hoz hasonlóan, amely a K7-en alapul – RISC-szerű utasításkészlettel dolgozik, az x86-os utasításokat kisebb utasításokra (macro-op) dekódolja, hogy könnyebben (gyorsabban) tudja végrehajtani azokat. A K10-ben a harmadik lépcső az utasítás kiválasztása, a negyedik-ötödik lépcső pedig a dekódolás. A K10-ben két különböző dekóder található, melyek nem képesek az egyidejű működésre: ezeket DirectPath és VectorPath névvel illette az AMD. A DirectPath az egy (DirectPath Single, végrehajtásuk 0,5–4 ciklus) vagy két (DirectPath Double, végrehajtásuk 2–30 ciklus) macro-oppá alakítható utasítások feldolgozásáért felelős. A VectorPath azokat a bonyolultabb utasításokat dolgozza fel, melyeket három vagy több macro-oppá kell alakítani, ehhez a microcode-engine ROM-ot használja. Mindkét dekóder utasításdekódolási üteme maximum három macro-op/ciklus. Az újítás itt is jelentős: a K10 dekóderei képesek egy ciklusidő alatt a 128 bites SSE utasítások feldolgozására. Ez azt jelenti, hogy a dekódereknek nem kell az utasításokat két 64 bit széles macro-oppá alakítani (mint a K8-ban), majd később összefűzni azokat, azaz az SSE utasítások végrehajtásának sebessége megduplázódott. De nem csak ennyi történt, hiszen ennek köszönhetően az egész design gyorsult, mert a dekódoló egységek több utasítást képesek feldolgozni adott időegység alatt, vagyis nőtt a „kibocsátás” sebessége. Az ezután következő Pack (csomagolás) lépcső (a hatodik/hetedik a futószalagban) macro-op párokat „gyúr össze”, majd továbbít a következő állomásra.

A dekódolás során újdonság a Sideband Stack Optimizer megjelenése, ami a veremmutató (ESP regiszter) értékének visszaállítására szolgál. Az alapprobléma, hogy veremműveletek (CALL, RET, PUSH, POP) végrehajtása során a veremmutató értéke indirekt módon megváltozik, ami a párhuzamosan futó veremműveletek végrehajtása során – amikor az ESP regiszter értékétől is függ a végeredmény – nem elfogadható. A Sideband Stack Optimizer beiktatásával a K10 képes a veremmutató értékét szinkronizálni, visszaállítani az utasításmeghívás előtti állapotba, így a párhuzamosan futó veremműveletek végrehajtása során nem alakul ki függőség. Az Intel ezt a funkciót Dedicated Stack Managernek hívja a Core-ban.

A cikk még nem ért véget, kérlek, lapozz!