-
GAMEPOD.hu
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
Oliverda
félisten
Ja, meg az 1333-as HT is eléggé érdekes volt.
(#595)Drizzt: BIOS frissítés után az összes jelenlegi AM2-es lapban menni fognak a K10-es Phenom X2 és X4 procik kisebb korlátozásokkal. Pusztán csak az a kérdés hogy melyik gyártó fogja megcsinálni a BIOS-t, reméljük hogy a nagy része igen. Ha tudsz még várni bő 1 hónapot akkor várj, mivel jön az RD790-es AMD chipset és a rá épülő lapok. Az ilyen chipkészlettel szerelt lapok már kivétel nélkül AM2+ foglalatúak. Tehát HT 3.0, Split Power Lanes, 2x64bit dual channel mem. vezérlés. Sima AM2 esetében ezekről le kell mondj, de hogy ezek hiánya mennyit jelent teljesítmény szempontjából, azt nem tudom. Szerintem nem olyan sokat, de majd a tesztekből kiderül.
RD790: [link] , [link]. 3 darab hosszabb PCI-E slot lesz rajta, ebből 2x16 a Crossfire, és 1x4 az ATi féle Physics-nek. Tehát majd bele lehet rakni 3 darab R600at.
Ja, és a rá épülő AMD referencia lapot Mako-nak hívják. Biztos menni fog benne a Budapest is. 
Ha már a héten mindenképpen vásáolni akarsz akkor ezt javasolnám: [link]
[Szerkesztve]"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
-
Oliverda
félisten
Az szép lenne ha 50%-kal veszítene, az ugyanis azt jelentené hogy még lassabb mint a K8.
Az eddigi infok alapján szerintem alkalmazástól függően 20-40% lesz az előnye azonos órajelen."Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
#609
Mr. Maffia
tag
Mr. Maffia
tag
Ha volt, bocsi: [link]
-
Oliverda
félisten
-
Andre1234
aktív tag
válasz
cellpeti
#612
üzenetére
bocsi de én is csatlakozok az előbbiekhez...
Az a cpu nem a core2 re volt hivatott megverni.
Hanem northwood, prescott.
De viszont én sem osztom az észt mert meg se tudnék mukkanni ezen hsz-ek melett..
De.... talán annyit hogy hajrá AMD...
és amennyit az én pici agyammal fölfogok ezen hsz-ekből ez a K10 minimum egálban lesz
az intel cpukkal.mind 2-4 magban.
(legalábbis áresőben bízom majd)Ha x tart végtelenbe, akkor a prímek reciprok szorzatának negáltja 0-hoz tart...
-
dezz
nagyúr
Hmm, Core2 esetén fel van tüntetve egy bizonyos Internal Results Bus, a K10 esetén az ilyesmi hiányzik az ábrákról.
A végkövetkeztetésekben meg egy szó sem esik a natív 4-magosság mellett a másik legfontosabb változás, a kiemelkedő floating-point (SIMD) teljesítmény mind desktop, mind munkaállomás, mind szerver vonalon jelentette előnyről.
(#611) 7600GT: nemrég még ''lázadtál'' a technikai szöveg ellen, most meg egyenesen igényedet fejezed ki?
Bár nem tudom, vállalkozik-e Raymond egy 10 oldalas, tömény technikai szöveg pár mondatba sűrítésére. -
Raymond
félisten
''Core2 esetén fel van tüntetve egy bizonyos Internal Results Bus''
Akkor en vak vagyok, mert nem latom
A vegkovetkeztetesben nem sok mindenrol esik szo. Nem emelt ki, sot nem is nagyon emlit konkretan egyik ujitast sem, inkabb olyan zaroszonak nez ki az a resz.
''egy 10 oldalas, tömény technikai szöveg pár mondatba sűrítésére.''
NemPrivat velemeny - keretik nem megkovezni...
-
dezz
nagyúr
Naszóval, sokáig nem értettem, honnan jön a K10 AMD által mondott gyakorlati 30-40%-os (tehát elméletileg még több) fp (SSE2+) előnye a Core2-höz képest, amikor mindkettőnek 1-1 128 bites FADD és FMUL egysége van. Ez az ábra világította meg valamennyire a helyzetet:
![[kép]](http://www.k-hardware.de/bilder/spc.gif "[kép]")
[szerk: hmm, nem jelenik meg, talán gif-et nem lehet betenni.]
Nagyban: [link]
Nos, az Instruction Fetch Bandwidth rendben van. De a Data Cache Bandwidth már nem teljesen: a Real World Tech-es elemzés szerint a D-cache Core2-ben is 256 bites, csak az I-cache az, ami a K10 256 bitjével szemben csak 128 bites. Persze ez sem kis jelentőségű dolog.
Más: egy korábban linkelt blokkdiagramon szerepelt 3 általános-kód decode egység, és külön egy FP Decode&Rename egység. Ugyebár ez az RWT-s diagramokon a uCode Engine, vagy nem? Arra akarok kilyukadni, hogy így elvileg nem ~3-as, hanem ~4-es IPC-nek is lehetségesnek kellene lennie. Sőt, (az egyik RWT-s diagramon) ez a K8-nál is megvan (csak ugye a pre-decode buffer és az I-cache bitszélesség kisebb), tehát ott is többnek kellene tudia lenni az IPC-nek, mint 3.
Raymond: 6. és 9. oldal.
A natív 4-magosságra is utal, illetve a nagyobb sávszélességet, vagy pl. a több HT buszt is kiemeli. Akkor a nagy fp teljesítményt is ki kellett volna emelnie. szerk: oké, nem a Conclusions, hanem a Performance részre gondolok.
[Szerkesztve] -
#95904256
törölt tag
Szia dezz!
Említetted hogy az AMD 30-40%-os FP (SSE2+) előnyt mond a K10-re a Core2-vel szemben, holott a műveletvégzők mennyisége azonos. Ez egyben azt is jelenti hogy a Core2 műveletvégzői az idő legalább 30-40%-ban ''üresben'' járnak. Már pedig az eddigi eredmények alapján úgy tűnik, az Intel mérnökei nem végeztek ilyen ''csapnivaló'' munkát.
A K10 így látatlanban csak hajszálnyival tűnik gyorsabbnak. Nem látok benne olyan csodát ami indokolná hogy könnyűszerrel ''lelépje'' a konkurens arhitektúrát.
P.H.
Szerintem a CPU hatékonyságát jelentősen növelné az is ha nem kellene minden egyes utasítást minden egyes végrehajtás előtt újra és újra micro/macro opokra dekódolni. Ezzel legalább 2-3 lépcsővel csökkenne a pipeline hossza az ismételt végrehajtásoknál.
[Szerkesztve] -
Raymond
félisten
LOL, tenyleg vak vagyok
Ott van az IRB.
''egy korábban linkelt blokkdiagramon szerepelt 3 általános-kód decode egység, és külön egy FP Decode&Rename egység. Ugyebár ez az RWT-s diagramokon a uCode Engine, vagy nem?''
Nem. A uCode Engine a Frontend-hez elejen van, az FP Decode&Rename pedig csak kesobb jon a kepbe - az RWT-nel a ''FP Mapper and Renamer''-nek hivjak.
''Arra akarok kilyukadni, hogy így elvileg nem ~3-as, hanem ~4-es IPC-nek is lehetségesnek kellene lennie.''
Elmeletileg ~4 a Core-nal es a K8-nal a fetch szam es duplaja a barcelona. De ez nem jelenti azt hogy az IPC 4+ abba meg beleszol a tobbi stage es az x86 kod Pl. a Core-nal a retire rate 4 uOp.
[Szerkesztve]Privat velemeny - keretik nem megkovezni...
-
dezz
nagyúr
válasz
#95904256
#620
üzenetére
Hát, azért csak számít valamit (és nem pedig PR-feature
), hogy a 3x8 elemes általános-kód scheduler mellett külön ott van az a 3x12 elemes fp scheduler, tehát összesen 24+36=60 elem (egy 72 elemes reorder buffer után), miközben Core2-ben egy közös, mindössze 32 elemes scheduler van (igaz, egy 96 elemes reorder buffer után, ha ez számít). Mondjuk egy fullos fp kód-részletnél ez vélhetően nem igazán számít. Viszont ott van a 256 vs. 128 bit I-cache elérés különbsége (ez szerintetek mennyit számít?). Hozzátehetjük még, hogy az AMD-s magok utasítás-dekódolása 3+2+2+2 rendszerű, miközben a Core2 4+1+1+1, azaz az AMD több összetettebb utasítást tud egyszerre kezelni.
szerk: ja, és még valami: K10-nél a 128 bites FADD és FMUL mellett van egy ugyancsak 128 bites FMISC, de ilyet nem látok Core2-nél.
Nem akarsz még kísérletezni a 3 fölötti IPC kihozásával? Elvileg K8-on is el lehet érni 3.0 fölötti értéket.
Raymond: ja, tényleg, köszi.
[Szerkesztve] -
#95904256
törölt tag
Szerintem összeszedted az összes olyan különbséget amiért a K10 egy hajszálnyival képes a Core2-re ráverni. Talán a 256 bites I-cache ami egy kicsit talányos. Akárhogy is nézegetem, az a Core2 nagyon eltaláltatott. Csak egy-két extrém eset az amiben a K8 utoléri (megelőzi). Amennyire a Core2 eltér a NetBurst-től, a K10 annyira hasonlít a K8-ra. Olyan mint egy nagytestvér. Meglátjuk mi lesz belőle.
Az FMISC valószínűleg a VectorPath-os FP utasítások miatt ''egyéb'' dolgokat jelöli.
Pl. sinus, cosinus, integer műveletek, ...
A K8-ból IPC=3,000-t lehetett kicsikarni, nem többet. Egyébként kíváncsi vagyok hogy szerinted hogyan lehet elérni nagyobb értéket. -
dezz
nagyúr
válasz
#95904256
#623
üzenetére
''Szerintem összeszedted az összes olyan különbséget amiért a K10 egy hajszálnyival képes a Core2-re ráverni.''
No azért van ott még jópár más kisebb különbség is. Én itt csak azokat igyekeztem kiemelni, amik az fp teljesítményben is nagyobb szerepet játszanak/játszhatnak.
''Talán a 256 bites I-cache ami egy kicsit talányos. Akárhogy is nézegetem, az a Core2 nagyon eltaláltatott.''
Nyilván, ha egyszer elég szépen elverte a K8-at, anélkül, hogy egy monstrum lenne. Viszont, vélhetően megelégedtek azzal, hogy ''legyorsulja'' a K8-at, nem akartak kapásból minden világrekordot megdönteni (mi marad későbbre? ). FP teljesítményben eleve sokat hozott a végrehajtó egységek 128-bitesítése, de talán nem akartak minden cseppet kisajtolni a dologból. A K10 esetében meg nagyrészt igen (adjunk bele apait-anyait alapon -- bár azért ők is hagytak még 1-2 dolgot a K10.5-nek nevezett Shanghainak).
''Amennyire a Core2 eltér a NetBurst-től, a K10 annyira hasonlít a K8-ra. Olyan mint egy nagytestvér. Meglátjuk mi lesz belőle.''
Hmm, szerintem kisebb a különbség.
szerk: ja, közben rájöttem, félreértettelek. Akkor a válasz: hát igen, de a K8 eleve nem volt rossz, csak volt benne pár szűkebb keresztmetszet, amit igyekeztek kiszélesíteni.
''Az FMISC valószínűleg a VectorPath-os FP utasítások miatt ''egyéb'' dolgokat jelöli.
Pl. sinus, cosinus, integer műveletek, ...''
Talán az FDIV-t is ez csinálja, nem az ''FMUL'' egység, amire azért gyakrabban van szükség (bár az opt. guide szerint ajánlatos ahol csak lehet, szorzással helyettesíteni).
''A K8-ból IPC=3,000-t lehetett kicsikarni, nem többet. Egyébként kíváncsi vagyok hogy szerinted hogyan lehet elérni nagyobb értéket.''
Mint ahogy írtam: a 3 alap decoder mellett ott van 4.-ként az a uCode engine, ami látszólag párhuzamosan működik velük, és vélhetően az összetettebb utasításokon dolgozik (3 uOP vs. 1-2 uOP). Már ha jól értelmezem.
[Szerkesztve] -
#95904256
törölt tag
Hali dezz!
A K8-on az FDIV az FMUL-on keresztül hajtódik végre méghozzá úgy hogy azon az egységen minden felfüggesztődik ( tapasztalat hogy nem lehet átlapolni az osztással párhuzamos szorzásokat, de lehet hogy még az előjelváltás (FCHS, FABS) sem működik ).
Na jó, kipróbálok még pár vectorpath+directpath kombinációt egy jobb IPC érték eléréséhez ( hátha... ), de szerintem amit microcode enginnek vélsz az nem más mint az utasítások kezdőcímét meghatározó/tároló egység. Ugyanis nem piskóta dolog megmondani egyszerre 16 bájton hogy hol kezdődnek utasítások. Ugye ez kell ahhoz hogy egyszerre több utasítás dekódolásának lehessen nekikezdeni. Tkp. akkor lehetsz biztos a második, harmadik, stb. utasítások kezdőcímében mikor az elsőnek ( előzőnek ) a hosszát is sikerült meghatározni. Gondolom egy ömódosító kód ( SMC ) elég jól megtudja bolondítani a dolgokat. -
dezz
nagyúr
válasz
#95904256
#625
üzenetére
Hát, lehet, de azért gondolom, hogy az is csinál valamilyen dekódolást, mert abból is vezet egy nyíl a diagramon a Pack Bufferbe, 3 uOP-os szélességgel.
Úgy tudom, egy ideje az önmódosító kód non-allowed a fejlettebb prociknál. (Vagy legalábbis a memóriában kell csinálni egy cache flush után, vagy ilyesmi.) -
-
dezz
nagyúr
Ide vonatkozó szöveg:
''Like the Pentium Pro, the K7/8 has an internal instruction set which is fairly RISC-like, composed of micro-ops. Each micro-op is fairly complex, and can include one load, a computation and a store. Any instruction which decodes into 3 or more micro-ops (called a VectorPath instruction) is sent from the pick buffer to the microcode engine. For example, any string manipulation instruction is likely to be micro-coded. The microcode unit can emit 3 micro-ops a cycle until it has fully decoded the x86 instruction. While the microcode engine is decoding, the regular decoders will idle; the two cannot operate simultaneously. The vast majority of x86 instructions decode into 1-2 micro-ops and are referred to as DirectPath instructions (singles or doubles).''
Tehát, ez is dekódol, csak épp egyszerre nem megy a kettő (simák + ez).
(No azért nem dől össze a világ. )
Viszont, van itt egy ilyen is:
''In Barcelona, 128 bit SSE computations now decode into a single micro-op, rather than two''
Akkor most nem tudom, hogy ezek a sima dekóderrel mennek-e, vagy a speciálissal, függetlenül attól, hogy 1(-2) uOP-ra fordulnak.
Valaki valahol azt írta, hogy K10-nél az IPC 3-ról 4-re emelkedett, de akkor ez valószínű téves, és nem a max. IPC nőtt, hanem az átlag.
[Szerkesztve] -
-
P.H.
senior tag
Nagyon jó cikk, minimális háttérismeretek birtokában érthető (= ha tudja az ember, hogy miről beszél, akkor tudja azt is, hogy mit mond). Egy kicsit zavaró, hogy micro-opokban fogalmaz macro-opok helyett.
dezz #617: K10 esetében is van result bus (írja is, hogy nem ábrázolja, mert túl bonyolult lenne az ábra tőle), result bus nélkül az egész működésképtelen lenne (INT oldalon nincs is register-rename, csak resultbus->ROB/ICU forwarding, legalább K7 óta).
dezz #619: Sajnos az Intel visszatért a PPRO/P2/P3 complex-simple-simple... (itt most még egy -simple, 4-1-1-1 micro-op) decoder felállásához. Valahogy mindig RISC-felfogású decoder-eket akarnak tenni egy x86 elejére P6 óta (Netburst alatt az egyszem decoder szűkösségét elnyomta a trace-cache), pedig pont oda kellene CISC-felfogás. Ezek szerint három egymást követő OP reg,mem típusú utasítást Core2 3, K10 1, (de még ha nem DirectPath Double útra mennének, akkor is) legrosszabb esetben 2 órajel alatt fordítaná. Itt is van egy szűk keresztmetszete, illetve a mem tagokat Core2 1/órajel (cache lehet, hogy dual-ported, de LOAD - port2- csak egy van), K10 2/órajel szélességben hozza fel Data Cache-ből legjobb esetben, akár 2x128 bitet.
akosf #619: üresben ugyan nem járnak, de nem biztos, hogy FP munkát végeznek, lévén shared INT/FPU pipe-ok (számláló, forrás- és célcímek kezelése, branch futtatása, stb...)
Pont a macro-op cache-t említettem korábban is, a fetch/decode itt majd' a pipe felét viszi el, nem csak 2-3 órajelet/stage-t. A másik ötletem, a Hyper-Threading azért játszhatna itt, mert mostmár teljesen tiszta, hogy a pack-stage-ek után nincs vízszintes mozgás a macro-ophármasokban, minden utasítás arra a portra megy, amelyik lane-en van, főleg FPU-ban teli van gap-ekkel. Ezeket tölthetné meg másik szál, INT esetén pedig az 3 micro-op/cycle miatt nem nehezedne nagyobb nyomás (INT-ben sokkal nagyobb gondot okoznak a függőségek, mint a szélesség). A branch-ágak práhuzamos futtatása sajnos nem, megintcsak amiatt, mert nincs INT oldalon register-rename.
dezz #622: 3+2+2+2-t nem tudok kiolvasni az Optimization Guide-ból, csak 3/2+2+2-t. Mivel végig 3-széles maradt a micro-architecture (3 macro-op/sor), szerintem nincs 4 decoder, a VectorPath csak ábrázolásszinten külön oszlop (vagy a 3 DirectPath, vagy VectorPath).
akosf #623: érdekes módon az FSTORE-t az idők folyamán átnevezték FMISC-re. Mindenesetre ennek van belső ROM-táblája a betölthető konstansokhoz, ez kezeli az INT->FP és FP->INT konverziókat (fild, fist(p)), és ahogy mondod, az FSIN, FCOS, ... utasítások által generált spec. micro-opokat futtatja (lehet, hogy csak ez fér hozzá a belső, programozói szinten nem látható átmeneti (scratchpad) register-ekhez?)
IPC: majdnem mondtam, hogy próbálj egy átlapolt, nem függő FPU/INT utasítássort, de azt meg a decode limitálja 3-ra.
dezz #624: azért majd meglátjuk, 65 nm-en meddig fogják felvinni az órajelet, mennyi tartalék van benne.
akosf #625: felfüggesztődik? Nem hiszem el...
SMC: egy (a? ) másik topikban zajló események miatt pár napja multi-core/multi-processor/NUMA témába ástam bele magam. SMC természetesen lehetséges (még mindig 8086 miatt, de már nem sokáig lesz ez így), AMD-nél a MOESI-szerinti cache-probe módosítás esetén kiüríti az I-cache adott vonalát (store-jellegű probe esetén az I-cache-t is ellenőrzi system-wide), és érvényteleníti a teljes CPU-pipe-ot. Ha jól emlékszem, Netburst alatt nyomta ki a teljes instruction cache-t egy SMC.
dezz #628: DirectPath-on mennek egy 1 micro-opos utasítások (3 micro-op/órajel), DirectPath Double-re a 2 micro-oposok (1.5 micro-op/órajel, lényegében ugyanaz, mint a DirectPath Single, csak 2 órajel alatt fordít), VectorPath-ra a többi. Csak ennyi a szabály.
akosf #629: OP reg,mem már 2 micro-op Intel-nél. Most hivatkoznék megint a fenti IDCT-kódomra, sokszor elemi utasításoknál sem férnek el a konstans-ok a 8(/16) XMM-registerbe.
Igen, kb. annak felel meg, aminek leírtad. Csak AMD esetében van DirectPath Double, és sokkal több minden fér bele valamelyik DirectPath-ba, K10 esetén meg már főleg).
Első gondolatom a cikk után az volt, hogy vagy nagyon rááltak a server-piacra, vagy hamarosan több CPU-s rendszereket akarnak látni az otthonokban.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
Raymond
félisten
''Első gondolatom a cikk után az volt, hogy vagy nagyon rááltak a server-piacra, vagy hamarosan több CPU-s rendszereket akarnak látni az otthonokban.''
Mindketto es ilyen sorrendben Ezt csinaljak mar a Mustang bejelentese es a K8 gyakorlatbani megjelenese ota. A szerver piacon tudjak megszorongatni az Intelt technikailag es teljesitmenyileg meg persze ott nagyobb a nyereseg kisebb eladott darabszam mellett. A technologia aztan lejon a mainstreambe is. Amit most csinalnak mar par eve az a platform ertekesitese nem csak a processzoroke. Opteron, Hyperstransport, Torrenza, Fusion es mind egybevag. 4 es 2 socket rendszerekbe siman verni fogjak az Intel megoldasokat mind teljesitmenyben mind osszfogyasztasban. A 1 socket rendszerben labdaba fog meg rugni az Intel foleg az integer teljesitmeny es az oriasi L2 cache miatt ami ezeknel a feladatoklan jol jon. Bonusz hogy most nagyon divatos a stream processing es ott megintcsak ott vannak a nyitott HT/Torrenza rendszerel (pl. Clearspeed koprocik) es jon a sajat megoldasuk ami miatt (is) az ATI-t megvettek. Ezen kivul az IBM ugyanezt hasznalja a Load Runner projektnel Opteron + CELL kombinacioval.
Sokan temetik (nem rad gondoltam) az AMD-t mert a 3DMarkXY nagyobb eredmenyt az egy Core2Duo-val de azert nem eszik olyan forron a kasatPrivat velemeny - keretik nem megkovezni...
-
P.H.
senior tag
Nagyon egy dologra gondoltunk.
+[link]
Nemrég néztem, egx 2000 CPU ára 2-30 dollár környékén van, egy 8xxx CPU-é $2000 felett...
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Persze elrontottam, szóval a 2xxx CPU-k 2-300 dollárnál kezdődnek, 8xxx CPU-k pedig jóval $1000 felett. Amellett, hogy 8xxx 4/8-CPU-s rendszerekhez kell, vajon mennyivel nagyobb költség a megteremtésük (főleg a kimondottan egységesített gyártásfolyamat óta), mint egy asztali X2-nek?
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
dezz
nagyúr
Igen, már én is rájöttem erre a 3/(2+2+2)-re, miután elolvastam a vonatkozó részt (az egészet egyben még mindig nem
).
A szöveg szerint a VectorPath utasítások 3+ uOP-ból állnak (load, computation, store[, store]), és ezeket az a bizonyos uCode Engine fordítja, nem pedig a sima dekóderek. Így viszont elvileg órajelenként 1 ilyen (makro)utasítás indulhat.
Az a szövegrész, hogy K10-en már 1 uOP egy 128 bites SSE computation, vélhetően arra vonatkozik, 1 computation uOP van, tehát a loaddal, és 1-2 storral együtt 3 v. 4. -
Raymond
félisten
Az MP szeria (tobb mint 2 socket) mindig is draga volt mindket tabornal. Mondjuk az egyik elonye a Barcelona-nak platform szinten a plusz meg egy HT link. Ez benne is van az RWT cikkben.
Szerk: A koltsegek nem nagyobbak egyiknel sem (gyakorlatilag csak a merettol fugg). Csak a kereslet kicsi a ''jotallas'' a helyes mukodesre pedig szivos igy megkerik az arat. Ugyanaz a helyzet mint mondjuk a repulogep gyartoknal a kontaktok vagy mas komponensek. Sokkal tobbet fizetnek ertuk mint mondjuk egy autogyar pedig ugyanaz kapjak meg. Csak a garancia eonokkal nagyobb rajuk.
Az IBM LoadRunner persze Roadrunner akart lenni [link]
[Szerkesztve]Privat velemeny - keretik nem megkovezni...
-
P.H.
senior tag
Egyik SSE utasításkészletben nincs OP mem,reg forma, x87 szinten sincs (csak az x86 orthogonális utasításaiban) csakis OP reg,mem, OP reg,reg és store alak (az MMX/SSEx csoportokat már igencsak RISC-szemléletben tervezték).. x86 szinten pedig csak egy store lehet/macro-op (32/64 bit), az OP mem,reg formára pedig van egy spec. load/store micro-opuk, ami csak egyszer számolja a címet. és megvárja a művelet visszavonulási eredményét.
Mindez szemben az Intel load+op+store_address+store_value (4 uop) megközelítésével, bár Core/Core2 esetén már a load+store_address uop-fusion-nel van egyesítve.)
[mod] Raymond: Nem olcsóak, de megdöbbentőek a különbségek, hogy 4/8 socket-es rendszereket mennyivel drágább összeállítani, mint 2-socketes rendszereket. Az igényeket, de főleg a skálázhatóságot igencsak meg kell fizetni.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
dezz
nagyúr
Ja, oké. Furcsa is volt, hogy csak 3 uOP széles a uCode Engine outputja, mert store-ral együtt már akár 4 uOP lenne (K8-nál meg akár 5). (Bár több lépésben is küldhetné a uOP-okat, de ez nem lenne túl hatékony.[*]) Viszont akkor nem értem, miért emleget a szöveg ''3 or more'' uOP-ot. Hogy jön össze K10-en 3-nál több?
[*] Mondjuk DirectPath esetén is ennek kell történnie, mert 2 uOP a sima dekóderek kimeneti szélessége. Nem?
Mindenesetre, a szöveg szerint a VectorPath utasításokkal csak a uCode Engine foglalkozik. Így nem nagyon lehet 1.0 CPI alá menni SSEx kódban. (Tényleg, az x87-es utasításokat tudják kezelni a sima dekóderek - annak ellenére, hogy adott esetben ugyanarra a uOP-ra fordulnak?)
Szerk: ''vagy hamarosan több CPU-s rendszereket akarnak látni az otthonokban.''
Lásd Athlon FX, és később Phenom FX vonal (socket F esetén): 2-procis rendszerek gamingre, videofeldolgozásra, stb.
[Szerkesztve] -
P.H.
senior tag
mod: nem, 3 macro-op széles a DirectPach (Double) és a VectorPath is (csak a DirectPah után van register-fordítás, a VectorPath-os micro-opok mindig belső registereken dolgoznak), ez 6 micro-op (1-1-1 op+load, op+load/store, store (idáig biztos) vagy spec - esetleg spec+spec)) lehet, úgy tudom. Írtam, hogy Ő furcsán micro-opot írt mindig.
''Hogy jön össze K10-en 3-nál több?''
pl. FSIN, FCOS, és a többi rögzített ciklusszámú utasítás (a cikk írja, hogy régen az integer osztás is ilyen volt), ezek sokkal több, mint 3 macro-opot adnak.
''Mondjuk DirectPath esetén is ennek kell történnie, mert 2 uOP a sima dekóderek kimeneti szélessége. Nem?''
A DirectPath decoderek kimeneti szélessége 1 (DirectPath) vagy 2 (DirectPath Double), de azt hiszem, ezért van 2 Pack stage utánuk, ezek egyesítik és osztják el végül a 3-3 lane-re a marco-opokat.
1 IPC alá egyik x86 micro-architecture-n sem eshetne, erre kell, hogy tervezzék a scheduler pufferének (schceduler-ek puffereinek) nagyságát. De ha egyszer csak minden utasítás egy előző (nagyon hosszú) lefutású, mondjuk FSIN-től függ, akkor látszólag megállhat az élet.
''Tényleg, az x87-es utasításokat tudják kezelni a sima dekóderek - annak ellenére, hogy adott esetben ugyanarra a uOP-ra fordulnak?)'' Meg kell nézni a fent linkelt Software Optimization Guide-ot, Appendix C Instruction Latencies De nagy részét igen.
''Lásd Athlon FX, és később Phenom FX vonal (socket F esetén): 2-procis rendszerek gamingre, videofeldolgozásra, stb.'' Ehhez le kell vinni az árakat olyan szintre, amit meg is fizetnek érte az egyszeri, de nem tapasztalatlan vevők. Nekem úgy néz ki, hogy a négymagos Socket-F rendszerem összeáll egy Core2-rendszer ára alatt, és ha tényleg működik, akkor is igen-igen nagy szerencsém van megint.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
dezz
nagyúr
Hmm, de hát ez nem úgy van, hogy az x86(/x87/SSEx) gépi kód a makro-kód, ill. makro-op-ok, és a dekóderek által fordított RISC kód a mikro-kód, ill. mikro-op-ok? Ezért ír a cikk is mikro-op-okat...
<1 CPI (clock per instruction): hmm, de hát ugyebár a 3 sima dekóder egyszerre mehet, és ha pl. 1 ciklusos műveletek vannak, akkor miért ne jöhetne ki az 1 alatti CPI? -
P.H.
senior tag
Megpróbálom leírni, az integer pipe-on keresztül, hogy mi is történik. Először is a kétszintű fordítás alapegységei:
- az x86/x87/MMX/SSEx utasítások változó hosszúak (ízig-vérig CISC), szinte semmi szabályosság nincs bennük (ott van, ahol legalább ModR/M byte van), lehetnek ''egyszerű'' store, ''egyszerű'' load, vagy összetett load+operation illetve load+operation+store műveletek.
- macro-op: rögzített hosszúságú, regularized instruction field jellegű egységek, (ezek RISC jellegre utalnak, de még komplexek, mivel) általában egy tartalmaznak egy operation jellegű műveletet és tartalmazhatnak egyet a következők közül: load, store, vagy load/store azonos címre, ez így összesen adja ki a legfejlebb 2 micro-opot.
- micro-op: rögzített hosszúságú, regularized instruction field jellegű egységek, egy primitív RISC műveletet jelentenek, pontosan egyet a következők közül: load, store, operation.
Mindkét esetben az operation jelenthet integer vagy floating-point műveletet. (A K10 dokumentáció is ezen alapegységek definiálásával kezdődik).
A CPU pipeline egy jelentős része (az Instruction Control Unit-ig) azzal van elfoglalva, hogy a CISC-utasításokat macro-opokká konvertálja.
Pontos adatot arra, hogy egy macro-op mekkora méretű, nem találtam, de ezek a mezők vannak benne biztosan (az elnevezéseket a micro-opon kívül én találtam ki, egységes nevet nem tudok, illetve így egybegyűjtve nem találtam meg sehol a macro-op mezőit):
[res | resflag | resenv | micro-op1 | micro-op2 | tag | #chn]
Ezek ilyen hármas sorokban vannak rendezve, ezen hármasok egy elemi egységet alkotnak.
- res: ha a macro-op módosít egy register-t, akkor melyiket, és mivel (maga az eredmény).
- resflag: ha flag-jellegű eredménye is van, akkor micsoda (flag-jellegű, mert más lehet integer esetben - EFLAGS -, más FP-esetben - status word)
- resenv: a kiváltható kivételek (branch misprediction, page fault, divisionbyzero, ...) egy-egy jelzőbitje
- uop1, uop2: azon legfejlebb 2 micro-op (op, load, store, load/store), amiből állhat egy macro-op. Ahogy vannak, teljes egészükben. (dezz: ezen fadd32 micro-op azonos ADDSS és FADD esetén, de a macro-op környezet teljesen más).
- tag, #chn: minden macro-op kap egy sorszámot 0..23 között (23->0 átfordulásnál van jelentősége egy wrap-bitnek, ami jelzi az átfordulást), a #chn azt jelenti, hogy a hármasban melyik pozíción van (0..2). Éppen 24 db hármas macro-op sor van a ICU-ban, tehát egy-egy macro-opot pontosan azonosít egy ilyen #chn+tag-pár a teljes CPU-ban.
Ne feledjük, hogy az ICU-ig pontosan programsorrendben vannak az macro-opok, ennek a register-átnevezésnél és a függőségek feloldásánál igen fontos szerepe van. Valamint a macro-opok látható nagy méretéből következően sejthető, hogy a macro-opok fizikailag nem továbbítódnak az ICU-ból, megülnek benne, csak a ''címük'' továbbítódik a következő stage-ek felé. Egyrészt lenne ilyen fizikai továbbítás, akkor az akár negyed/fél kilobyte-os nagyságrendű adattotvábbítást jelentene a stage-ek között, ez felesleges pazarlás lenne. Másrészt a visszavonulási folyamatban vissza kell állítani az program szerinti utasítássorrendben, ami ezáltal felesleges, mert adott.
A fordítás során először meg kell határozni az utasítások elejét és végét. Adott méretű sorokban kerülnek az ezt végző egységhez az utasítások, ismert belépési ponttal (klasszikus értelemben ez egy Instruction Pointer), tehát az első utasítás eleje ismert. Ha az adott sorral akkor találkozik először az egység (most került be a memóriából az I-cache-be), akkor órajelenként 1 utasítás hosszát tudja meghatározni, majd lépteti a belépési pontot. De ha nem, akkor órajelenként több utasítás mehet a következő lépésbe, az is adott, hogy melyik (DirectPath vagy VectorPath) ágra. Miért?
Ha egy cache x KB méretű adatot tartalmazhat egyszerre, NEM azt jelenti, hogy pontosan x KB méretű. Minden cache-vonal mellett további információkat tárol, például az ECC vagy parity biteket. Ezek mellé még fel lehet venni pár speciális információt tartalmazó bitet. Az utasításhossz-meghatározó egység pl. egy-egy ilyen spec. bitbe vissza is írja az utasítások elejének és végének jelzését a vonal mellé, tehát ha legközelebb találkozik ugyanezzel a vonallal (pl. ciklus), akkor már nem kell dolgoznia (ezek a bit-értékek L1->L2 transfer után is megmaradnak, tehát az L2 is tartalmazza őket).
Az utasítás végét egy egyszerű ok miatt jelzi (tudható lenne a következő utasítás elejének jelzéséből), a kezdő- és végzőbit bitkombinációi azt is tárolják, hogy az utasítás milyen decoder-ágra kerül. Ez egyszerű ökölszabályokkal leírható, de eltérőek K7, K8 és K10 esetén, mondjuk az ADDPS xmm0,[esi] utasításnál:
- K7 esetén minden utasítás, ami egy macro-opot generál, DirectPath-ra, a többi VectorPath-ra kerül. A 4x32 bit összeadás 2 db 2x32 bites operation-nal végződik, egy macro-op egy operation micro-opot tartalmazhat, tehát VectorPath lesz (a 2 load itt nem játszik, mert elfér az egy-egy operation mellett).
- K8 esetén bekerült a DirectPath Double szemantika, 1 macro-op (általában) DirectPath-ot, 2 macro-op (általában, jellemzően FPU esetén) DirectPath Double-t, az összes többi (akár egy macro-opos utasítás is lehet) VectorPath-ra kerül. 4x32 egyanúgy 2 db 2x32 operation, tehát DirectPath Double. De mondjuk a PUSH eax (ami egyenértékű SUB esp,04h + MOV [esp],eax műveletekkel) 2 macro-op, de VectorPath-ra kerül.
- K10 esetén 1 macro-op DirectPath, 2 macro-op DirectPath Double, 3 vagy több pedig VectorPath-ot jelent. ADDPS valóban egy darab 4x32 bites operation, tehát DirectPath. (PUSH eax még mindig 2 macro-op, szóval DirectPath Double).
K7 és K8 esetén van egy speciális átkapcsolás a DirectPath és VectorPath között, mert az MROM-ból kétféle macro-op jöhet (K7-nél a cycle 5: EDEC lépcsőben, ahogy fentebb írtam).
- macro-op sablonok, az említett PUSH eax esetében SUB ESP,04h és MOV [esp],xxx. A DirectPath utolsó lépése behelyettesíti az xxx helyére itt az eax register nevét. Általánosságban, minden VectorPath-on induló, de (akár csak a címben is) register-argumentumokkal rendelkező utasítás esetében ez történik.
- a komplex, nagyon sok macro-opra forduló műveletek (FSINCOS, vagy IDIV) a register-készlet kiterjesztéseként felfogható, kívülről nem látható registerkészleten dolgozik. Minden macro-opnak van eredménye, ami register-be íródik, kelletlen lenne, ha mondjuk az FSINCOS az átmeneti értékeit a x87-stack-ba pakolná, és csak úgy lehetne lefuttatni, ha mondjuk legalább 6 üres register van a stack-ban. Ezekbe a macro-opokba bele van drótozva, hogy adott macro-op melyik registerbe tegye az éppen kiszámolt átmeneti értékét.
K10 esetén már csak az utóbbi macro-opok jönnek az MROM-ból, ezért ábrázolnak 4 decoder-t egymás mellett, viszont a VectorPath mellett nem fordulhat DirectPath-on egyidejűleg más.
Eddig megkaptuk a macro-opokat, ezeket hármasokba kell rendezni. Integer oldalon nincs nagy gond, mert minden ALU-ban és AGU-ban bármilyen jellegű művelet végrehajtódhat (''Each of the three ALUs performs general purpose logic functions, arithmetic functions, conditional functions, divide step functions, status flag multiplexing, and branch resolutions. The AGUs calculate the logical addresses for loads, stores, and LEAs.''), kivéve integer szorzás. Nagyobb gondot jelentenek az FPU-ba kerülő műveletek, mert ott minden végrehajtó egység csak bizonyos műveleteket fogadhat, ezután az állomás után viszont a hármasokban nincs cserélődhetnek az elemek, tehát itt ki kell alakuljon az macro-opsorrent a hármason belül, ami meghatározza, melyik egységbe (3 ALU, 3AGU, FADD, FMUL, FMISC) kerül az utasítás. Nem tiszta viszont, hogy pl. ADDPS reg,[mem] esetben az összeadó operation-ök csak az FADD pipe-ba kerülhetnek (0. pozíció a hármasban), akkor macro-opban mellette levő a load-nak is kötelezően az 0. AGU-ban kell-e lefutnia, vagy ezek még itt átrendezhetőek, különválaszthatóak-e. Másik kérdés: mivel az FPU-macro-opok rögzített helyre kerülnek a hármasban, a hármasok teli vannak üres helyekkel, ezek az üres helyek vajon kitölthetőek-e ALU-jellegű macro-opokkal (számláló, prefetch, ciklus kezelése megszokott az FPU-jellegű műveletekkel keverve), vagy azoknak új hármas sor indul (ez utóbbi az ideális utasítássorrendet befolyásolja nagyon kódolás/fordítás közben). Erre gondolok, hogy egy FADD ST(2),ST; FMUL ST,ST(1); SUB ecx,01h (a x87-es utasítások rögzített hármason belüli pozíciója mellett) vajon egyetlen macro-op-hármassá fordul-e ([fadd][fmul][sub]), vagy kettővé ([fadd][fmul][---] és [sub][---][---]). Ugyancsak kérdés, hogy ha csak egyetlen hármasra fordul, akkor úgy is igaz-e ez, ha a SUB az első utasítás (én így szoktam írni a kódokat, a cilkusváltozó módosítása mindig a lehető legmesszebb van a hozzá tartozó Jcc-től).
Ott tartunk, hogy adottak a macro-op hármasok, ezek programsorrendben bekerülnek az Instruction Control Unit-ba (ezentúl csak az integer oldalt nézem), két dolog van még hátra, a register-átnevezés, és a függőségek feloldása. Ehhez minden macro-op megkapja a hármasban a bekerüléskor a tag (mindig eggyel nagyobbat, mint amit az előző hármaséi kaptak, egy hármasban ugyanazt) és #chn mezőit (pozíció a hármasban). Ez a kulcsa az egésznek.
Az integer-egység nagyon pörög (emléleti 3+3 művelet órajelenként), nem igazán előnyös klasszikus register-allocation table használata (FPU-ban viszont van), mert akkor a belső register-ek száma irdatlan nagy kellene, hogy legyen. Ehelyett 2 db 16 elemű (az átmenetieredmény-register-eket most hagyjuk figyelmen kívül az egyszerűség kedvéért) register file van (16 elemű: EAX, EDX, ECX, EBX, ESI, EDI, EBP, ESP + a 64 biten megjelent 8 új integer register), a Register File és a Integer Future File. Mindkettő elemei mellett vagy ugyancsak egy-egy tag, #chn, és egy valid érték.
- az ICU látja, hogy mely register-ekből fogják kapni bemeneti értékeiket a macro-opokban levő micro-opok (akár adat, akár címzés), és a micro-opokba beleírja az Integer Future File-ban adott register mellett levő tag és #chn értéket (= programsorrendben mely művelet fogja módosítani utoljára az adott register-t, mely eredményre kell várni). Illetve, ha a valid bit is be van állítva a bejegyzés mellett, az azt jelenti, hogy az a művelet már le is futott, közvetlenül átveszi az eredményt is, nem kell várni erre az eredményre.
- azt is tudja, hogy a macro-op mely register-t fogja módosítani (ha módosít egyáltalán), annak tag és #chn értékét beírja az Integer Future File megfelelő bejegyzése mellé, és törli a valid bitet (ezzel mostmár ez a macro-op ''birtokolja'' az adott register-t).
Így fel is épült a függőségi viszony a műveletek között, gyakorlatilag 0 órajel alatt. És a másik, a Register File? Ahhoz a futási hurok másik végére, a visszavonulási eljárásra kell nézni. Minden macro-op tudja, hogy mely register-be és mit írt, a visszavonulás folyamán az ICU ezen információk alapján mindig naprakészen tartja programsorrendben a Register File-t (nicsak, itt egy másik Instruction Pointer), ugyanúgy mellette a tag és a #chn értékekkel. Ez egyedül azért kell, mert ha pl. kivétel vagy hibás elágazásbecslés történt, akkor egyszerűen a Register File tartalmával egészében felülírja az Integer Future File-t (mellette beállítja annak valid bitjeit is), és az utolsó helyes környezetben folytatódik tovább a futtatás. Tehát a két register file miatt teljesen párhuzamosan folyik a macro-opok fogadás/továbbítása az ütemező felé, és a visszavonulás (órajelenként egyaránt 3-3 macro-op).
Ezután a macro-opokat eltördeli (breaks down) az ICU a bennük levő micro-opokra, és azok beléphetnek a 3 ütemezőbe. Az, hogy melyikbe, az a hármason belüli pozíción múlik, out-of-order végrehajtás csak az egyes ütemezőkön belül függőlegesen lehet. Mindegyik ütemező után jön egy ALU+AGU (AGU-k végén a közös load/store queue), amelynek a végén egy-egy (azaz összesen három) result bus lóg. Ha egy micro-opnak megvan már az összes bemeneti eredménye, ''szaladhat'' az exection unit-ja felé. Ha viszont nincs, várnia kell a bemeneti értékére, ami meg fog jelenni a result bus-ok valamelyikék. A micro-op kapott egy tag-et és egy #chn-t, hogy mit figyeljen, és melyik bus-on (a #chn miatt csak egy bus-t kell figyelnie). Ha ezt megtalálja, akkor közvetlenül onnan leemeli az eredményt, majd várja a további ismeretlen bemeneti értékeit, ha van még.
1-1 result bus-on órajelenként 1 eredmény jelenhet meg elméletileg, ezeket az ICU is látja. Minden eredmény mellett ott utazik a tag is (a #chn adott), ezeket összeveti az Integer Future File megfelelő bejegyzéseivel. Ha azok mellett még mindig az a tag és #chn van, ami a result bus-on megjelent (azóta nem módosította semmi az adott register-t, az adott művelet még mindig „birtokolja” azt), akkor beírja az eredményt, és beállítja a valid bit-et. Ha nem azt a #chn+tag-et látja ott, akkor nem foglalkozik vele, a megfelelő micro-op már úgyis látta és megkapta az eredményét.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
dezz
nagyúr
Huh, hát ez nagyon szép, hogy ilyen kimerítően kifejtetted. Megjegyzem, azt hiszem, jóval rövidebben is megértettem volna. De gondolom, ezt már nem is csak nekem írtad.
Viszont akkor lenne még 1-2 kérdésem. A sima (DirectPath) dekóderek kimenete 2 mikro-op széles. (Vagy itt is 2 makro-opot kellett volna írniuk esetleg?) Naszóval, ebbe beleértendő mindaz, amit írtál még az 1-2 mikro-op mellé (mármint az egy makro-opban)? Mert ugye ha nem, akkor további ciklusokba kerülne mindet továbbadni, ami ugye lehetetlenné tenné a 3.0-ás IPC-t.
A másik: akkor ugye az olyan összetett, nem dedikált egységgel egyben, hanem több lépésben végrehajtott utasítások, mint pl. sqrt, több makro-opra fordulnak (és nem pedig több mikro-opra, egy sorozatban)?
A CPI-s kérdésemre válaszolok magamnak. Szóval, mint az opt. guide-ban látható, a legtöbb ''multimédia'' utasítás is DirectPath-os, így a 3 sima dekóderen mehetnek keresztül, és a throughputjuk 2/1 vagy 3/1 is lehet (instr./clock). (Azaz, SSEx utasítások egy részénél megvan az 1.0 alatti CPI.) Amik persze VectorPath-osak, azoknál a legjobb eset az 1/1 - lenne, de inkább 1/''sok'' a rátájuk.
[Szerkesztve] -
P.H.
senior tag
Azért írtam le ilyen részletesen, mert korábban felmerült (talán) akosf részéről egy decode elejére vonatkozó kérdés, hogy hogyan lehet egy órajel alatt több utasítás elejét/végét meghatározni. Ennyi az, amit (több forrásból) össze tudok rakni tényeken alapulóan magamban egységes egésszé, de nekem is van kérdésem és sejtésem elég. Sajnos ezen kérdések és sejtések jó része csak az MROM tartalmának ismeretében lenne megválaszolható, de ez meg például a legendává vált (időben kb. még 486-tal párhuzamosan elhelyezhető) Intel-AMD-botrány miatt nem lehetséges, ez a rész már nem publikus.
''A sima (DirectPath) dekóderek kimenete 2 mikro-op széles. (Vagy itt is 2 makro-opot kellett volna írniuk esetleg?) Naszóval, ebbe beleértendő mindaz, amit írtál még az 1-2 mikro-op mellé?''
A DirecPath kimenete összesen 6 micro-op - 3 op + 3 load vagy store vagy load/store. Hogy ez 3 macro-op, vagy a 6 micro-op csak később rendeződik 3 macro-oppá, ez kérdés (fel is tettem a hsz-ben). Mindenesetre egyrészt K7 óta az ábrákon a három macro-op az ICU előtt közvetlenül jelenik meg egységszinten, másrészt egyes helyeken a K8-nál pont ezt a szintet (és az átrendezés - részleges - hiányát) jelölik szűk keresztmetszetként.
pl. sqrt, több makro-opra fordulnak
K7-nél is már a DIVSS és SQRTSS DirectPath, a DISPS és SQRTPS VectorPath, tehát pontosan 1 és 2 macro-op-ra fordulnak, amik megrekednek hosszabb időre az FMUL pipe egy alágának valamely szintjén.
CPI (Clock Per Intruction) így persze lehet kevesebb elméletileg, integer úton jó rendezéssel 3 IPC (és így 0.33 CPI elérhető), ha reg,reg formáról van szó. 3 felett nem hiszem, mert a retirement unit 3 macro-op/cycle (és ezt is említik, mint bottleneck-et).
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
Raymond
félisten
''...egy decode elejére vonatkozó kérdés, hogy hogyan lehet egy órajel alatt több utasítás elejét/végét meghatározni.''
Ha jol ertettem akkor a pre-decode fazisban rejlik a megoldas. A leirtak alapjan a fetch-elt 16 byte adatot mar elore megjeloli mielott meg a scan/allign es onnan a decoderbe (direct es vector path) kerulnenek. [link]
[Szerkesztve]Privat velemeny - keretik nem megkovezni...
-
dezz
nagyúr
Ha egy makro-opban az 1-2 mikro-op mellett az eredeti gépi kódú utasításra vonatkozó, ill. abból származó információk is vannak, akkor hogyan lenne lehetséges, hogy először csak a mikro-opok adódnak tovább, és csak később csatolódnak hozzájuk ezek az egyéb mezők? Mindez az információ megvan az egyes mikro-opokban is, tehát a makro-opokba rendezés végülis egy protokoll, ami arra kell, hogy segítse a reorderinget?
(Az ICU gondolom a ROB. Mit rövidítesz ICU-nak?)
Az ábrákon a Pack Buffer kimenetét 3 uOP-nak jelölik - az merült fel bennem, hogy ennek inkább 3 makro-opnak kellene lennie, nem? Nekem így lenne logikus. Máskülönben csak 1 uOP-os DirectPath (tehát nem Double) műveletekből jöhetne össze 3.0-át közelítő IPC, Double-ekből már csak max. 1, stb.
A 3.0 feletti IPC, mint már kiderült, nem lehetséges itt. Viszont az 1.0 feletti nem csak integer kóddal jöhet ki!
[Szerkesztve] -
P.H.
senior tag
''Ha egy makro-opban az 1-2 mikro-op mellett az eredeti gépi kódú utasításra vonatkozó, ill. abból származó információk is vannak, akkor hogyan lenne lehetséges, hogy először csak a mikro-opok adódnak tovább, és csak később csatolódnak hozzájuk ezek az egyéb mezők? Mindez az információ megvan az egyes mikro-opokban is, tehát a makro-opokba rendezés végülis egy protokoll, ami arra kell, hogy segítse a reorderinget?''
Affene, hogy mennyire igazad van! Nem lehet különválasztani a memóriához hozzáférő utastásokat az eredeti környezetüktől, legalábbis azért, mert a page fault elég gyakori, ekkor egy kivételt/(software-es) megszakítást kell kiváltani, ami beolvassa a swap-ból az adott lapot, majd az kiváltó thread újraindul a page fault-ot kiváltó utasítástól. Ezt ki lehet pipálni, igen élesszemű meglátás!
''Az ICU gondolom a ROB. Mit rövidítesz ICU-nak?)''
Az Instruction Control Unit-ot rövidítem ICU-nak. ROB (Re-Order Buffer) Intel szóhasználatában létezett először PRro esetén, én pedig idegenkedek az alternatív elnevezésektől - konzervatív vagyok ezen a téren eléggé, x86-64-et is szívesebben használok, mint x64-et -, jelentsék akár ugyanazt. De ROB=ICU, igen.
''Az ábrákon a Pack Buffer kimenetét 3 uOP-nak jelölik - az merült fel bennem, hogy ennek inkább 3 makro-opnak kellene lennie, nem? Nekem így lenne logikus. Máskülönben csak 1 uOP-os DirectPath (tehát nem Double) műveletekből jöhetne össze 3.0-át közelítő IPC, Double-ekből már csak max. 1, stb.''
3 macro-op a kimenete, igen: ''Early decoding produces three macro-ops per cycle from either path. The outputs of both decoders are multiplexed together and passed to the next stage in the pipeline, the instruction control unit.'' (megintcsak a Software Optimization Guide for AMD 10h Processors-ból) Nem egyszerű átlátni, hogy pre-decode, early decode, decode hogy és hol is van, én is keverem néha sajnos.
A fordítás ICU-ig elég sötét ló, sehol nem találni teljes információt/levezetést róla (inkább csak egymásnak ellentmondóakat, és sajnos utoljára K7-re vonatkozóan találtam AMD által kiadott részletes, cycle-to-cycle leírást még anno két éve). Pedig ahogy kinéz, programozói szempontból ez a leglényegesebb. Ha a fenti kérdést lezártuk, akkor elsődlegessé a következő lép elő:
FMUL ST(2),ST
FADD ST,ST(1)
Ez vajon [fadd][fmul][---]-ra vagy [---][fmul][---], majd [fadd][---][---]-ra fordul? És ha az előbbire (jobb lenne), akkor mi tartja (tarthatja) fenn ott az eredeti programsorrendet? Erre sehol nem találtam információt. Mert fordított sorrendben:
FADD ST,ST(1)
FMUL ST(2),ST
a balról jobbra sorrend lehet vezető szabály: [fadd][fmul][---]
raymond #647:''If a branch is made to an address which does not have its pre-decode start bit set then we know that something is wrong.'' Erre értettem, hogy még nem találkozott az adott vonallal.
The instruction pipeline may invoke the pre-decoding hardware in this case to initialize or correct the pre-decoding bits within only two cycles. ... invoke the pre-decoding hardware[...] within only two cycles, de vajon az mennyi idő alatt, és hogyan végzi el a dolgát?
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
dezz
nagyúr
''''Early decoding produces three macro-ops per cycle from either path. The outputs of both decoders are multiplexed together and passed to the next stage in the pipeline, the instruction control unit.''
Na azért! Már kezdtem megijedni, hogy itt van egy érdekes szűk keresztmetszet, amikor megláttam a képet - de aztán arra gondoltam, ez nem lehet.
Meg akkor ugye az ábra fentebbi részein 1-1 makro-opról van szó valójában, csak eltérő számú aktív mikro-opot tartalmazhatnak.
''Ez vajon [fadd][fmul][---]-ra vagy [---][fmul][---], majd [fadd][---][---]-ra fordul?''
Hát ugye vagy az van, hogy a pre-decode egység figyeli a dependenciákat, és akkor a 2. eset van, vagy az ICU/ROB, és akkor talán lehet az első is. (Szóval a ROB küldené ki őket szépen egymás után.) Egy nagyon okos register-rename által jó esetben fel lehetne oldali a dependenciát (mintha Raymond írt is volna valami ilyesmit), de itt szerintem nincs ilyen, legalábbis nem látom, ebben az elrendezésben hogyan oldanák meg azt az esetet, ha erre éppen nincs lehetőség.
Ja, és a rá épülő AMD referencia lapot Mako-nak hívják. Biztos menni fog benne a Budapest is. 
Bár nem tudom, vállalkozik-e Raymond egy 10 oldalas, tömény technikai szöveg pár mondatba sűrítésére. 
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Az ide nem illő hozzászólások topikja:[link]
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- Aliexpress tapasztalatok
- Garmin Forerunner 165 - alapozó edzés
- ASUS ROG Ally
- Poco F3 - a mindenes, de nem mindenkinek
- Garancia kérdés, fogyasztóvédelem
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Ukrajnai háború
- Motorola Edge 40 - jó bőr
- További aktív témák...
