Új hozzászólás Aktív témák

• #685 P.H. senior tag dezz #662

  Új Válasz 2007-05-27 16:18:44 #685

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  P.H.

  senior tag

  válasz dezz #662 üzenetére

  Egy darabig az AMD tartotta magát az Intel-étől teljesen nomenklatúrához (például micro-op vs uop), teljesen jogosan, mert a funkcionális egységek azonos szinten is teljesen mást jelentenek (Intruction Control Unit vs Reorder Buffer), ez mára egy kissé összefolyt, nem kevés kavarodást okozva.
  
  Kezdve ott, hogy az AMD-féle micro-op sokkal általánosabb, mint az Intel uop-ja, tekintve, hogy ez utóbbinak legfejlebb 2 bemeneti értéke lehet. Egyszerűbb esetben pl. az olyan utasítások, amik bemeneti értékként valamely flag-et is használják, mint az ADC reg,reg (eredmény=reg+reg+CarryFlag) két uop-ra fordulnak Intel esetében. Bonyolultabb ez eset címzéseknél: általános címzési forma a reg+reg*scale+offset (scale lehet 1,2,4,8), PPro-tól kezdve egészen Core2-ig lehet találni olyan információkat, hogy ezesetben nem egy uop-ra fordul a címgenerálás, hanem bizonyos ALU-műveletek sorozatára, ha nem csak reg, reg+reg vagy reg+offset formájú. Kardinális kérdés ez Netburst alatt lett amiatt, hogy a reg*scale kiszámítását egy külön shift uop végezte, aminek futása egyetlen portra korlátozódott (port1, complex ALU), 3 órajel latency mellett. Prescott-tól talán ezt kiküszöbölték, a latency 1 lett, kérdés, hogy mennyi maradt meg ebből a Core-családra.
  
  uop-fúzió két esetben lehet Intel-nél, read-modify és store. Előbbinél a load+op egyesül (ez hasonló az AMD load+op macro-opjaihoz), utóbbi azt a kellemetlenséget szünteti meg, hogy egy store operation két uop-ból áll, store_address és store_data (maga a transfer), ezek két külön portra kerülnek még mindig, de decode után együtt haladnak. Ez AMD-nél egy uop, és ha hozzávesszük, hogy egy load+op+store (= op mem,reg) AMD-nél egy macro-op két micro-oppal, Intel esetében összesen 4 uop, amiból a load+op és a store_address+store_data két fuzionált párost alkot, akkor is lemaradásban van még AMD-vel szemben. Ráadásul ez a uop-fúzió a decode utáni lépés, tehát a 4-1-1-1 decoder-szélesség még mindig limitáló tényező.
  
  Makro-opfúzió csak igen speciális esetekben lehet, csak bizonyos feltételes ugrások (amik nem kezelik az Overflow Flag-et, tehát csak előjeltelen esetben) és az azokat közvetlenül megelőző CMP vagy TST utasítások (amik céloperandusa nem memória) fuzionálhatnak. Ráadásul mindez 64 bites módban nem is működik Core2 esetén.
  
  
  Ez előző, AMD pre-decode-dologhoz: zavart eléggé, hogy tényleg erőltetettnek tűnt az én mondatértelmezésem Raymond-ével szemben. Kérdezted, hogy ''lehetséges-e tetszőleges ponttól kezdve keresni a köv. utasítást'', erre én írtam, hogy ''gyakorlatilag tetszőleges belépési pontban értelmes utasítás találtható.''. A kettő nem zárja ki egymást, ha adott egy egység, ami párhuzamosan a beolvasott 16 (K10 esetén 32) byte-os ablak minden egyes byte-jától meghatározza az ott kezdődő utasítást. Kevesebből nem érdemes, az nem visz előre. Ha ez megvan, és adott az első utasítás belépési pontja, akkor akár egy órajel alatt ki lehet szűrni a 16/32 utasításból a valósakat. No de ki az az őrült, aki ilyen nem egyszerű felépítésű egységből - ismernie kell a teljes utasításkészletet - 16-ot (vagy 32-t) tesz egymás mellé egy CPU-ban.
  Hát, az AMD az. Az adott szekcióból Raymonddal szinte az összes mondatot beidéztük, gyakorlatilag csak a lényeget nem (én teljesen átsiklottam felette akkor).
  A second instruction can not be decoded until the length of the first instruction is known. The start position of the second instruction depends on the length of the first instruction. The massively parallel pre-decoder avoids this problem by first pre-decoding the 16 possible instructions in parallel. Each instruction starts at one of the 16 byte locations of the 16 byte line. It then filters out the real instructions with the help of the program-counter which points to the start byte of the next instruction, depending on where we jump into the 16 byte line.
  [link]
  K8 esetében egy-egy alapegység 1 órajel alatt meghatározza az adott byte-nál kezdődő utasítás hosszát és jellegét, 4-4 ilyen egység egy blokkba van rendezve, és 4 ilyen blokk van. Tehát 1 órajel alatt megjön az eredmény mind a 16 egységtől, amiből következő órajelben a Start/End Fixer/Sorter az ismert belépési pont segítségével kiszűri, melyek a valós utasítások. Intel esetében valószínűleg (legalábbis bizonyos esetekben) áll a step-by-step predecode, márcsak abból kiindulva, hogy az adatméret- vagy címméret-módosító prefix-szel ellátott utasításokat újra kell értelmeznie, információk szerint 6 órajel alatt (adatméret prefix pedig ismerős lehet SSE2-utasítások esetén).
  
  
  Kicsit leült a hét elején, én az utóbbi 5 napban a Csabai Sör- és Csülökfesztiválra fordítottam az érdeklődésemet. Mondjuk inkább a sör-részére, mert csülköt én is tudok elkészíteni, sört viszont nem tudok főzni
  
  [Szerkesztve]

• #663 VaniliásRönk nagyúr dezz #662

  Új Válasz 2007-05-24 22:49:44 #663

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  VaniliásRönk

  nagyúr

  válasz dezz #662 üzenetére

  Szivesen bekapcsolódnék a beszélgetésbe, de nem igazán tudnék mit hozzátenni.
  Jó hogy vannak még programozók akiket foglalkoztat a CPU-k mélylélektana.

Új hozzászólás Aktív témák