-
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
-
-
P.H.
senior tag
Ezen esetekben ki kell törölni az adott mag L1-éből a vonalat, és a másik mag L1-ébe kell átvinni. Mivel AMD-k esetében (Athlon óta biztosan) az L1 a fő cache (az L2 és az L3 is csak write-back victim cache), egy CPU-n belül csak egy helyen lehet az adott adat. Tehát nem lehet beleírni az L3-ba, mert oda csak azok az adatok kerülnek, amik »helyhiány« miatt kerülnek ki az L1-ből.
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
Az idézeted (a .PDF-ben nem találtam ilyet) és az Optimization Guide között ott van az ellentmondás, hogy az idézet szerint ''The L3 Cache, however, is not exclusive,...'' a Guide szerint viszont ''The L3 cache is considered a non-inclusive victim cache architecture,...''. Szerintem egyszerű a dolog, hogy a jelenlegi K8 X2-k/Opteron-ok esetében is két mag közötti átvitelt a crossbar valósítja meg, ezen nem változtattak semmit.
De tegyük fel, hogy az L3-on keresztül menne: akkor a CPU-n belüli teljesen exlusive hierarchia miatt az egyik L1-ből/L2-ből kiíródna az adat az L3-ba (, amiatt onnan egy értékes vonal esetleg kikerülne a memóriába), majd onnan a másik mag L1-ébe, viszont az L3-ban nem maradhatna, ezért az L3 vonalát azonnal érvényteleníteni kell. Tehát az L3-ban levő értékes adatok mennyisége csökkenne feleslegesen. És gyanúm szerint ez lassabb is lenne, mint az eddig bejáratott crossbar-megoldás. NUMA architecture mellett sem ritka az ilyen adatáramlás, tehát ez jelentős L3-teljesítményvesztést jelentene, mert az L3 egy része folyamatosan üres/invalid lenne.
[mod]: ''Egyébként szerintem x86-on nincs extended prec. FP.''
[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
En inkabb az AMD dokumentaciora hagyatkoznak mint az Anandtech-es cikkre
Ha megnezed a 182 es a 216 oldalon a diagramokat akkor ott latszik hogy az Anandos szoveg lehet kicsit egyszerusitett. Az AMD az L1 es L2 cache-t szamitja a core-hoz a SRQ-t es az XBar-t mar nem. Viszont a 182-esen teljesen hianyzik az L3 a 216-al ellentetben.
Szerk.: Ha pedig a die photo-t nezed akkor ott lathato hogy valahol az SRQ/XBar-on keresztul kell hogy menjen a kommunikacio, az L3 kicsit ''messze van''.
[Szerkesztve]Privat velemeny - keretik nem megkovezni...
-
Raymond
félisten
Ez a resz leir mindent szepen es tomoren:
''Wie bereits hinlänglich bekannt ist, führt AMD beim K10 ein drittes Cache-Level ein. Auf diesen L3 Cache können alle Kerne gemeinsam zugreifen, während sie dedizierte L1 und L2 Caches haben. Liegen die benötigen Daten im L1 Cache, kann ein CPU-Kern sie direkt laden. Dies funktioniert auch, wenn sie im L1 Cache einer anderen CPU liegen. In diesem Fall läuft die Kommunikation wiederum über die Crossbar. Liegen die Daten im L2 Cache, werden sie in den L1 Cache geholt und im L2 Cache gelöscht. Liegen die Daten im L3 Cache, können sie direkt in den L1 Cache geladen werden, ohne einen Umweg über den L2.
Ist der L1 Cache voll, werden dort die ältesten Daten wieder in den L2 Cache geschrieben, ist dieser auch voll, in den L3 Cache usw. bis in den Hauptspeicher. Im Gegensatz zum L2 Cache werden vom L3 Cache geladene Daten nicht zwangsweise verworfen. Mithilfe eines Shared-Bits kann die CPU kernübergreifend genutzte Daten markieren, sie stehen dann auch anderen Kernen zur Verfügung.''
Ugy van ahogy ertelmezted.
Akkor az AMD doksi 216-os oldalan azert van az az elrendezes ami, mert igy tudtak az L3-at megfeleloen abrazolni.
[Szerkesztve]Privat velemeny - keretik nem megkovezni...
-
dezz
nagyúr
Hmm, úgy tűnik, rosszul emlékeztem erre az FPU vs. SSE dologra, mert a GDC2007-es pdf-ben ez van:
Vectorized SSE is very fast with SSE128
- Much faster than x87 & scalar SSE
- Double-precision is 2x faster than x87
- Single-precision is 4x faster than x87
És itt elég nyilvánvalóan rendes SIMD kódról van szó.
Viszont, valahol pedig szó volt az FPU-s, x87-es kód egy operandusos SSE-re (''scalar SSE'') fordításáról, hogy az gyorsabb, de akkor nem tudom, mennyivel.
ps. egy megjegyzés a PowerPC/Cell/Xenon procik VMX/AltiVec/Velocity Engine-jéről (mind ugyanaz): ez eleve 128 bites volt megszületésétől, mármint 128 bit/ciklus, mint amilyen a K10 most lett... A Xenonban ennek VMX128 verziója van, de ez nem úgy 128, mint az SSE128, hanem azt jelzi, hogy 128 regisztere van (+ néhány új utasítás).
[Szerkesztve] -
#95904256
törölt tag
Megjegyezném hogy a P4D-ről a C2D SSE végrehajtása nem csak a 128 bites engine miatt gyorsult jelentősen.
Lássuk pár SSE2 utasítás késleltetési / ütemezési idejét:
MOVAPD xmm,xmm: 7 / 1 ---> 1 / 0,33
ADDPD xmm,xmm: 5 / 2 ---> 3 / 1
MULPD xmm,xmm: 7 / 2 ---> 5 / 1
elméleti sebességnövekmények:
Adatpakolászás: 7*1/1/0,33 = x 21,0
Összeadás: 5*2/3/1 = x 3,33
Szorzás: 7*2/5/1 = x 2,8
A K10-re visszakanyarodva, az alábbiakra számíthatunk:
MOVAPD xmm,xmm: 1 / 0,33
ADDPD xmm,xmm: 4 / 1
MULPD xmm,xmm: 4 / 1
Ez versenyben van a Core2-vel.
-
Raymond
félisten
Az a kep a 128bit-es ujitas bemutatasara szolgal legfokeppen. Ezert hianyzik rola egy csomo dolog amit a picike FMISC komponensel inteztek el.
''Egyébként működhet egyszerre az összes egység? Gondolok itt kevert SSE+FPU kódra.''
Keverni keverhetsz, ez eddig is lehetseges volt. Viszont az hogy allandoan ellasd mukaval az osszes feldolgozo egyszeget az lehetetlen.Privat velemeny - keretik nem megkovezni...
-
Raymond
félisten
Csak annyit hogy gyakorlatilag a komplett x87 pipeline hianyzik a keprol.
Csak nem értem a 128 bites FADD-ot és FMUL-t, amik ugye sima FPU-s egységek.
Az SSE+FADD es SSE+FMUL egy-egy egyseg a ket-ket feladatra (x87 es SSE). Lasd itt: [link]
[Szerkesztve]Privat velemeny - keretik nem megkovezni...
-
Raymond
félisten
Azt hiszem kicsit elbeszeltem melletted
Visszaolvasva, arra gondoltal hogy a 2x128bit helyett 4x64bit operaciot hajtana vegre hozza pedig valamilyen x87 vagy SSE1 stb.? Ez lehetetlen mert a schedule/disptach nem tud annyi utasitast tovabbadni.Privat velemeny - keretik nem megkovezni...
-
Raymond
félisten
Charlie a szokasos szerencsetlen forma helyett inkabb az informaciotartalomra koncenralodhatott volna.
''So what do you end up with? A massive gain in frequency. How massive? Almost 500MHz. Instead of the much touted launch parts, look for five SKUs at launch, AM2 quads at 2.6GHz, 2.7GHz and 2.9GHz, a dual at 2.7GHz and a quad on socket F at 2.8GHz.''
Referencia tablazat:
[link]
The Inq szoveg ekodolva
1) ''AM2 quads at 2.6GHz, 2.7GHz and 2.9GHz'' = Phenom X4 = 2.4Ghz + 500Mhz = 2.9Ghz
2) ''a dual at 2.7GHz'' = Athlon 64 X2 = 2.2Ghz + 500Mhz = 2.7Ghz
3) ''a quad on socket F at 2.8GHz'' = Ezt a Phenom FX-bol silabizalta ki valahogy de nem tudott fix erteket irni mert meg kerdeses lehet a TDP miatt.
SZVSZ a 2. pontnal azert nem a Phenom X2-t vette mert ott mar eleve van 2.8Ghz valtozat.Privat velemeny - keretik nem megkovezni...
-
Hát meglátjuk, amikor ténylegesen bejelentik (esetleg megbízhatóbb forrásból) vagy kaphatóak lesznek a szépségek
De nekem tetszene, ha alapból 2,9Ghz körül indulna a buli. Abban bizta lenne ''kráft''
Bár ahogyan néztem a hozzászólásokat nem nagyon kell félni, hogy rosz lesz a k10. -
Raymond
félisten
Az x87-nel nem nehezedik rajuk semmi nyomas. Meg mindig lenyomjak bermelyik masik x87 CPU-t a piacon. Nem volt ertelme ebbe sok penzt es energiat olni. Kulonosen hogy az x87 szorul ki a piacrol. Az MS OS-ek alatt a nativ 64bit-es aplikacioknak mar nincs hozzaferesuk az x87, MMX es 3DNow! registerekhez. Csak az SSE-k elerhetok.
Privat velemeny - keretik nem megkovezni...
-
-
#95904256
törölt tag
dezz: Úgy érted hogy az FPU regiszterek ''dedikáltsága'' vagy a temporary regiszterek szűnnek meg?
Ha ez előbbi, akkor hurrá! Sikerült átdolgozniuk (egyszerűsíteniük) az egész egységet. Ez kisebb késleltetéseket, kisebb fogyasztást jelenthet.
Ha az utóbbi, akkor: Megspórolnak pár ezer tranzisztort, viszont a ''speciális'' műveleteket lelassítják. ( szögfüggvények, maradékképzés, logaritmus, ... ) -
P.H.
senior tag
Igazából most igazán nem értem, mit értesz a így superscalar végrehajtás. Fejtsd ki még egyszer pls.
''Mint ahogy az integer ALU-knál teszik is már jó ideje!'' Tudomásom szerint a Netburst volt eddig az egyetlen, amiben az ALU-k 1 órajel alatt 2 utasítást tudtak fogadni. Ezt emlékeim szerint úgy oldották meg, hogy a két egyciklusú ALU - és az ütemező (egy része) - a hivatalos magórajel kétszeresén működött.
[offoff]Karakterisztika és mantissza kifejezéseket használja az 1988-as kiadású Pethő Ádám: A ROM-BIOS és ami mögötte van (IBM PC/XT felhasználóknak és programozóknak) Az Intel 8087 koprocesszor című fejezete. Megfelelően régi? [/offoff]
akosf #476:
A K8 és a K10 elméleti végrehajtási sebességét és gyorsulását hasonlítottam össze, ahol a decode, dispatch, és a pipe-ok működése is lényegében azonos mechanizmuson alapul. Végülis a K10 a K8-hoz képest lesz kétszeres sebességű, AMD szerint.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
Rive
veterán
Az elvileg lehetséges 4 körüli IPC elég problémás. Dícséretes, hogy erre törekszenek, de a gyakorlatban integer oldalon az átlag kettő már nagyon-nagyon jó. És ez adott program esetében - magán programon kívül - nem annyira a VE-k számán, hanem inkább az elágazásbecslésen, az OOO cuccokon meg az efféléken múlik.
Lebegőpontos oldalra nincsenek pontosnak vehető információim. Bár a mérés elvileg kivitelezhető, jelenleg nincs rá időm./// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!
-
P.H.
senior tag
Azt hiszem, így már értem, hogy képzelted. Azt hittem, hogy mondjuk az egyszem FADD 4 számolóegységébe akarsz 4 scalarSSE/FPU utasítást bepasszírozni egy órajel alatt alkalomadtán.
Az AMD ütemezői K7 óta (K7 óta biztosan) egyidejűleg összesen 9 micro-op indíthatnak egy órajel alatt párhuzamosan, 3-3 a három darab ALU-ban és a velük ábrázolásszinten valamiért szoros kapcsolatban lévő AGU-ban, 1-1-1 az FADD, az FMUL és az az FSTORE (azaz FMISC) egységekben.
Az FPU-egységei is komplexek, talán a K7 dokumentációjában van kifejtve legrészletesebben:
- FADD: (FP add/MMX ALU/3DNow!): The first of the three pipes is generally known as the adder pipe (FADD), and it contains 3DNow! add, MMX ALU/shifter, and floating-point add execution units.
- FMUL: (FP mul/MMX ALU/MMX Mul/3DNow!): The second pipe is known as the multiplier (FMUL). It contains a 3DNow!/MMX multiplier/reciprocal unit, an MMX ALU and a floating-point multiplier/divider/square root unit.
- FSTORE: The third pipe is known as the floating-point load/store (FSTORE), which handles floating-point constant
loads (FLDZ, FLDPI, etc.), stores, FILDs, as well as many OP primitives used in VectorPath sequences. (Itt még az OP elnevezéssel illeték a micro-op-okat, csak hogy az Intel nomenklatúrájától különbözzenek, és így ebben az időben az SSE1 még 3DNow! Professional néven futott.)
Egyébként amikor megérkeztek az első hírek a K8L megduplázott FPU-járól, akkor én is azt hittem, hogy több exetucion unit-ot megdupláznak.
Ha rajtam múlna, hogy merre fejlődjön tovább az x86, akkor a következők felé vinném el:
- a kiindulási alap egy K-family alapú micro-architecture (persze lehetőleg K10 a 128 bites FPU miatt, csak az még nem kézzelfogható most). A macro-op megközelítés maradna, sokkal hatékonyabb, mint az Intel-féle micro-op szemlélet (fusion-nal együtt), és a közös INT/FP pipe-ok se szimpatikusak.
- a decoder-ek »mögé« tennél egy Intel-féle nagyméretű trace cache-hez hasonló macro-op cache-t tennék, levenné a L1-ről és a decoder-ekről a sokszori felesleges munkát (pl. minden ciklus-lefutás újrafordítódik). Azt ne feledjük, hogy AMD-nél a 1x-stage pipe hosszának kb. felét teszi ki a fordítás macro-op szintre.
- behoznék az x86 utasításszintre egy speciális, 8 byte-os paraméterű feltételes ugrásokhoz kapcsolható prefix-et, így meg lehetne különböztetni már programszinten az IF-ELSE ugrásokat a ciklusszervező ugrásoktól.
- az elágazásbecslés-szempontú ugrásvégrehajtás mellett az előbbi prefix-szel együttműködve alkalmaznám azt a (például IA-64-ben implementált) elágazáskezelési technikát, amelyben spekulatívan mindkét ágat elkezdi végrehajtani, majd a kiértékeléskor az hamis ág utasításait eldobja. Igencsak megnőne az eldobott utasítok száma, viszont ugyanennyivel (összességében nagyban) javulna a megtartott utasításokok mennyisége a mostanihoz képest. Az micro-architecture elbírná szerintem ezt a többletnyomást.
- az egészhez átvenném az Intel Core2-es load/store szemantikáját, igencsak megnövelt, (visszavonható) store-bufferrel
- az egészet megfejelném a Hyper-Threading egy olyan megvalósításával, ahogy nem teljesen szimmetrikus a szálvégrehajtás, hanem az OS-től kapott prioritás mentén lenne egy főszál és egy mellékszál, ami a főszál által nem használt execution- és retirement sávszélességet használhatná. Azonos prioritási szinten természetesen szimmetrikus lenne.
Az AMD CPU-k felépítéséből ebbe az egészbe leginkább a VectorPath decoder nem illik bele (Decoding a VectorPath instruction may prevent the simultaneous decode of a DirectPath instruction ezt úgy értelmezem, hogy ez olyan ciklusjellegű és ciklusváltozótól függő utasításoknál, mint a REP MOVSx, leállítja a teljes dekódolást az utasítás lefutásáig. Vajon az olyan x87 utasítások, mint FSIN, FCOS, FPATAN is ilyenek?). Az a kóbor rémképzetem van, hogy a K10-ben tapasztalt szembetűnő VectorPath->DirectPath (Double) áttérés és az x87 háttérbe szorítására figyelmeztetés valamelyik fenti elképzelésem felé visz, és afelé, hogy ''záros határidőn'' belül eltűnik a VectorPath.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
-
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."
-
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...
-
#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...
-
#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. -
#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. -
-
-
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 ˙˙˙
-
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 ˙˙˙
-
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 ˙˙˙
-
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 ˙˙˙
-
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 ˙˙˙
-
Raymond
félisten
''a pre-decode egység figyeli a dependenciákat''
Az biztosan nem. A pre-decode csak megprobalja megtalalni es megjelolni a parancsok parametereit egy blokkon belul. A dependenciakat csak a dekodolas es ''szeleteles'' utan lehet elvegezni a ROB-ban hogy az OOOE elv mukodjon.Privat velemeny - keretik nem megkovezni...
-
P.H.
senior tag
A 8/16/32/64 bites x86 készlet (folyamatosan bővítve a P1-ig) így néz ki:
- othogonális stílusú utasítások: op dest,src forma, ahol dest és src vagy register, vagy cím, vagy közvetlen adat lehet, de nem lehet op mem,mem forma, értelemszerűen a dest nem lehet közvetlen.
prefix | opcode | ModR/M(+SIB) | addr_offset | immediate (32 bitben a leghosszabb utasítás tizenvalahány byte-os lehet).
pl. lock add [edi+ecx*2+0000100h],eax vagy add eax,20h
Az kód alap cím- és adatméretet (default word = 16/32/64 bit, 8 bites adatméret mindenhol van, az más opcode) a kódszegmens bizonyos bitjei határozzák meg, ezért az addr_offset és az immediate egyenként 16/32/64 bites lehet. Lehetne, de ha valamelyik -128 és 127 között van, akkor az 8 biten kódolódik, decode idején előjelhelyesen kiegészítődik.
A default word méretek között egy-egy utasítás erejéig a 66h (adatméret) és 67h (címméret) prefixekkel lehet váltani, 64->16 és 16->64 váltás nincs. Az opcode kódolja az adatméretet (8 vagy default word), a ModR/M és a 32 biten megjelent opcionális SIB (scale-index-base) kódolja az memóriaoperandus címének formáját és hosszát (8 vagy default word méret), ha van egyáltalán, illetve az egyik vagy mindkét register-operandust.
- van egy nagycsomó egybyte-os egyoperandusú utasítás, közvetlenül opcode-ban kódolt argumentummal: nyolc külön darab INC, DEC, PUSH, POP,... utasítás van a 8 register-re, persze ezeknek van egy-egy 9. formája is, ami memóriaoperanduson dolgozik (ModR/M vagy SIB segítségével), minden 8 bit displacement-es feltételes urgásra (később 0Fh prefix-szel kiegészítve jelentek csak meg a default word displacement-es változatok).
- a 8086 átvette a 8085 jórészt klasszikusan akkumulátoros/célregister-es utasításait is, ezek is egybyte-os utasítások, pl. a MOVSD 32 bitet beolvas a ESI által mutatott címról, azt kiírja a EDI által mutatott címre, majd továbblépteti 4-gyel a megfelelő irányba (ezt a EFLAGS egy bitje mutatja). Ha emellé odateszünk egy REP/REPZ vagy REPNZ prefixet, akkor ezt annyiszor ismétli, amennyi ECX értéke kezdetben (meg ha időközben a ZERO FLAG beállt/törlődött, összehasonlító jellegűeknél, mint CMPSD, SCASD). Viszont ezek némelyikének is van 8 bit-es argumentuma. Rengeteg utasítás tartozik ide is.
- De hasonló jellegű utasítás máig az integer osztás (osztandó EDX:EAX-ben, eredmény EAX-be, maradék EDX-be), a port-I/O utasítások, és még sokan mások. Ezek egy 1 opcode byte-osak, egyik operandusuk fix, a másikat mondja egy ModR/M(+SIB) mondja meg.
Még leírni se egyszerű. És ez még csak a kezdet, a rendszerutasításokat, mint time-stamp counter, controlregister-ek, descriptor table register-ek kezelését hagyjuk inkább.
Az x87 utasítások opcode-ja 2 byte-os, az első (talán) 9 bit megegyezik, a többi 7 kódolja a műveletet, és hogy memóriacím vagy register a másik operandus, ha előbbi, jön a ModR/M(+SIB).
Időközben elfogytak az egybyte-os opcode-ok, így a 486-os időkben már egy 0Fh byte-ot is fel kellett venni az új utasítások elé (pl. CPUID, de azért csak sikerült pl. 8 darab BSWAP utasítást elhelyezni a táblában...), mint 'alternative instruction set' prefix, ez később elvesztette prefix jellegét (a decode-nál nem volt mindegy P6-ig), az MMX és az SSE1 utasításokban mindben benne van. Az AMD a három dínó idején egyszerűen megduplázta a 0F prefix-et, így ők már akkor 3 byte-os opcode-nál tartottak.
Az Intel sem fért bele teljesen a 2 byte-os opcode-ba SSE1 esetén, ezért ők mást találtak ki. A skalár és vektorutasítások (ADDSS és ADDPS) abban különböznek, hogy a skalár előtt ott egy REPZ prefix, innen ugyanaz a formája, mint a vektoros alaknak.
De az SSE2-t is ábrázolni kellett valahogy, az megint több, mint 140 utasítás, itt az 66h adatméret-váltó prefixet tettek az SSE1 és az MMX megfelelő alakjai elé. De hogy ne legyen egyszerű, a skalár floating-point SSE2 előtt nem 2 prefix van (66h és REPZ), hanem csak egyetlen REPNZ.
Az egészet fejeljük meg 64 bitben egy REX prefix-szel, hogy a plusz 8-8 általános és XMM registerhez hozzá tudjunk férni. Mindezek mellett az AMD és az Intel is bizonyos esetekben azt ajánlja, hogy NOP műveletek helyett a kód (cikluskezdés) 16/32 byte-os határra illesztését inkább az opcode-dal együtt nem értelmezhető prefix-ekkel tegyük meg (pl. x87-műveletek elé betett REPZ prefix-szel), mert a NOP-pal szemben ezek nem foglalnak macro-op és micro-op helyet...
A kód a kódban, tehát hogy egy ugró utasítás célja egy másik utasítás azonnali értékének valamely belső byte-ja, ami onnan önmagában is értelmes utasítás, még 8 éve is egyetemi vizsgatétel volt assembly-ből.
Nagyon egyszerűen: code segment az alapméretet adja, akárhány prefix lehet az opcode előtt, az opcode mondja meg az azonnali érték létét és hosszát, valamint, hogy van-e ModR/M byte, a ModR/M mondja meg, hogy van-e SIB byte, és utóbbi kettő, hogy van-e a címhez is azonnali érték. Mindezt módosítják a prefixek.
Erre mondják azt sokan, hogy ki kellene dobni az egészet a fenébe, és egy teljesen új (lehetőleg regularized instruction field alapú) utasításkészletre áttérni.
SSE2+ persze, addigra már megártott a sok .PDF, amit aznap olvastam
[mod]: ...ha csak egyszer sikerülne pársoros hsz-t összehozni.
[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
Mivel a ModR/M byte mind a 256 féle lehetősége értelmes, a SIB byte 256 féle lehetősége ugyancsak, illetve a prefixek és 1 byte-os opcode-ok egyesítve megintcsak kitöltik majdnem teljesen a 0..255 teret (egy-két üres hely lehet már csak benne, a REX prefix-nek is találtak még üres elemet, ezen kívül a 0Fh prefix és két segment override prefix jött be összesen utólag 8086 óta, mindkettő 386/486 alatt), azonnali értékek és címeltolások bármik lehetnek, így gyakorlatilag tetszőleges belépési pontban értelmes utasítás találtható.
Az utasítás meghatározásához pontos belépési pontra van szükség, lehet ez ugrás, CALL, RET, INT célja, vagy az előző utasítás vége.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
#663
VaniliásRönk
nagyúr
dezz
#662
VaniliásRönk
nagyúr
-
#674
VaniliásRönk
nagyúr
dezz
#671
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ú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.
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest