- Honor Magic V5 - méret a kamera mögött
- Sony Xperia 1 VII - Látod-e, esteledik
- Mindenki Z Fold7-et akar
- Minden a BlackBerry telefonokról és rendszerről
- Szuperkijelzővel készül a Huawei Mate 80 RS
- Android alkalmazások - szoftver kibeszélő topik
- Samsung Galaxy S24 FE - később
- Új Trónok Harca telefon érkezik
- Milyen okostelefont vegyek?
- Yettel topik
Hirdetés
Aktív témák
-
#45
Pizzafutar
aktív tag
tocsa
#42
-
tocsa
senior tag
Ja. Ez jó kérdés, hogy pontosan mit jelent a mikrokód.
Számomra olyasmit jelent, hogy egy assemblynél is jóval alacsonyabb ''nyelven'' leírt utasításokkal egy algoritmus/program. Amit értelmezni tud a prociban egy logika. Az program lehet persze egy dekódolt mikroutasítás végrehajtása is. Miért ne. De ezen a programozható területen gondolom lehetnek adatok is feltételezésem szerint.
Utána kéne járnom a dolgoknak, ha lesz időm rá. -
Fentebb azt próbáltam leírni, hogy a gyakran használt, egyszerű utasítások simán fordítódnak (egy ciklus alatt kidobja a dekóder), de a komplex utasítások mikroutasításait ROM-ból szedi. Talán ezt a ROM-ot lehet felülbírálni feltöltéssel.
Nekem a mikrokód=mikroutasítások, de lehet, hogy magyarul nem (nem emlékszem már a digit ezen részére pontosan). Intel doksiban download microcode néven fut az upgrade, ezért tettem a fenti egyenlőséget. -
tocsa
senior tag
Azt tudjuk, hogy mikroutasításokra bomlanak az utasítások. Méga számunkra legegyszerűbbnek tűnő is. Már csak a pipeline miatt is szükséges.
De a mikroutasítások mikrokódban lennének? A mikrokód egy plussz indirekciót jelentene a végrehajtás során (pont amiatt, hogy változtatható). Ezáltal véleményem szerint lassabb az utasítás végrehajtás, mintha valami nem mikrokódos lenne. Lehet, hogy nincs igazam. Úgy gondoltam, hogy egy olyan elemi művelet, mint egy regiszter kiolvasása, vagy egyel növelése változtathatatlanul be vannak drótozva, és ki vannak optimalizálva a sebesség miatt. Mondjuk pont a pipeline elrendezés miatt előfordulhat, hogy egy stage ideje úgyis meghatározott, és egy nagyon egyszerű utasítás lehet, hogy belefér időben mikrokódosra az indirekció miatt.
Mi a véleményetek? -
-
-
mr_ricsi
veterán
válasz
Flashcash
#15
üzenetére
''Az Intel weboldalán megjelent dokumentum szerint nem kevesebb mint 31 olyan hiba van még a vállalat Prescott ... Pentium 4 processzoraiban, melyeket napjainkig nem javítottak ki.
a 31 darab még javítatlan probléma igen soknak mondható''
Összehasonlításul: az AMD TBredB-s procikban 8db ilyen hiba van. -
Biztosnak nem mondhatjuk, hiszen ezt csak a fejlesztők tudhatják...
Szerintem azért majdnem biztos, mert sok elemi részre lehet bontani. Betöltés, kiírás, cím növelés/csökkentés, számláló csökkentés és tesztelés (meg persze flag állítás). Másrészt pedig írták még a régebbi doksikban, hogy kerüljük ezeket a komplex utasításokat, mert lassú a dekódolásuk (a rep-es változatok persze hatékonyak, mert csak egyszer kell dekódolni).
Ha úgy vesszük, akkor már a K6 és a Pentium Pro óta mikrokódot futtatnak ezek. Lefordítják az x86-os utasításokat mikroutasításokra, és azokat futtatják. A primitív utasításoknak egy, de a komplex utasításoknak egy sor mikroutasítás felel meg, amit ROM-ból olvas.
Ha jól emlékszem, az AMD doksikban benne van, melyik komplex, melyik nem.
Egy jó oldal: [L]http://chip-architect.com/[/L] -
-
Szerintem mivel a hiba a movs utasításnál jön elő, és az teljes biztossággal mikrokódos, ezért némi teljesítmény rovására pl. beiktatnak plusz mikroutasítást a movs kódjába, ezzel már nem abban az állapotban lesz, ami előidézi a bug-ot. Nem teljesen szar a pipeline, hanem csak a csillagok nagyon rossz együttállásakor hibázik.
-
#33
tocsa
senior tag
Pizzafutar
#31
tocsa
senior tag
válasz
Pizzafutar
#31
üzenetére
De nem hiszem, hogy a retire vagy OOO logika abban van. Meg azt sem, hogy mind a sokszáz utasítás végrehajtási programja ott van. Lehetetlen. Annyira gyorsnak kell lenni a procinak, hogy ezeknek a cuccoknak beépítettnek kell lenni.
-
tocsa
senior tag
Tudom, asszem Linux alatt I2C és SMBus cuccokkal lehet is olvasni.
Nade az _nagyon_ pici része a procinak (?), csak bizonyos dolgok vannak benne. Az utasítás végrehajtások logikája, vagy az OOO (Out-Of-Order Exec Unit), retire unit logikája nyilván nincs benne. Akkor az egész CPU csak egy nagy tároló logika lenne. Akkor már majdnem egy transmeta proci lenne az egész. A proci legnagyobb része hardwired. -
Már egy ideje a Pentiumokat is lehet ''felújítani''. Van külön hely mikrokód feltöltéshez. Azért kell ezt a BIOS-ba rakni, mert ez minden kikapcsoláskor elfelejtődik. Gondolom AMD-éknél is van mikrokód frissitési lehetőség (már egy ideje nem olvasom a data sheet-eket). A movs utasítás pedig komplex, így én elég valószínűnek tartom, hogy mikrokód patch-csel jól fog menni (ha lehet patch-elni AMD-éknél).
-
WN31RD
addikt
A buszfigyelgetés nyilván kivitelezhetetlen. :)
Nem tudom, ezt a hibát hogyan akarják orvosolni, de a többi hasonló esetben jellemzően a BIOS letilt a prociban valami olyan feature-t, ami nélkül nem jöhet elő a hiba.
Kérdés, hogy az ilyen letiltások mekkora teljesítménycsökkenést okoznak... mert ugye nem véletlenül rakták azokat a feature-öket a prociba.
Az eredeti hírben van egy link az AMD errata doksijára ([L]http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25759.pdf[/L]), érdemes átböngészni. -
Nem kell megítélni a hiba súlyosságát.
Én azt ajánlottam hogy objektív legyen az oldal, tehát ha az AMD-nél 1db bios 'frissítéssel javítható' hibáról a főoldalon több példányban olvashatok, akkor az Intel Prescott 31db hibájáról miért nem látok semmit?
Azok nem olyan súlyos hibák? :) -
rog
addikt
az lehet hogy szerinted nem erről van szó. de világ összes cikke a témában erről ír. hogy van ez a hiba, és hogy emiatt a bios patch-eket sorban készítik a cégek.
ha nem érinteé a bios-programokat a hiba, akkor gondolom viszonylag kevés cég adna ki javítást a biosához miatta. -
tocsa
senior tag
válasz
Flashcash
#24
üzenetére
Ezt ne várjuk el a PH!-től. Nem ők itélik meg, hogy mi a súlyosabb hiba. Ez most tényleg annak mondható, ezért van ez csak felkapva. Az F00F bug idején a Pentium került reflektorfénybe, pedig abban az időben az MADknek is volt persze ugyanúgy hosszú erratajuk, csak egyik sem volt olyan súlyos hiba.
A lényeg az, hogy mi értünk hozzá, nem parázunk be, tudjuk, hogy nincs semmi komoly gond. -
tocsa
senior tag
Szerintem nem erről van szó, mert ha ez lenne a szituáció, akkor a szóban forgó BIOS-os gépek mind eléggé faygtak volna. Itt egy laboratóriumi körülmények között reprodukált hibáról van szó. Azért nincs ennél nagyobb botrány, mert ugy néz ki, hogy a hiba előállásához szükséges csillagok szerencsétlen együttállása mindennapi gyakorlatban nem áll elő. Lehet hogy Parci assembly szemével durva hiba (szerintem is), de ha gyakorlatban is előfordulna (nem csak laborban), akkor nagyobb botrány lenne.
A hibából úgy veszem ki, hogy talán az elágazácsbecslés, Out-of-order-execution ill. retire logikákban lehet a hiba. És nem a REP MOVSB instruction végrehajtásában. És akkor ez lehet, hogy esetleg máskor is előjöhet. Ezért fontos az AMD-nek majd későbbi steppingekben sürgősen javítani a hibát.
Még a compilerek patch-elésével lehetne workaroundolni a cuccot, hogy azok toldjanak be a string művelet elé kamu utasításokat. -
Én ott még ilyen szavakat is látok a prohardver hírben hogy Opteron/lefagyás.
Nekem az a véleményem ha már ezzel a témával a főlapon foglalkoztok akkor az AMD 1db hiba mellett az Intel-ről is készítsetek egy hasonló hírt, így lesz objektív az oldal.
Valójában meg egyiknek sem kellene hírnek lennie. :) -
tocsa
senior tag
Valami szekértő elmondhatná, hogy egy ilyen hibát hogyan lehet BIOS-ból orvosolni.
Nekem csak óriási hack-ek jutnak eszembe:
- a chipset passzívan figyeli a az adatbuszt, és hogy milyen utasítások áramlanak rajta
- valahogyan figyelia proci DF falg értékét is (?)
- figyeli az RCX értékét is valahogy, hogy 1 és 20 között van-e
- ha DF=1 (vissza irányú a string művelet) és jön egy MOVS, előtte REP perfixxel
- és mindezek előtt az errata-ben említett utasítások voltak (BOUND, CLI, LDS, LES, LFS, LGS, LSS, IDIV, and most microcoded x87 instructions), akkor közbeavatkozik
Már ennek az esetnek a figyelése is baromi bonyolult, mert a mobo nem lát bele a prociba. Sőt, talán lehetetlen is.
És hogyan avatkozik közbe? Bead valami NOP-ot vagy más utasítást sutyiba a procinak, hogy a retire logikát egy kicsit siettesse? De akkor elromlik az IP értéke.
Ezt nem tudom elképzelni. -
rog
addikt
nekem tök úgy jön le a cikkből, hogy a cpu hibáját majd a bios módosításval korrigálják, és innentől minden jól fog működni.
pedig inkább csak arról van szó, hogy a most használt bios-okban van egy olyan kódrész, ami ezt a hibás működést előidézi, és azt javítják ki a gyártók az amd útmutatásai alapján.
ettől még előfordulhat, hogy valakinek a programja, oprendszere is tartalmaz olyan kódot, ami előidézi ezt a problémát.. -
Erasmus
őstag
válasz
Flashcash
#18
üzenetére
Héló, én nem téged kritizáltalak, hanem a hírt (a szerzőjének is írtam, btw).
Hogy ki a szenzációhajhász, azt meg a hírcímek összehasonlításából döntse el ki-ki maga:
''Orvosolták az AMD64-processzorok apró hibáját''
vs.
''Tucatnyi javítható és javíthatatlan hiba az Intel 90 mikronos technológiával gyártott Pentium 4 processzoraiban''
:)
üdv, -
tocsa
senior tag
Ne hidd, hogy jobb lenne a hibaszámban a NorthWood. Maximum azért lehet jobb, mert későbbi revizió, ezért az _ismert_ hibák egy részét már kijavították. A Prescott és a Northwood is annyira nagy komplexitású már, hogy ugyanolyan gyakori lehet bennük a hiba. Meg az AMD-ben is.
Hangsúlyozzuk, hogy itt (pl Prescott 31 hibája) az ismert hibákról van szó.
Kb ugyanaz a helyzet mint a szoftvereknél. Csak itt sokkal nehezebb a helyzet a fixálással, mert nem lehet egyszerűen egy patch-el kijavítani. A BIOS javítás valszeg valami orbitális hack workaround a dologra.
Kivétel lehet a Transmeta, ahol ha valahogy pacth-elik a mikrokódit, akkor kijavíthatják kvázi szoftveresen a ''hardver'' hibát.
A processzorok ma már annyira sok állapotot vehetnek fel, hogy a tökéletes letesztelésük gyakorlatilag lehetetlen (vagyishát kivárhatatlan). Ehelyett heuristikákkal és okos logikákkal próbálják őket tesztelni, de néha nem sikerül tökéletesn. -
-
Erasmus
őstag
válasz
Flashcash
#15
üzenetére
Gyerekek, nyugalom! Erőteljesen szenzációhajhász a hwsw-n megjelent hír. MINDEN ilyen bonyolultságú processzor számos kisebb-nagyobb bugot tartalmaz. Ezekből jó esetben egyik sem lesz olyan komoly, mint például a Pentium FPU-bugja annak idején. Ezeket többnyire újabb revíziókban javítják, de ha nem muszáj, nem módosítják a chipet, mert az értelemszerűen nem kevés pénzbe kerül, ezért inkább írnák egy BIOS-t, amellyel megkerülhető a probléma.
Ha itt megnézitek például, a Willamette/Northwoodban 91 darab bugot fedeztek fel (és akkor még nem beszéltünk azokról, amelyekről nem is tudnak): [L]ftp://download.intel.com/design/pentium4/specupdt/24919950.pdf[/L]
Tehát itt egyáltalán nem egyedi esetről van szó. Hogy mennyire komolyak a Prescottban lévő hibák, azt persze én nem tom, de az is biztos, hogy az idézett hír írója sem.
üdv, -
A Prescottról is megjött a hibalista:
''Az Intel weboldalán megjelent dokumentum szerint nem kevesebb mint 31 olyan hiba van még a vállalat Prescott -- 90 mikronos gyártástechnológiával készült -- Pentium 4 processzoraiban, melyeket napjainkig nem javítottak ki. Amint arról hírt adtunk, a rivális AMD Opteron és Athlon 64 processzorai egy hibájához adott ki egy szoftveres frissítést tegnap.
Az Intel processzoraiban talált hibák egy része BIOS frissités segítségével javítható, mások azonban nem orvosolhatók ilyen módon, csupán a processzorok egy következő revíziójában javíthatják ki őket. A 31 eddig nem javított hiba stabilitási és teljesítménybeli gondokat okozhat.
Minden piacra dobott processzor tartalmaz hibákat, melyeket a gyártók folyamatosan javítanak BIOS frissítések segítségével. Azonban egyes vélemények szerint a Prescottokban felfedezett hibák egy része meglehetősen komoly és a 31 darab még javítatlan probléma igen soknak mondható.'' -
hobizoli
nagyúr
válasz
rATdrAgOn
#10
üzenetére
Az benne volt am meg a Pentium Pro, a Pentium MMX es a Pentium II CPU-kban is, mivel ''csak'' '98 tajekan jottek ra...:U
CMPXCHG8B
''F0 0F C7 C8...8 byte, ami megrengette a vilagot''
Vmi PC-s ujsag cikk cime volt akkoriban (Ch*p? vagy PCW*rld?)
Errata lista egyebkent minden CPU-hoz van a gyartoknal, hol tobb, hol kevesebb
hobizoli -
rATdrAgOn
senior tag
-
Megnéztem a tech doksit... hihi :)
Ha fordított irányú ciklust futtatsz 1 és 20 közötti alkalommal, és neadjaég még egy szegmens regisztert is betöltesz előtte (LDS, LES utasítások), bukó...
Hát, ez NAGYON nem olyan dolog, amit lehetetlen lenne előidézni, sőt, mint ex assembly-s arc, elég komoly bugnak tűnik. Persze ki tudja.
Aktív témák
Hirdetés
- Samsung Galaxy A34 5G 128GB Kártyafüggetlen 1 év Garanciával
- Eladó szép állapotban levő Samsung Galaxy A22 5G 4/128GB fekete / 12 hónap jótállás
- Apple iPhone 16 Pro Max - Desert Titanium - Újszerű, Karcmentes,256GB
- Bomba ár! Lenovo ThinkPad T480s - i7-8GEN I 16GB I 256GB I 14" WQHD I HDMI I Cam I W11 I Gari!
- Telefon felvásárlás!! iPhone 11/iPhone 11 Pro/iPhone 11 Pro Max
Állásajánlatok
Cég: FOTC
Város: Budapest