Hardver Ismeretek IA32 -> IA64
Intel IA-64 architektúra
Problémák az IA-32-vel
Bonyolult architektúra CISC ISA (RISC jobb a párhuzamos feldolgozás szempontjából) Változó utasításhossz és forma – nehéz dekódolni és párhuzamosítani Lehetséges megoldás: IA-32 ISA utasításait széttördelhetjük RISC-szerű rövid utasításokra – ez azonban bonyolult HW-t igényel Címtartomány problémák (2^32 = 4GB) Kevés általános célú regiszter – sok memóriahivatkozás, akkor is, ha logikusan nem kéne (pl. eredmények átmeneti tárolására – ezt regiszterekben lehetne tárolni) Titkos regiszterek használata – bonyolítja a HW-t pénz++
Általában igaz: teljesítmény nagy része nem arra megy el amire kéne (nem „számol”, hanem zsonglőrködik a CPU)
Intel IA-64 architektúra
Megoldások Félmegoldás: EMT-64
IA-32 64 bites kiterjesztése Pl. P4 architektúra, 64 bites címekkel, 64 bites regiszterekkel
Végső megoldás: IA-64
HP & Intel közös fejlesztés Teljesen új architektúra – tiszta lap
Intel IA-64 architektúra
EMT-64 (EM64T – Extended Memory 64 technology) rövid története
AMD 64 bites kiegészítést tervez az x86, 32 bites architektúrához, elnevezi x86-64-nek Később átnevezi AMD64-nek Intel is lép, bevezeti a 64bites kiegészítést, melyet rendre IA-32e, EM64T, Intel 64 néven nevez Általános név a kiegészítésre: x86-64 v. x64
Intel 64 és AMD64 szinte ugyanaz, minimális különbségek vannak (pár operandust enged az EMT64, amit AMD64 nem, de ezek kivételével kompatibilisek, mindkettő 32bites gép 64bitesre való kiterjesztése, 64bites új utasításkészlettel) Intel és AMD egymást sakkban tartják egy szerződéssel: ha Intel felmondja, nem készíthet x64-es gépet, ha AMD, nem használhatja az ia32-es architektúrát (így az x64-et sem)
Intel IA-64 architektúra
x64 kiegészítései
64bit integer típus támogatása Plusz regiszterek (ált.reg.-ek száma 8-ról 16-ra) Több SSE (Streaming SIMD Extensions) regiszter Nagyobb fizikai és virtuális címtér (2^32-ről akár 2^64) NX (Non-execute) bit, futtathatatlan memóriarészek puffer overflow támadások ellen Stb… Az x64-es architektúra alapvetően 32 bites architektúra, annak minden gondjával
Intel IA-64 architektúra
x64 előnye
32 bites kódot alapból képes futtatni, SW-k jelentős része 32 bites (OS, driverek, stb) Nagy adatmozgatásoknál a 64bites memóriaelérés jól jöhet (szerverek, 3D)
Intel IA-64 architektúra
IA-64
HP rájött hogy a RISC megközelítés határa az egy utasítás per egy órajel Új architektúrát dolgozott ki, melyet EPIC-nek (Explicitly Parallel Instruction Computing) neveztek el
Itt több utasítás is végrehajtódik egy órajel alatt, de nem a CPUnak kell vizsgálnia hogy melyek lehetnek ezek, hanem a fordító vizsgálja meg, és generál ennek megfelelő kódot a HWből ezt a vizsgálatot ki lehet hagyni olcsóbb, gyorsabb
HP társul az Intellel, közösen fejlesztik az architektúrát Megkapja az Itanium nevet, melyet később Itanic-nak csúfol a közösség (a nehéz fejlesztés, késések miatt) Sokan az IA-64-től várták a szerverpiac robbanását (HP még most is ettől várja)
Intel IA-64 architektúra
IA-64 előrejelzések változása (2004)
Intel IA-64 architektúra
Főbb IA-64 újítások
RISC megvalósítás (EPIC Expl. Parall. Inst. Comp.)
Rengeteg regiszter – kevesebb memóriahivatkozás
Szoftver (fordító) kiváltja a bonyolult HW elemek implementálását, jól párhuzamosítható kódot generál 128 db általános célú 64 bites regiszter 128 db lebegőpontos regiszter (IEEE 745) 80 bit sok regiszter, így a részeredmények regiszterbe kerülhetnek mem. helyett 128 db spec. alkalmazás regiszter (státusz, ia32, stb) 64 bit 64 db 1bit predikátumregiszter – feltételes futtatáshoz használt 8 db elágazásregiszter (branching) 64 bit – indirekt elágazás esetén a célcímeket tartalmazzák
IA-32-es kódot először HW-ből tudott, de lassan, így HW emuláció kikerült és egy SW réteg csinálja gyorsabban: IA32 Execution Layer (IA-32 EL)
Intel IA-64 architektúra
Főbb IA-64 újítások
Utasításütemezés feladata a fordítón – a fordító már előre kideríti mely utasítások végezhetők párhuzamosan és ezeket megfelelő csoportokba szervezve készíti el a kódot. A HW-nek már nem kell ezen „gondolkodnia” csak vakon ütemezni a csoportokból. A fejlesztés végén, a végső fordításnál nagyon sokáig is optimalizálhat a fordító, jó fordítókat készíteni is nehéz Predikáció – utasítások feltételhez kötöttek (pl. CMOVZ R2,R3,R1 – ha R1=0, R3 megy R2-be) – feltételes elágazások csökkenthetők. IA-64 minden utasítása feltételessé tehető, minden ágat elkezd végrehajtani, a végrehajtási cső végén a feltétel alapján eldobja vagy végrehajtja Spekulatív betöltés – memória regiszter betöltéseket a fordító előbbre hozza, mert lassúak. Ha sikertelen, nem megszakít, hanem mérgezett bitet használ – ha amúgy sem kell ez az érték később, akkor simán dobjuk – spóroltunk egy fölösleges megszakításkezelést
IA-64
Elképzelés jó Megvalósítás (SW) nagyon bonyolult, nem használja ki a HW-t Menet közben az x64 architektúrák mérhetőek lettek az IA-64-hez (ahol a fordítók nem tudják a HW-t kihasználni) Nehalem és Opetron azonos teljesítményt nyújt olcsóbban fejlesztést megint csak hátráltatja A távolabbi jövő mégis egy új, tisztán 64 bites architektúra Most érdemes megnézni a trendet :
Google Trends példa („itanium”,”core 2 duo”,”core i7”) Top500.org, proc. arch. csoport
IA-64
Google Trends (2009 szept) kék: „itanium” 2,8 ; piros: „nehalem” 1 ; sárga: „core 2 duo” 16,4 ; zöld: „core i7” 1,8
IA-64
Google Trends (2010 szept) kék: „itanium” 2,8 ; piros: „nehalem” 1 ; sárga: „core 2 duo” 16,4 ; zöld: „core i7” 1,8
IA-64 Top500
IA-64 Top500
