Új hozzászólás Aktív témák
-
#95904256
törölt tag
válasz
#95904256
#157
üzenetére
Két utasításparamétert módosítva, úgy hogy ne legyenek közös, egyszerre írható memóriaterületek, a hiba nem jelentkezik! Vagyis a hiba csak akkor áll fenn ha két vagy több szál egyszerre próbálja meg módosítani a memóriában az egymáshoz közel lévő biteket. Van erre valami adat?
T3_START:
MOV RSI,[ADR_PUFFER]
MOV RCX,4*1024*1024*1024
MOV RBP,3*4*1024*1024*1024 ;***
T3_CYCLE:
BTS Q[RSI],RBP
ADD RBP,1 ;***
DEC RCX
JNZ T3_CYCLE
BTR D[THREADS],3
invoke ExitThread,0 -
#95904256
törölt tag
Sziasztok!
Napok óta szívok vele hogy eltűnik pár bit a memóriából, így csináltam egy tesztet:
- foglalj le 4GiB RAM-ot
- töröld a területet összes bitjét
- indíts el nyolc szálat
- mindegyik szál állítsa be minden nyolcadik bitet, szálanként egy bit különbséggel
- ellenőrizd hogy a 34.359.738.368 bitből mennyi maradt nullaNa most akárhányszor futtatom le ezt a tesztet, változóan olyan 200 ezer és 2 millió közötti számú nulla marad memóriában. Ez most programozói hiba vagy nem?
így néz ki egy szál kódja:
T1_START:
MOV RSI,[ADR_PUFFER]
MOV RCX,4*1024*1024*1024
MOV RBP,1 ;0..7 közötti érték, a szálnak megfelelően
T1_CYCLE:
BTS Q[RSI],RBP
ADD RBP,8
DEC RCX
JNZ T1_CYCLE
BTR D[THREADS],1 ;jelzés az utolsónak hogy mentheti a puffert
invoke ExitThread,0Egyelőre úgy tűnik ez a dolog akkor is jelentkezik ha a szálak ugyan egyszerre írják a memóriát, de a memóriaterületeik nem fedik egymást. Hol a hiba?
-
korner83
tag
Sziasztok!
8 magos gépet szeretnék venni, milyen configot javasolnátok? Alapvetően Intel párti vagyok jelenleg. Csak ram és CPU legyen a gépben erős, VGA elég csak valami alap (akár alaplapi, de komolyabb lapokban úgy sincs).
Kb a következőket szeretném, csak az alaplap (LGA771-es vagy 775-ös, skulltrail esetleg?) és processzor pontos típusával vagyok gondban (Xeon vagy sima Quad, esetleg Corei7?)
RAM: min 2x2 giga ram
CPU: 2xQUAD CORE valami (2,2-3Ghz között)
ALAPLAP: max bruttó 100e legyen - fogalmam sincs mi lenne jó 2 CPU-hozAki tud olyan weboldalt ahol 8magos gépeket teszteltek renderelő programokkal az írja meg PLS!
Olyan oldal is érdekel ahol 2 magos gépet lehet online összerakni és megrendelni.
Az egész configra a pénzkeret kb. bruttó 350-450e Ft, ebből kéne minnél nagyobb számítási kapacitást kihozni.
Használt gép/gépek is érdekelnek, akár 4 magos szerver is.
Előre is köszönöm a válaszokat!
KoRner
-
dezz
nagyúr
Akkor mégegyszer:
"Various forms of μops have long been the basis for traditional microcode routines used to simplify the implementation of a particular CPU design or perhaps just the sequencing of certain multi-step operations or addressing modes. More recently, μops have also been employed in a different way in order to let modern "CISC" processors more easily handle asyncronous parallel and speculative execution: As with traditional microcode, one or more table lookups (or equivalent) is done to locate the appropriate μop-sequence based on the encoding and semantics of the machine instruction (the decoding or translation step), however, instead of having rigid μop-sequences controlling the CPU directly from a microcode-ROM, μops are here dynamically issued, that is, buffered in rather long sequences before being executed."Tehát itt nem történik más, mint hogy ezek az újszerű (vs. tradicionális) mikrokód-rutinok nem real-time vezérlik a proci bizonyos elemeit, hanem késleltetve! Ennyi!
Vagy szerinted azok is hülyék voltak, akik ezt az oldalt szerkesztették???
-
dezz
nagyúr
Miért nem, tekintve, hogy "amik a későbbiekben hasonlóan vezérlik az ALU-kat és a többi vonatkozó egységet (hasonlóan, mint korábban a klasszikus horizontális mikrokód)."?
Ha jól látom (sajnos indoklást nem mellékeltél), mert szerinted a "mikrokód" kifejezés semmi mást nem jelenthet, mint az egész proci összes microcoded elemének vezérlésének összességét kitevő "programcsomagot" (így tanultad, vagy mi). Azaz olyan egyszerűen nem létezik, hogy egy mikro-op-okból álló rutin fajtáját tekintve mikrokód...? Hát szerintem ez nonszensz!
"- Mit írsz, mikroprogramozó?
- Mikrokódot.
- Ez a 20 sor itt egy proci teljes mikrokód-vezérlése!?" -
dezz
nagyúr
Hol írtam olyat, hogy mikrokód = 1-1 utasítás? Idézem magam:
"Kétféle micro-op létezik!
1., az egyik fajtából összeálló mikrokód a CPU sok alap-működését vezérli;""In a typical implementation a horizontal microprogram word comprises fairly tightly defined groups of bits. For example, one simple arrangement might be:
I register source A I register source B I destination register I arithmetic and logic unit operation I type of jump I jump address I"Ebből nekem erősen az jön le, hogy itt nincsenek külön adatok, hanem azok a microperarion részei. Rosszul jön le? Hasonlóan, gépi kódban is az instruction word része(i) az operandus(ok), amik lehetnek adatok is. Persze itt ott vannak a memóriában (v. cache) helyet foglaló adatok is, de azokat nem szokás a lényegi program részének nevezni. Persze pl. egy executable részei lehetnek (ha előre elkészített adatokról van szó), ha ilyen értelemben használjuk a "program" szót. Viszont ilyen külön adatokra nem látok utalást a wikis szövegekben. Persze el tudom képzelni, hogy itt is vannak pl. look-up táblák, de valamiért ezt nem tartották fontosnak a "microcode" lap szerkesztői... (Csak olyan értelemben szerepel a look-up table, hogy onnan kerülnek beolvasásra a micro-op-ok.) Most emiatt (tovább) alázni egy kicsit erős (már kákán csomót keresés).
Szerinted a "mikrokód" kifejezése csak olyan értelemben lehet használni, hogy "egy proci vezérlésének összessége, mindennel együtt"? Nem csak ilyen módon használva lehet vele találkozni, hanem egy-egy mikrokód-rutin is "mikrokód", ami a fajtáját jelenti.
"A belinkelt, SZVSZ masszívan egyértelmű es kezdetben igencsak 'gyengéd' helyesbítésekre meg villámgyorsan átváltottál agresszív kismalac módba."
Nagyon sajnálom, hogy nem érted, amiről itt gagyarászok már egy ideje, és nem tudod beleképzelni magad a helyembe (adott "mindsettel" olvasni egy szöveget, ami egybevág azzal).
Ráadásul, mint kiderült, nyugodtan lehet úgy is értelmezni (és nem csak én teszem), hogy az is mikrokód (egy-egy mikrokód-rutin, tehát mint program-fajta), amit a dekóder egységek kipumpálnak magukból, és amik a későbbiekben hasonlóan vezérlik az ALU-kat és a többi vonatkozó egységet (hasonlóan, mint korábban a klasszikus horizontális mikrokód). Ilyen értelmezésben az a bizonyos mondatom nem volt hülyeség, és nem arra vallott, hogy abszolút fogalmam sincs, mi fán terem a mikrokód, és mire szolgál (low-lever vezérlése a proci egyes alegységeinek).
All-in-all, nem érdemeltem meg azt a lekezelő stílust (és ha úgy vesszük, 1-2 dologban igazam is volt). Ezen háborgok itt, nem máson. Nem én játszom itt az eszem, és beszélek nagyon magas lóról, hanem ti... Ezen gondolkozz csak el!
-
Rive
veterán
Jááááj.
A mikrokódban előfordulhatnak olyan uOPok is, amiket a dekoderek is kepesek kinyomni magukbol (meg olyanok is, amiket nem képes). De a mikrokod ennel ugyanis joval tobb - az ugyanis programcsomag. Meg mellé még adatok. Ezt keverted össze utasitasokkal. A belinkelt, SZVSZ masszívan egyértelmű es kezdetben igencsak 'gyengéd' helyesbítésekre meg villámgyorsan átváltottál agresszív kismalac módba.
Hát b+.
Ebben a témában inkább ne okoskodj többet, hanem kérdezz. A felhozott idézeteid a megfelelő ismereti háttér hiányában csak lógnak a levegőben. Semmi masra nem alkalmasak, csak a dolog összezutymolasara.
Szoval a mikrokod ma az a (dekoder képességeit joval meghalado uOP-repertoárból osszeállítható) programcsomag, ami az osszetett gepi kodu utasitasok illetve specialis muveletek elvegzeset vezerli. Ezen felül olyan adatok kupaca, amik a processzor belso mukodeset meghatarozzak - az LS egysegtol a gyorsitotarakon, interconnecten, VE-ken es belso buszokon keresztül a várakoztatoallomasokig.
Szoval, meg egyszer, nem utasitas, hanem komplex programcsomag. -
dezz
nagyúr
Ja, és még valami. Ti bizonyára suliban tanultatok a (klasszikus) mikrokódról, hogy ilyen jól tudjátok a leckét. Amikor én keztem az asm programozást, nagyjából 25 éve (júj, biztos ez is "önfényezés" -- lenne, laikusok között; programozók között szerintem nem az, csak egy egyszerű tény [egyébként nem vagyok annyira öreg, csak korán kezdtem]), szerintem még egyetemen sem tanítottak ilyesmit. Azoknak a prociknak, amikkel akkor a hétköznapokban találkozni lehetett, legalábbis tizenévesként (6502/6510, Z80), közük nem volt ehhez. Akkor már létezett a 8086, ami (mint most utánanéztem) már mikrokód-vezérelt volt, de csak igen drága IBM PC-kben volt, amiket max. nagyobb cégek engedhettek meg maguknak. Létezett a 68000 is, amivel egy kicsit később ismerkedtem össze, de sehol egy sor nem volt ilyesmiről a manualokban, hogy mikrokód-vezérelt, én legalábbis nem emlékszem ilyesmire. És igazából sosem volt szükségem erre az információra. Aztán jöttek a superscalar procik, meg más efféle dolgok, de a mikrokódról továbbra sem sok említés volt. A következő infó, ami eljutott hozzám, az alvégre, hogy már nem az alap gépi kódot hajtják végre a procik, hanem azok RISC jellegű utasításokra konvertálódnak először, azaz uop-ok sorára. Hát ennyi, ez van.
Mellesleg az is le van maradva (esetleg a tananyaggal együtt), aki a horizontális mikrokód ("On each tick of a sequencer clock a microcode word is read, decoded, and used to control the functional elements which make up the CPU.") világában él, lásd idézet az előzőben. Még csak a dekóderek sem feltétlenül mikrokód vezéreltek belülről. Persze azért nem veszett ki teljesen. ("After the microprogram is finalized, and extensively tested, it is sometimes used as the input to a computer program that constructs logic to produce the same data. This program is similar to those used to optimize a programmable logic array. No known computer program can produce optimal logic, but even pretty good logic can vastly reduce the number of transistors from the number required for a ROM control store.", "Modern CISC implementations, most notably the x86, implement most instructions and all addressing modes "in hardware"; microcode is still used however, for some really complex, or very special, instructions (such as CPUID), as well as for internal "housekeeping".)
-
dezz
nagyúr
A #109-es (a másikat teljes laikusnak beállítva) a Microcode@Wiki-re irányított, amely oldallal kapcsolatban lásd megjegyzésemet az előzőben. Mikrokód = decoder output uOP-ok sora feltételezésben olvasva nem derül ki a félreértés.
Így a #123 sem mond túl sokat (konkrétumok nélkül), és inkább csak arra volt jó, hogy megkérdőjelezze a felfogóképességemet.
A #127-es rész jó lett volna - ha ezzel kezded, de így már kicsit megkésett volt, másrészt úgy értelmeztem (a vita hevében), hogy nem csak az. (Itt már láttam, és jeleztem is, hogy látom, hogy tágabban kell értelmezni a mikrokód alkalmazási területét, így már nem ez volt a lényeg, hanem hogy elhárítsam a súlyos "vádakat".)A személyes jellegű megjegyzéseimet a fentiek váltották ki. Remélem, te is látod, hogy a vita nagy részét el lehetett volna kerülni. Nem kell a másikat teljes hozzánemértőnek beállítani, csak mert valamit rosszul tud (a hozzáértők látják, mit tud és mit nem, de a valódi nem-hozzáértők nem), és ha valami nem akar leesni neki (vagy úgy tűnik), akkor az sem feltétlenül azért van, mert idióta.
De egyébként talátam egy ilyet is a Discussion lapon (névvel):
"In the case of P6 and later x86 processors from Intel, I have the impression that some instructions are directly translated to uops by the hardware, and other instructions cause a sequence of uops to be fetched from on-chip store; those sequences of uops could be thought of as microcode. They might not be horizontal microcode that directly controls gates in the processor, but not all microcode is horizontal." -
Raymond
titán
"A névegyezés miatt azt hittem, az utóbbiak sora a mikrokód! (Holott ezeket max. uop-sequences-nek hívják.)"
"Nos azért valakinek lehetett volna annyi esze, hogy rájöjjön, mi a félreértés alapja, már bocs... "
Ajanlom figyelemdbe a #109-et...
"Ha ebben a cselesen csalóka "alapvetésben" olvassátok a Wikis mikrokódos oldalt (főleg az itt előbb idézett szövegeket), a helyembe képzelhetitek magatokat: azok látszólag megerősítik!... Teljesen egybevágónak tűnik úgy is a dolog. (Ezért nem volt túl hasznos tanács, hogy olvassam el mégegyszer.)"
#123: "...fogd mar fel vegre hogy mi minden az a mikrokod, mi mindenre jo es hogy hogyan/miert lehet valtoztatni."
#127: "Probald meg eloszor elfelejteni hogy szerinted a mikrokod az hogy az x86 utasitasokat a CPU leforditja micro-ops utasitasokra. Aztan olvasd el a wiki-t meg egyszer."
"Főleg, hogy én nem azt mondtam, hogy így van, és kész, mondjatok akármit, hanem próbáltam rájönni, hol a bibi, de csak beszólásokat kaptam."
Olvasd el magad utan meg egyszer miket irkaltal nekem...
Reszemrol ennyi volt. Orulok hogy eljutottunk a vegere.
-
dezz
nagyúr
Na, végre, valaki egyenesen válaszol. Miért nem lehetett ezt előbb? Akkor itt van a hiba!
Kétféle micro-op létezik!
1., az egyik fajtából összeálló mikrokód a CPU sok alap-működését vezérli;
2., a másik meg az, amik sorát a dekóder egységek "kipumpálják": ezek vezénylik le az ALU és társaik működését. (Ezekről beszéltem én.)A névegyezés miatt azt hittem, az utóbbiak sora a mikrokód! (Holott ezeket max. uop-sequences-nek hívják.)
Ha ebben a cselesen csalóka "alapvetésben" olvassátok a Wikis mikrokódos oldalt (főleg az itt előbb idézett szövegeket), a helyembe képzelhetitek magatokat: azok látszólag megerősítik!... Teljesen egybevágónak tűnik úgy is a dolog. (Ezért nem volt túl hasznos tanács, hogy olvassam el mégegyszer.)
Nos azért valakinek lehetett volna annyi esze, hogy rájöjjön, mi a félreértés alapja, már bocs... (Hiszen még egy vonatkozó blokkvázlatot is belinkeltem.) A fényezéses, bizonyítványos szöveg helyett... Főleg, hogy én nem azt mondtam, hogy így van, és kész, mondjatok akármit, hanem próbáltam rájönni, hol a bibi, de csak beszólásokat kaptam.
Álljon itt erre egy kis idézet ((innen)):
"Various forms of μops have long been the basis for traditional microcode routines used to simplify the implementation of a particular CPU design or perhaps just the sequencing of certain multi-step operations or addressing modes. More recently, μops have also been employed in a different way in order to let modern "CISC" processors more easily handle asyncronous parallel and speculative execution: As with traditional microcode, one or more table lookups (or equivalent) is done to locate the appropriate μop-sequence based on the encoding and semantics of the machine instruction (the decoding or translation step), however, instead of having rigid μop-sequences controlling the CPU directly from a microcode-ROM, μops are here dynamically issued, that is, buffered in rather long sequences before being executed." (stb.) -
Rive
veterán
Na de az eredménye IS mikrokód, ugyebár!?
Nem.Még egyszer, utoljára, éppen csak nem autós hasonlattal.
Úgy emlékszem, hogy szoftver felől indulva közelítetted a processzorokat - talán Motorola beágyazott rendszerek, vagy mi.
Tehát szoftveresen szólva amit fentebb csináltál, az olyan, mintha egy programozó-konferencián egy előadó összekeverné a kernel-imaget (ami itt programok és paraméterek együtt) a juzer-szpészben engedélyezett (!) utasításokkal.
Ha ezt még tovább akarod fényezni, hát tessék. Egyedül.
-
dezz
nagyúr
Na de az eredménye IS mikrokód, ugyebár!? Akkor nem teljesen rosszul tudtam, hogy mi az a mikrokód, ugyebár!? Csak azt nem tudtam, hogy más szerepe is van, ugyebár!? Legyél szíves ezekre a kérdésekre egyenesen, igen/nem-mel felelni!
És igen, elég meglepő a számomra, hogy pl. maguk a dekóder egységek is mikrokódot futtatva végzik a tevékenységüket.
Főleg, ha ilyeneket pl. olvasok (éppen Raymond által linkelt Wiki, amit persze már korábban is olvastam):
"Microprogramming (i.e. writing microcode) is a method that can be employed to implement machine instructions in a CPU relatively easily, often using less hardware than with other methods. It is a set of very detailed and rudimentary lowest-level routines which controls and sequences the actions needed to execute (perform) particular instructions, sometimes also to decode (interpret) them."(Az utóbbit itt a sometimes miatt úgy értelmeztem, hogy csak valamilyen különleges prociknál volt így [pl. talán Transmeta Crusoe, de lehet, hogy ott nem mikrokód szinten történt a code-morphing, nem tudom], nem pedig minden szóba jövő procinál.)
Aztán:
"The microcode usually does not reside in the main memory, but in a special high speed memory, called the control store. It might be either read-only or read-write memory. In the latter case the microcode would be loaded into the control store from some other storage medium as part of the initialization of the CPU, and it could be altered to correct bugs in the instruction set, or to implement new machine instructions."Szó sincs itt a proci egyéb bugjairól.
Továbbá:
"Microprograms consist of series of microinstructions. These microinstructions control the CPU at a very fundamental level of hardware circuitry. For example, a single typical microinstruction might specify the following operations:Connect Register 1 to the "A" side of the ALU
Connect Register 7 to the "B" side of the ALU
Set the ALU to perform two's-complement addition
Set the ALU's carry input to zero
Store the result value in Register 8
Update the "condition codes" with the ALU status flags ("Negative", "Zero", "Overflow", and "Carry")
Microjump to MicroPC nnn for the next microinstruction"Ezek itt olyan utasítások, amik a gépi kód (esetünkben x86/x64/stb.) végrehajtását szolgálják! (Kivéve persze az ugrást, ami univerzális.)
-
Rive
veterán
Most azt akarjátok itt kihozni, hogy fingom sincs arról, mi az a mikrokód, fingom sincs a procik belső felépítéséről, és így tovább?
"
A mikrokód az a kód, amire a proci (Intelnél egy, AMD-nél két lépésben) lefordítja az x86 kódot."Igen. Gyakorlatilag osszekeverted a forditas eredmenyet a forditas elvegzeset (is) vezerlo "koddal". Ennek a bizonyitvanynak a tovabbi fenyezeset minel hamarabb hagyd abba.
Gy.k. "mikrokod' mar a 8086-os proccokban is volt.
-
dezz
nagyúr
Mi a f@szról beszélsz?
Most azt akarjátok itt kihozni, hogy fingom sincs arról, mi az a mikrokód, fingom sincs a procik belső felépítéséről, és így tovább? 
Nézd már meg az évekre visszamenő hozzászólásaimat a témában, mielőtt te is így beszólsz! 
P.H.-val is már nem egyszer beszélgettünk a témáról, szerintem neki sem így jött le...És mivel Raymond is jelen volt, a velem szembeni megnyilvánulása az ő rosszindulatát bizonyítja!
Nézzétek már meg Raymond #109-esét! Totál lekezelő, leoltó szöveg, és úgy állítja be, mintha fingom nem lenne az egészről. Ez egy szemétség.
A hibás feltételezésem az volt, hogy csak konkrét x86 utasítások végrehajtásakor léphetnek ezek életbe, nem csak úgy ukk-mukk-fukk. Szánom-bánom bűnömet, nyakazzatok le.
Mutass egy hozzászólást itt tőlem, ami nem erre vall!Az sem igaz, hogy nem fogadom el, hogy valamit (nem semmit) nem tudok vagy nem jól tudok, a hsz-eim vonatkozó részeiben jeleztem, amiben bizonytalan vagyok.
-
dezz
nagyúr
Dehogy nem mozgattam a fülem botját! Még rá is kérdeztem, hogy hogy érted a mikrokód betöltését (tekintettel az első mondatodra, hogy a prociban lévő példányt nem lehet átírni).
Mellesleg olyasmit is a számba adtál, amit nem is mondtam, és olyasmit is nekiálltál megmagyarázni, amivel nem is mondtam ellent.
Mégegyszer: a "nem érted az egészet" egy hazugság, és nem baráti magyarázat. Nem gondolod???
Egyébként meg nemrég éppen Raymond barátunk játszotta el azt, amit itt emlegetsz: [link] Ráadásul egy jóval egyszerűbb kérdésben.
-
tcp
tag
öregem. nézd vissza, én is próbáltam neked elmagyarázni, hogy mi a helyzet, de füled botját sem mozgattad, csak próbáltál az én mondanivalómba is belekötni, hogy központi tárba mi? én általában legyintek arra, aki nem akarja felfogni, hogy mit magyaráznak nekik, a többiek próbálták veled megértetni. ahelyett, hogy hálás lennél, hogy magyaráznak neked, még neked áll feljebb.
mellesleg, nem hiszem, hogy a prohardver hozzászólásaink száma határozná meg a hozzáértésünket (szerencsére nem is így van), de ezt Te már világosan bizonyítottad (esetleg egy helyesírási hibát nem találtál valaki mondanivalójában, mert akkor még azt is előhozhatnád érvként).
-
dezz
nagyúr
Kösz, hogy ilyen autentikusan visszaadtad a beszélgetés menetét.
Jobb lenne, ha újoncként nem szólnál bele ilyen pofátlan módon. "bocs, a dolgoknak ehhez a részéhez nem értek"
Látom, az már magas a számomdra, hogy itt nem ezen ment a szó (ezt készséggel elismertem), hanem azon, hogy "nem érted az egészet". Ha javítás lett volna, semmi probléma nem lett volna.
-
tcp
tag
nem unalmas még ez az utóvédharc?
egyik mond valamit, ami nem jó, és a többiek kijavítják. erre egyik persze nem elismeri, hogy bocs, a dolgoknak ehhez a részéhez nem értek, köszi a javítást, hanem megpróbálja elmagyarázni, hogy amit eredetileg mondott az valójában annak az egyik apró hibával tűzdelt változata volt, amit mostmár ő is tud, de a többiek hülyék, hogy nem értették...
bakker, miért baj elismerni, hogy valamihez nem értünk/rosszul tudunk, és pont? (senki sem érthet mindenhez)
-
dezz
nagyúr
Hú, de nehezedre esett elismerni (persze most sem egyenesen), hogy az általad kiemelt mondat önmagában nem volt hülyeség, és nem arra vall, hogy nem értem az egészet. (Csak te szépen eléggé félreértetted, lásd alább.)
Direkt azért írtam, hogy "úgy emlékszem", mert nem voltam benne biztos, hogy teljesen korrek volt-e, amit írtam, és valamilyen normális kiigazítást vagy kiegészítést vártam volna rá. Nem azt, hogy "nem érted az egészet", ami nem igaz.
"A valosag viszont az hogy az osszes Intel es AMD procinal lehet (nem csak lehetett) updatelni es pont az a helyzet hogy mivel a microcode nem csak x86->MicroOP forditassal foglalkozik hanem a proci iranyitasainak egy resze is ebben van kodolva ezert tudja befolyasolni az egyes alreszek mukodeset."
Látod, az az állandó rosszhiszeműséged... Én sem azt írtam, hogy a mikrokód "x86->MicroOP forditassal foglalkozik" (azt a dekóder egységek csinálják), hanem a végeredmény maga a low-level végrehajtást vezérlő mikrokód.
Annyit kellett volna írnod, hogy 'nem csak az egyes gépi kódú utasítások végrehajtását vezérelheti a mikrokód, hanem bizonyos egyéb proci-tevékenységet is'. Ezzel le is lett volna zárva a téma, mindenféle séregetés és egyebek nélkül. De neked ugyebár kényszered van arra, hogy a lehető legrosszabb színben tüntesd fel a másikat.
"Egyszeruen arrol van szo hogy a logikai utak amelyek egyes funkciokat vezerelnek nem hardveresen vannak bedrodozva hanem update-elhetok"
Egy szóval sem mondtam, hogy mindezek be vannak drótozva. Hiszen a gépi kód mikrokódra fordítása is éppen azt jelenti, hogy nem bedrótozott a végrehajtás, hanem egy lower-level kód vezényli le azt, ami még update-elhető is. Azonban nem minden egyes bitje mikrokód-vezérelt egy modern procinak sem. Pl. a P.H. által linkelt szövegben is csak morfondíroznak arról, hogy mi ilyen, és mi nem.
Így pl. az is kérdés marad továbbra is, hogy a TLB vezérlése mennyiben mikrokód-alapú, és mennyiben bedrótozott kombinatoriális logika (aminek a végrehajtása sokkal gyorsabb, mint a mikrokód-végrehajtás). A Barcelonás eset alapján itt inkább csak némi konfigurációra van lehetőség, azzal a mikrokód-update-tel.
Egyébként maga a "mikrokód-update" kifejezés sem teljesen korrekt, mert azt sugallja, hogy egy meglévő kódot cserélnek le, holott adott esetben egy mikrokód-alapú átkonfigurálásról van szó, ami csak egyszer fut le, vagy csak bootnál.
-
Raymond
titán
Ertds mar meg hogy pedig valotlant irtal. Pontosabban azon oknal fogva hogy azt hitted a microcode csak a (idezem a #108-bol) "...az a kód, amire a proci (Intelnél egy, AMD-nél két lépésben) lefordítja az x86 kódot. Egyszerűbb utasításokat 1-2 mikroOP-ra, összetettebbeket (jellemzően pl. a média utasítások) többre." feladatot latja el, ezert allitottad hogy "Úgy emlékszem, egyes prociknál ez utóbbit lehet(ett) utólag update-elni. De olyan dolgokat, amikhez a proci elektronikáján kell változtatni, szerintem nem igazán lehet ilyen módon változtatni." A valosag viszont az hogy az osszes Intel es AMD procinal lehet (nem csak lehetett) updatelni es pont az a helyzet hogy mivel a microcode nem csak x86->MicroOP forditassal foglalkozik hanem a proci iranyitasainak egy resze is ebben van kodolva ezert tudja befolyasolni az egyes alreszek mukodeset. Egyszeruen arrol van szo hogy a logikai utak amelyek egyes funkciokat vezerelnek nem hardveresen vannak bedrodozva hanem update-elhetok. Ki- es bekapcsolhatsz reszeket vagy valtoztathatsz a routing-on. Tehat a #108-al nem a a problema hogy a microcode "nem kizárólag arra szolgál" hanem az hogy pont azt a reszet valasztottad ki a funkcio csomagjabol aminek semmi koze az itteni temahoz.
"A wikis linked éppen hogy csak megerősített, és egy sort sem látok benne a procis mikrokód update-ről..."
Akkor azt rohadtul nem olvastad el figyelmesen, mert amellett hogy pontosan leirja mi is a microcode meg a CPU-kra vonatkozo reszletes is ott vannak.
"P.H. linkje volt célravezető."
Az jo, csak megfigyelhetted volna hogy ahogy P.H. irta a hozzaszolasaban a wikis link az elmelet (ott van leirva mi az es mire jo) az ove pedig egy gyakorlati pelda a K8 vilagabol.
Szoval a fentiek fenyeben meg mindig azt tanacsolnam hogy probald meg megerteni a wikis szoveged. Aztan talan nem fogod kotni az ebet a karohoz.
-
dezz
nagyúr
Értsd már meg végre, hogy nem valótlant írtam (a #108-asban), hanem arról van szó, hogy a mikrokód nem kizárólag arra szolgál. Ennyi. Ez a vita sarkalatos pontja. Itt meg te kötöd az ebet a karóhoz.
A wikis linked éppen hogy csak megerősített, és egy sort sem látok benne a procis mikrokód update-ről...
P.H. linkje volt célravezető.
-
Raymond
titán
"Ez már no comment. Te meg azt bizonyítottad újra, azt lesed, hogy tudod alázni a másikat (engem v. másokat), nem pedig konstruktívan helyre igazítani."
Akkor sokkal tobb mindenre valaszoltam volna. Ha megnezed most is csak szoltam hogy rosszul tudod mert amit irtal egyszeruen nem volt igaz. Ahelyett hogy utannaneznel irtam megint valami valotlant. Erre megadtam a linket ami mindent elmagyaraz amit tudnod kellene a temarol, de ahelyett hogy elolvastad volna akkor kototted az ebet a karozhoz es meg most is itt tartunk ahol. Lehet nem minden hozzaszolasomat kene ugy venned mint valami tamadast az ellenfel reszerol.
-
dezz
nagyúr
Aha, olvastam. Hát, érdekes lenne, ha a procikban FPGA-s részek is lennének. És még érdekesebb, ha sikerülne vissza is fejteni, mit hogy csinálnak az update-ek, majd nekiállni proci-mikrokódban kódolni...
(Akkor talán nem bottal piszkálnám az x86-os procikat, ti. utálom az x86 ISA-t. 
) Bár most már mindegy, lényegében senki sem programozik asm-ben PC-n, meg máshol sem nagyon. (Még a mikrokontollereknél is a C lett a default.)Raymond: "Pedig de, az idezett (nem kipecezett) mondat mutat(ott) ra arra miert nem erted."
Igen, hogy egy részét nem értettem, de nem azt, hogy az egészet nem értem. Van egy kis különbség, nem gondolod? (Többek között az egyik sértés, a másik nem.)
"Ezen hsz szakmai reszei is bizonyitjak hogy meg mindig nem teljesen tiszta. Probald meg eloszor elfelejteni hogy szerinted a mikrokod az hogy az x86 utasitasokat a CPU leforditja micro-ops utasitasokra. Aztan olvasd el a wiki-t meg egyszer. Annal szebben nem lehet leirni."
1. Nem szerintem az, hanem tény szerűen az IS mikrokód.
2. Ha figyelmesebben olvasod, láthatod, hogy itt már nem exkluzív módon csak ezt vettem számításba.
3. Csak az a kérdés, hogy a TLB-vezérlés az egy fixed function egység (aminél pl. 1-2 paramétert lehet csak állítani, vagy legrosszabb esetben részben vagy egészében letiltani, mint az a Barcelonánál történt elvileg), vagy szintén kód-vezérelt."De ha egyszer nem erted basszus es minden ujabb hozzaszolassal bizonyitod ezt??"
Ez már no comment. Te meg azt bizonyítottad újra, azt lesed, hogy tudod alázni a másikat (engem v. másokat), nem pedig konstruktívan helyre igazítani.
-
Raymond
titán
"Tehát, semmi probléma nem volt azzal a mondattal (önmagában), amit kipécéztél, és indokolatlan volt az a szöveg is, hogy nem értem az egészet... Nagyrészt teljesen tiszta előttem."
Pedig de, az idezett (nem kipecezett) mondat mutat(ott) ra arra miert nem erted. Ezen hsz szakmai reszei is bizonyitjak hogy meg mindig nem teljesen tiszta. Probald meg eloszor elfelejteni hogy szerinted a mikrokod az hogy az x86 utasitasokat a CPU leforditja micro-ops utasitasokra. Aztan olvasd el a wiki-t meg egyszer. Annal szebben nem lehet leirni.
"Na szóval lehetőleg spórold meg az ilyen "nem érted az egészet"-eket, ha lehet..."
De ha egyszer nem erted basszus es minden ujabb hozzaszolassal bizonyitod ezt??
-
P.H.
senior tag
Kissé lejjebb:
"There may also be a hidden danger to altering K8 microcode without complete information. It is possible (though very unlikely) that the microcode could electrically reconfigure signal routing in a fashion similar to FPGAs, for instance to cut off defective logic and reroute signals to redundant arrays. This approach has been used in the past and the AMD patents even suggest it."
És a legfontosabb:
"Adding useful new instructions to the ISA is therefore unlikely; at best we could enable a previously undefined opcode to execute a few lines of uops and return. The primary purpose of microcode patching is to modify or disable defective functionality, rather than add new features."
Nem kell sok képzelőerő ahhoz, hogy egy-egy újabb, gyorsabb megoldás mellett a korábbi, "biztonságos" viselkedés is benne van a CPU-ban, amit aktiválni lehet ezen módszerrel.
("Contact your AMD representative for information on a BIOS update."a jelenlegi Revision Guide-ban is, máshol viszont egyértelmű utalások arra, hogy mely MSR-t kell átállítani) -
dezz
nagyúr
Na itt van a lényeg:
"Modern x86 microprocessors from Intel and AMD contain a feature known as "microcode update", or as the vendors prefer to call it, "BIOS update". Essentially the processor can reconfigure parts of its own hardware to fix bugs ("errata") in the silicon that would normally require a recall.This is done by loading a block of "patch data" created by the CPU vendor into the processor using special control registers. Microcode updates essentially override hardware features with sequences of the internal RISC-like micro-ops (uops) actually executed by the processor. They can also replace the implementations of microcoded instructions already handled by hard-wired sequences in an on-die microcode ROM."
Tehát, semmi probléma nem volt azzal a mondattal (önmagában), amit kipécéztél, és indokolatlan volt az a szöveg is, hogy nem értem az egészet...
Nagyrészt teljesen tiszta előttem.A bibi az volt, hogy azt feltételeztem, a jelenlegi prociknál nincs mikrokód (mind mikroOP-ok sora) update, és a mikrokód-frissítést itt az előbb idézett egyik szövegben szereplő "alternatív" szó-használatban értik. Ezt erősítette a teljesítmény-veszteség mások általi feltételezése is, mert általában a kijavított mikrokód megelőzi a teljesítmény-veszteséget, a helyes végrehajtás megvalósítása által. Továbbá, azt gondoltam, hogy egy TLB-vel kapcsolatos hibát (amit egy fixed function [és nem mikrokód-vezérelt, vagy más módon átkonfogurálható] egység elektronikai hibájának gondolnék) nem nagyon lehet mikrokód update-tel helyretenni (mert mit is update-el ebben az esetben az a mikro-kód update?). Mint emlékezhetünk, a Barcelonánál is részben vagy egészében le kellett tiltani... De persze lehet, hogy Intelnél máshogy van, pl. itt ez is külön mikrokód-vezérelt. Akkor viszont nyugodtan lehet, hogy bármiféle teljesítmény-veszteség nélkül orvosolható a probléma.
Na szóval lehetőleg spórold meg az ilyen "nem érted az egészet"-eket, ha lehet...
ps. nem teszem off-ba, mert végülis nem is az.
-
Raymond
titán
Olvass tovabb. Vagy meg egyszer. Vagy mit tudom en. Csak fogd mar fel vegre hogy mi minden az a mikrokod, mi mindenre jo es hogy hogyan/miert lehet valtoztatni. A lenyeghez tenyleg eleg a wiki link. Utanna ott a finom resz P.H. linkjeben. De az csak olyan mazsola, erdekessegnek.
Oliverda: ez a mai fiatalsag, rafinaltak mint a kockacukor...
-
dezz
nagyúr
Nos, olvasom, és ez a rész (a saját wikis linkedről) éppen azt támasztja alá, amit írtam, és hogy a mikrokód = mikroOP-ok sora:
"Microprogramming (i.e. writing microcode) is a method that can be employed to implement machine instructions in a CPU relatively easily, often using less hardware than with other methods. It is a set of very detailed and rudimentary lowest-level routines which controls and sequences the actions needed to execute (perform) particular instructions, sometimes also to decode (interpret) them. A machine instruction implemented by a series of microinstructions is thus loosely comparable to how an interpreter implements a high-level language statement using a series of machine instructions."
Nem tudom, a mi esetünkben nem erről van-e szó:
"Some hardware vendors, especially IBM, also use the term microcode as a synonym for firmware, whether or not it actually implements the microprogramming of a processor.[1] Even simple firmware, such as the one used in a hard drive, is sometimes described as microcode.[2] Such use is not discussed here."Szóval, itt a sima x86 (vagy más ISA) gépi kódot hívják szintén mikrokódnak... Ez eléggé félrevezető szóhasználat... És indokolatlan is.
Most megnézem a másik szöveget is.
-
dezz
nagyúr
Hova töltődik be az új mikrokód? Szerintem kizárt, hogy a főmemóriába, mert annak a kódnak sokkal gyorsabban rendelkezésre kell állnia a dekóder egységekben! Vagy ha úgy érted, hogy a proci pl. egy hibásnak bizonyult utasítás helyett a főmemóriából mikrokódot hajthat végre, hát ezt kötve hiszem... (Ha volna erre lehetőség, akkor az újabb fordítók közvetlenül mikro-kódra fordítanának, a több szempontból elavult x86 kód helyett!) Szóval, miféle mikrokódról beszélsz, amit a BIOS "betölt"?
update: mindezt úgy írom, hogy a "mikrokód"-ot mikroOP-ok sorának feltételezem. Most olvasom a linkelt szövegeket, amikből talán az derül ki, hogy a névhasonlóság ellenére másról van szó.
"Egyébként a microcode frissítésnek semmi köze a teljesítményhez olyan értelemben, hogy ha frissíted a microcode-ot akkor lelassul a géped."
Ilyet nem is írtam...
(#114) Raymond: Korrektebb és kevésbé ellenséges lett volna azt írnod: "ne keverd a mikrokódot és a mikroOP-okat!", vagy valami ilyesmi...
-
Raymond
titán
"Ha a szokásos, magadtól eltelt lekezelő stílus nyomása mellett maradna 1% "prociidőd", akkor látnád, hogy amit én írtam, az valójában ugyanaz, mint ami a linkeden olvasható..."
Ha elolvastad volna amit irtam es a link(ek)et ugy hogy raszansz 1% prociidot akkor latnad hogy a mikrokod messze nem az amit a #108-ban irtal es ezert marhasag az amit a #103-ban allitasz. Legyszives olvasd el a linkeket, most is leirtad ugyanazt amit elotte es ennek semmi koze a ahoz microcode update-el javitjak es kerulik meg a mai processzorok hibait.
A hozzaszolasomban egyebkent nem volt smmi lekezlo. Ideztem az elso modtatot amibol vilagos volt miert van a #103-ban vazolt problemad. Azert, mert a microcode tema nem teljesen vilagos elotted. Forditassal semmi bajom, nem is ertem mire gondolsz pontosan.
-
dezz
nagyúr
Ha a szokásos, magadtól eltelt lekezelő stílus nyomása mellett maradna 1% "prociidőd", akkor látnád, hogy amit én írtam, az valójában ugyanaz, mint ami a linkeden olvasható...
Nyilván a prociban nincs egy kis manó, ami kitalálja a megfelelő mikro-kódsort, ami az adott, esetünkben x86 utasítást hw szinten végrehajtja. Ezeket a CPU tervezői írják meg, miután belső ROM/EEPROM/FLASH-memóriákba kerül.
Ezek után, amikor működik a proci, akkor bizony éppen az történik, amit írtam: a proci a gépi kódot mikro-kódra fordítja. (Még az is stimmel, hogy az Intel 1 lépésben, az AMD meg két lépésben: először 2-2 mikrokódot tartalmazó [AMD terminológia szerinti] makroOP-okká.)
Lásd pl. ezt a képet! A Decoder egységek végzik a fordítást.
Vagy esetleg a "fordítás" szóval van problémád, és ezt eszkalálod "nem érted az egészet"-té?
-
tcp
tag
A mikrokódot lehet frissíteni, de persze a CPU-ban található példányt nem fogod újraírni.
Éppen ezért születtek különböző megoldások arra, hogy a mikrokódot mégis cserélni lehessen, és ennek segítségével a CPU szoftveres (mikrokód) és hardveres hibái javíthatóvá váljanak. Több féle megoldás is létezik rá, oprendszer megfelelő driverein keresztül, vagy a bios segítségével, a rendszer indulásakor a megfelelő (értsd újabb) mikorkód töltődjön be. Elég ha elindítasz egy linuxot, ott is mindjárt az elején lesz egy sor, hogy updating kernel microcode.Ez egyébként nem egy opcionális lehetőség a manapság használatos processzorokban -ahogy az eredeti cikk is írja -, minden CPU tele van hardveres hibával, amit a microcode segítségével javítanak, egyszerűen azért, mert ha minden hibát ki akarnának zárni akkor 10 évente jelenne meg új CPU, annyira összetettek az architektúrák, annyira nehéz 1-2 hibát kijavítani, hogy egyszerűen inkább kódból orvosolják, mint terveznek mindent újra az elejétől. Persze az újabb stepingekben azért javítgatnak ezt azt.
Egyébként a microcode frissítésnek semmi köze a teljesítményhez olyan értelemben, hogy ha frissíted a microcode-ot akkor lelassul a géped.
A probléma ezekkel a hibákkal tényleg az, ha a sajtó felkapja őket, és elefántot csinálnak a bolhából, azt sugallva, mintha a többi (más gyártók, architektúrák, vagy akár csak korábbi változatok), nem lennének szintén tele ilyen bugokkal. -
Raymond
titán
"A mikrokód az a kód, amire a proci (Intelnél egy, AMD-nél két lépésben) lefordítja az x86 kódot."
Ez megmagyarazza miert nem erted az egeszet. Nezz utanna a "CPU microcode"-nak es lon vilagossag
Megneztem az elso gugli linket (termeszetesen a wikipediat dobja ki mint altalaban) es szvsz eleg lesz ha azt elolvasod. [link] -
dezz
nagyúr
A mikrokód az a kód, amire a proci (Intelnél egy, AMD-nél két lépésben) lefordítja az x86 kódot. Egyszerűbb utasításokat 1-2 mikroOP-ra, összetettebbeket (jellemzően pl. a média utasítások) többre. Úgy emlékszem, egyes prociknál ez utóbbit lehet(ett) utólag update-elni. De olyan dolgokat, amikhez a proci elektronikáján kell változtatni, szerintem nem igazán lehet ilyen módon változtatni.
Szóval, lehet, hogy a Nehalemnél is van ilyen lehetőség, az adott problémát nem feltétlenül befolyásolja.
-
Oliverda
félisten
Sosem fog kiderülni hogy valóban igaz-e amit a javítással kapcsolatban mondtak vagy sem. Ha anno az első K10-ek is hasonló felállásban jöttek volna mint most az i7 (tehát először desktop) akkor az AMD is elhinthette volna, hogy (pontosabban a TLB) a hiba már régen ki lett javítva az akárhanyadik verziós AGESA-ban.
-
dezz
nagyúr
Amúgy nem tudom, milyen mikrokódos javításról beszéltek. Úgy tudom, a mai procik mikrokódja nem frissíthető utólag, és a BIOS-os workaround (ami asm, ill. gépi kód; intel terminológiában makro-kód) nem a mikrokódot frissíti, hanem pl. letiltja a nem működő funkciókat a prociban. (Ezért csökken bizonyos alkalmazásokban a teljesítmény.)
-
thearc
csendes tag
Hihetetlen, hogy már megint valami ratyit hozott össze az Intel. Megint csak félrevezetik a felhasználókat... Na jó, csak hülyéskedek.
Ha valóban (mikrokóddal) megkerülhetetlen hibák lennének, nem is került volna piacra a cucc. Ha mégis, akkor már tudnánk róla. -
dezz
nagyúr
Röviden: igen. x64-en a lassú emuláció nélkül futhatnak a korábbi programok is, akár együtt a 64 bitesekkel. Ráadásul Itamiumon -- a nagyobb peak IPC ellenére - az átlagos natív kódok is lassabban futnak, mert nehéz rá optimális kódot készíteni ezekből.
(#97) gV: Igen, a számára optimális kóddal, amit a uarch kialakítása miatt nem könnyű összehozni. És ennek tetejében ott van az alacsony órajel.
Jellemző, hogy az átlagos kódok 1.0/mag körüli IPC-vel futnak, így az x86-os procik 3.0-4.0/mag peak IPC-jét sem használják ki, nem hogy az Itaniumokét... Többmagos esetben, több és/vagy többszálas alkalmazásnál legalább a magok számával felszorzódik ez az 1.0 körüli érték. Miközben a nagyobb méret miatt az Itanium mindig kevesebb magos lesz.
-
P.H.
senior tag
Az Itanium a programozók álma (lehetne), már amennyiben azon komolyan nekiáll valaki hozzá közeli kódban programozni.
De ezt nem tette szinte senki, és a fordítók is csak a nekik megfelelő szinten tudnak kódokat alkotni rá. Itt halt meg: nem lehet manapság hardware-assist nélkül programkódot alkotni az időhatékony fejlesztési stratégiákkal, márpedig az Itanium enélkül épült. Majd talán valamikor előjön ez a személet megint...
És az Intel sem nagyon erőlteti már ezt a vonalat ezügyben (bár az Atom talán/mégis/egyszer visszahozhatná ezt... talán... Vagy talán mégsem.)Addig is minden erő megy és mennie is kell(ene) az x64-re, mert ez a fejlődés legkevesebb fájdalommal járó kényszerű, hatékony (és egyenes) módja a felhasználók számára.
-
64b0r
aktív tag
Az, hogy optimálisabb, az gyakorlati előnyt is jelent?
Én csak annyit tudok erről a dologról, hogy a számítási kapacitás már réges-rég kinőtte a 32 bitet, de olyan sok 32bites kód kering még mindig (windóznak hála) hogy túl nagy nyűg lenne lecserélni. Pl. haverom 2 éve használja AMD-hez a 64bites Xp-t, és úgy kellett összevadászgatnia hozzá annó a progikat (firefox, vlc stb) amik futnak 64 biten is. Én ezt túl sok melónak tartottam akkoriban, úgyhogy nekem azóta is 32bites a rendszerem (játékokat meg úgyis erre írták /lehet h még most is) -
Mercutio_
félisten
-
-
-
Abu85
HÁZIGAZDA
Régóta az AMD egyes technológiáit másolgatja az Intel ... ha viszont hivatalosan bejelentenék, hogy AMD technológiát licenszelnek, akkor bizza elismernék, hogy az AMD okosabban terelgeti a dolgokat.
Elég a látszatot fenntartani, hogy az Intel a legfejlettebb. Kedves szomszéd mondta, hogy a gimis számtechtanára nemrég áradozott az új Intel Core i7-ről. " ... Gyerekek, gondoljatok bele ez az első processzor ami integrált memóriavezérlőt tartalmaz. Az AMD mikor fog ide eljútni ??? ... "
![;]](//cdn.rios.hu/dl/s/v1.gif)
Én olyan híreket hallok, hogy a koherens busszal most keményen szívnak a kékek.
-
#65675776
törölt tag
A linkelt dokban a legelső (piacra sem került) rev hibalistája is benne van. A teljes lista 52 hibát tartalmaz, ebből jónéhány csak a C2-t érinti. A BA-ban 45 hiba volt, a C2-ben 22. Szóval ott van a lehetőség, hogy összehasonlítsa az ember a legelső Nehalem-et a legelső Barcelona-val.
dezz: Ráadásul a HT nyílt szabvány.
-
dezz
nagyúr
"csak rájöttek, hogy jobb lenne nekik is integrált memória vezérlővel végezni a dolgukat. Most ezen kell rágódni?"
Az csak egy dolog, csakhogy a HyperTransportot is lemásolták (ahelyett, hogy annak a rendje és módja szerint licencelték volna az eredetit, ami lényegében egy ipari szabvány), és a cache hierarhiát is.
"ehhez képest a Core2-k integrált memvezérlő nélkül is nyújtják a nem kicsi teljesítményt. Biztos jó hatással van a teljesítményre, de eddig megvoltak nélküle is."
Aha, desktopon, számolós, nem memória nyúzós, magok között nem sok adatot pakolgatós kódoknál. Szerver téren meg megfekszik az alkalmazások többségében.
-
P.H.
senior tag
válasz
#95904256
#79
üzenetére
Teljes rendszerszinten a leggyakoribb eset az, amikor a Present bitet törli egy mag, azaz amikor az OS eltávolít egy lapot a memóriából, kilapozza a page file-ba.
Magszinten hétköznapilag a legfőbb esetek a teljesítmény-csökkenésre a task-váltás és a Ring0-Ring3 váltás (kernelhívás), mert ilyenkor az adott mag nagyjából teljes TLB-jét érvényteleníteni kell (igyekezetek vannak arra, hogy kernelhíváskor ill. azonos process más szálára váltáskor ne legyen ilyen teljes törlés, mert azok memórialeképezése közös, ebben úgy tűnik, az AMD Address Space Number megoldása előremutatóbb, de jelenleg mindkettőnél csak a virtuális-valós OS közötti váltás megoldott, egy 1 bites kiegészítés formájában a TLB-ben).
Itt idéztem, hogy az Intel mely megoldást tartja teljesen biztonságosnak a TLB-bejegyzések megváltoztatásának közlésére, hozzátéve:
Alternate, performance-optimized, TLB shootdown algorithms may be developed; however, care must be taken by the developers to ensure that either of the following conditions are met:
• Different TLB mappings are not used on different processors during the update process.
• The operating system is prepared to deal with the case where processors are using the stale mapping during the update process. -
#95904256
törölt tag
Hali P.H.!
Van valami információd arról hogy ez a TLB tartalom változás milyen gyakran szokott előfordulni? Mert ha milliszekundumonként néhány nanoszekundumra "megáll" a teljes rendszer, akkor nem igazán látom értelmét hogy miért foglalkoznak a teljesítménycsökkentő hatásával.
-
#78
P.H.
senior tag
WonderCSabo
#70
P.H.
senior tag
válasz
WonderCSabo
#70
üzenetére
A nehézségeket éppen az okozza, hogy magonként két (külön adat- és utasítás-) TLB van, más nézőpontból nézve Intel-nél 3, AMD-nél 4, ha az első- és másodszintűeket külön számoljuk, amelyek tartalmát - ahogy akosf írta - minden pillanatban szinkronban kell tartani.
Kissé pontosabban ha egy mag módosít egy TLB-tartalomra hatással levő laptábla-bejegyzést, akkor a rendszerben lévő összes TLB-nek vagy - egy részének - törölnie kell a korábban történt olyan címfordításokat, amelyekre az az egy módosítás hatással van, addig nem lehet folytatni egyik magon sem a munkát (az időrendiséget fenn kell tartani). Bonyolítja a helyzetet, hogy a laptáblák bizonyos engedélyező biteket is tartalmaznak, a legismertebb és legújabb az NX-bit, amelynek beállítása után a rendszerben egyetlen egy olyan utasítás sem futtatható, amely ezzel a bittel jelzett memóriaterületen van (rendszerszinten egyetlen utasítás TLB-ben nem lehet olyan cím, amely ilyen memóriaterületre hivatkozik; ha van a módosítás pillanatában, azonnal el kell távolítani őket onnan, majd a következő kísérletnél, amikor ide betöltődne, hibát kell jeleznie a processzornak az OS felé). De ilyen engedélyező bitből jópár van, és ez process-enként bonyolódik, mert mindegyik program úgy látja, mintha csak ő futna a rendszeren; aztán bejön a képbe a virtualizáció is, ahol az OS-függő beállítások is váltakoznak.
Ezen időrendiség megtartásához praktikusan meg kell szakítani egy pillanatra a teljes rendszer munkáját (függetlenül attól, hogy hány mag vagy hány CPU van a rendszerben). Ez érezhető teljesítményvesztéssel járhat, ezért mindegyik gyártó igyekszik ezt a teljes leállítást az esetek lehető legnagyobb részében (~ megfelelő körülmények között) kikerülni, ebbe csúszik néha hiba. Ezt az igyekezetet jelzi, hogy ahogy nő a magszám, párhuzamosan került fókuszba a TLB-kifejezés, mára már szinte mindenki ismeri, pedig 386-ok óta van a CPU-kban.
-
#75
#95904256
törölt tag
WonderCSabo
#70
#95904256
törölt tag
válasz
WonderCSabo
#70
üzenetére
"Én nem értek hozzá, de nem lehetne úgy kiküszöbölni úgy a hibát, ha minden magnak külön TLB-je lenne?"
Ez nem oldja meg a problémát.
Mindegyik magnak minden pillanatban ugyanúgy kell tudni a virtuális memóriát összerendelni a fizikai memóriával. Ha valamelyik mag módosítja az összerendelést (operációs rendszer ott futó programszálja utasítja rá), azt a többinek is azonnal a tudomására kell hozni.
-
"az idő majd úgyis megmondja menyire jelentkezik a probléma élesben"
Nem lesz probléma élesben.
"Csak anno az AMD csúnyán megszívta, mert a sok hozzászóló beleképzelt mindent, és ez most sajnos meg is látszik a cég piaci helyzetén."
Hát, csodálkoznék, ha bármi köze lenne az AMD piaci helyzetéhez a TLB hibának...
-
orbano
félisten
a core architektúrája a p3 vonalát folytatja, és már a p4 alatt fejlesztették, a mobil vonalról jött át lényegében vissza az asztali chipekbe. már a pentium-m is nagyot szólt (főleg a dothan volt nagy istenkirályság), de a core (1) duo a yonah maggal még nagyobbat. ennek a vonalnak az újabb tagja lett a core 2, ami mobil vonalon (merom) kb 10-30% teljesítménytöbbletet hozott valamivel nagyobb fogyasztással karöltve. emlékszem már a yonah kijövetelénél rebesgették, hogy ezt az architektúrát fogják a p4 után visszahozni, és már akkor biztosra lehetett venni, hogy ez lealázza az AMD-t (hisz már a yonah is megtette, noha akkor még csak tuningolva).
-
#70
WonderCSabo
félisten
WonderCSabo
félisten
Én nem értek hozzá, de nem lehetne úgy kiküszöbölni úgy a hibát, ha minden magnak külön TLB-je lenne?
-
#95904256
törölt tag
válasz
#06658560
#68
üzenetére
Ha jól rémlik már régóta fejleszgetnek a Pekingi műszaki egyetemen is egy processzort ( ARCA, ARCA-II, stb. ) abból a célból hogy függetlenedjenek a nagy nyugati beszállítóktól. A jelenlegi leggyorsabb processzoruk egy 2GHz-es P4 teljesítményével vetekszik. Szóval nem olyan egyszerű egy ilyen architektúrát előteremteni...
-
oPalRx7
aktív tag
MajdnemOFF
Egyébként engem is csak az zavar az egészben, hogy anno AMD nagyon keményen megkapta a negatív sajtót, amit Intel jóval kevésbé kapja. Tény hogy intel sokkal pontosabb információkat adott(ok szivárogtatott) ki a hibáról, ezzel jobban megítélhették a hiba súlyosságát.. Anno phenomoknál sokáig keresgéltem, de nem találtam ilyen errata-t. bár 9500 1x se akadt ki (csak amikor megpiszkáltam az órajeleket, arra viszont azonnal kék)
/MajdnemOFF
Egyébként én már nagyon vártam a corei7-et mert végre modern lett az intel procija is. már nagyon csunyának tartottam az FSB életbentartását (oké 1-2 még 4 magnál se fontos igazából, de akkor is őskövület volt)
Megint offabb
másik dolog a core architectúra, ami gyanúsan gyorsan és hirtelen lett kész (és mintha egy egyetem már korábban el akart volna neki adni egy hasonlót - amit akkor nem kértek, de mégis lett saját verziójuk belőle) meg még az addig hajrázott HT is kimaradt (ezért is gyanús nekem a core)
/Megint offabb
most minden intel-tech benne van, így már helyes. gyors memo és SSD aztán víg nap
-
Atocha
senior tag
"Hasonlítsuk össze a két cég méretét, készpénzállományát, majd vizsgáljuk meg a történelmében a versenytörvényeket és az üzleti etika alapvető szabályait sértő magatartások számát... The winner is Intel!!!
"Ez tetszett, ezen nevettem egy darabig! Pedig teljesen igaza van ebben az egy mondtaban.
-
#06658560
törölt tag
Csak kerdeskent: nem lehet, hogy azert eltero a kezelese a ket problemanak, mert anno AMD kihozta kereskedelmi forgalomba a hibas termekeket, es sokaig semmit nem lehetett tudni rola, csak pletyka ment, intel meg a mar kereskedelmi forgalomba hozott termekeknel javitotta a problemat, igy gyakorlatilag eszrevenni nem lehetett volna?(A masikat sem lehetett volna eszrevennie persze munkakorulmenyek kozott)
A jelek szerint az integralt memoriavezerlonek akkor vannak ilyen nyugjei sok mag eseteben, hogy memoria hozzaferesnel osszeakadhatnak a dolgok?
akosf: vegyel kettot, vagy sokat ocsoe, mondjuk 1000 db-ot. Ugy mar barati aron is kapod.
-
#61
Mindreader
tag
Mindreader
tag
Ha valakit érdekel a cikkben említett dokumentum itt található!
-
Scalpel
senior tag
Egyébként nem értem, miért vagytok úgy kiakadva, hogy a szaksajtó nem szorongatta meg annyira az Intel tökeit, mint annó az AMD-ét.
Hasonlítsuk össze a két cég méretét, készpénzállományát, majd vizsgáljuk meg a történelmében a versenytörvényeket és az üzleti etika alapvető szabályait sértő magatartások számát... The winner is Intel!!!
Természetesen ez az üzleti magatartás nekem sem tetszik, egészen addig, amíg nem én ülök az Intel igazgatói bőrfotelében... De ettől fühhetlenül az Intel processzoraimmal sokkal elégedettebb vagyok, mint az AMD-kel... Ez van, sorry.
Ezek a hibák akkor sem érdekeltek, és most sem érdekelnek, főleg, hogy a laptopomat nem fogom két éven belül lecserélni, holmi Win7 kedvéért sem... főleg, hogy nem kell...
-
#65675776
törölt tag
-
mephi666
nagyúr
jó kis írás... amúgy komplett buglistát el lehet majd érni akkor idővel minden cpu-hoz? az nem lenne rossz... (persze olvasmányosabb változatban, mert szerintem a 100%-os töménységű angol szakszöveggel sokunknak problémája lenne)
amúgy meg ahogy írták: minden procinak rengeteg hibája van, ami azonnal nem derül ki, de attól sem kell félnünk, hogy sz@rt kapunk, mert a gyártók nem nagyon engedhetik meg maguknak, hogy hibás sorozatokat dobjanak piacra... inkább szerintem a hibák kiiktatási módja tudja meghatározni 1-1széria teljesítményét, itt eldőlhet simán 1-1generációnál, melyik oldalnak lesz összességében erősebb procija... a c2d vs x2 -ből a kékek jöttek ki jobban, de előtte a zöldek voltak sokáig nyeregben... igaz itt számos tervezési különbség is van a 2 vonal között, ami meghatározó... -
#55
Depression
veterán
Depression
veterán
Ezen az egy kiemelt TLB-n kívűl mennyi hibája van?
-
proof88
addikt
Az intel nagy igyekezetében, hogy lemásolja a Barcelonát ( ->Nehalem ), - írta Cagm^c, erre linkelted, hogy kis valóságalapja lehet. Erre írtam azt, hogy szerintem a külföldi cikk túlságosan úgy festi le az intelt, mintha rossz gyerek lenne (ezt kifelejtettem a hsz-emből, nem konkrétan neked mondtam).
De amúgy miért írtam badarságokat? Pár hónapja még az intel volt jobb helyzetben, ár/teljesítmény arányban, ez igazából nem tudom, változott-e, mert most csökkent árat az AMD. -
Blero2
tag
Köszönöm a többiek védelmező szavait, de nem szükséges.
Szerintem idősebb vagyok mint te, de ez ugye szintén nem tartozik ide.
Én nem látom sehol, hogy bizonygattam, hogy jó nekem az AMD.
Szerintem egy ártatlan mondat volt, bizonyítást nem látok sehol.Te jöttél veszekedni, szerintem én a témához szóltam hozzá, mielőtt kötekedni kezdtél.
De nem haragszom rád, vagy sértegetlek, érettebb vagyok ennél. -
#47
rootkiller
őstag
rootkiller
őstag
Ez előfordul, annyira összetett a dolog. De hálaisten engem nem érint.
-
#42
Overlocker
veterán
Oliverda
#41
-
#41
Oliverda
félisten
Overlocker
#36
Oliverda
félisten
válasz
Overlocker
#36
üzenetére
Nem vagy már így is elég bogaras?
-
#40
Overlocker
veterán
shteer
#37
-
#38
subaruwrc
félisten
Overlocker
#36
subaruwrc
félisten
válasz
Overlocker
#36
üzenetére
-
#36
Overlocker
veterán
Igen, hibásak lettek a procik...Viszont hogy ne kelljen kidobni őket, féláron átveszek 920 és negyedáron 965 processzort!!
-
Blero2
tag
[OFF]Nem a cikk "intel baráti hangvétele" miatt írtam amit írtam, vagy hogy a cikkíró fújta volna fel. Azzal szerintem sem volt semmi gond és helyes, hogy próbálsz megelőzni egy hasonló félreértést (az idő majd úgyis megmondja menyire jelentkezik a probléma élesben).
Csak anno az AMD csúnyán megszívta, mert a sok hozzászóló beleképzelt mindent, és ez most sajnos meg is látszik a cég piaci helyzetén.
Az intel is megérdemelne egy hasonlót, bár remélem a Denebnek nem erre lesz szüksége, hogy vegyék. Ha jól árazzák a teljesítményéhez képest, akkor enélkül is meglesznek AMD-éknél.Megalázásról meg nem szóltam egy szót se, elnézést, ha ezt olvastad ki belőle.[/OFF]
Zo2: Nem hinném, hogy bárki lehúzta volna az intelt.
Oliverda: Lehet, hogy ami a linkelt oldalon olvasható, az szóról szóra igaz, de ugyebár így fejlődik a technológia.
Máshol is ezt csinálják, a jó dolgokat átemelik és próbálnak rajt fejleszteni. Nem csak a proci piacon megy ez így. -
Zso2
őstag
Oli, tudjuk mekkora AT- AMD fan vagy, ezentúl csak piros betüvel írj légyszi.
Komolyan, miért kell valakit egyből lehúzni aki a másik oldalról ír valami jót ?
Ez a cikk az intelről szól, azt tessék itt van az összes véresszájú.....
UI: tényleg , miért nem próbálod ki proci téren az intelt ? Nagyobb teljesítményed lenne.. nem értem miért nem jobb neked a csúcsabb?...mert ugye "csúcs" pricid van. -
#29
Zso2
őstag
Picturemaker
#9
Zso2
őstag
válasz
Picturemaker
#9
üzenetére
miért jó az neked ha felfójnák? mert AMD-d van?....
mint a gyerekek. ez nem igazság, neki miért nem! -
proof88
addikt
Nem konkrét mérnöki terveket loptak, csak rájöttek, hogy jobb lenne nekik is integrált memória vezérlővel végezni a dolgukat. Most ezen kell rágódni?
"AMD was right all along about an integrated memory controller being the key to a superior processor architecture" - ehhez képest a Core2-k integrált memvezérlő nélkül is nyújtják a nem kicsi teljesítményt. Biztos jó hatással van a teljesítményre, de eddig megvoltak nélküle is.
"AMD is focused on delivering the ultimate visual experience to customers, and while Intel may talk about the visual experience, the mainstream PC platforms with Intel CPUs and chipsets leave something to be desired in that department" - lol, nem nagyképű ez a hozzászólás ?! Veri a mellét arra, hogy összejöttek ATI-ékkal. Rájuk is fért, az ATI most ismét nagyot alkotott, de az AMD lemaradt egy jó ideje a proci-párharcban. Bár úgy tudom, szerver fronton az AMD továbbra is jobb, és most ezt szeretné megváltoztatni az Intel. Mindazonáltal, ha mainstream PC platform alatt Intel CPU-val és chipsettel ellátott gépre gondol, mondjuk GMA X3100-zal, akkor az az Intel műve, az AMD meg az ATI grafikus megoldásait használja már. 2 évvel ezelőtt nem hallhattuk volna ezt a mondatot. Inkább jöjjenek ki az új fejlesztésekkel.
-
Khan13
senior tag
Hát emberek, kénytelenek leszünk saját CPU-kat tervezni, mert ezek a mostaniak már nagyon bugosak...
Hülye poént félretéve, aki abban az álomvilágban él, hogy a procik bugmentesek, az ébredjen fel, akiket ez megriaszt, az vegye észre hogy minden proci hibás, mégsem hal le amiatt a rendszere amit használ, és semmi észrevehető hiba nincs. Imádom az ilyen szenzációhajhászokat, akik az érdemi tájékoztatás helyett rákattannak ezekre, meg az oprendszerekre, meg hasonló "értelmes" dolgokra... Nagy tisztelet a PH!-nek, a megbízható lapcsaládnak!
-
-
Oliverda
félisten
"Az igazsághoz természetesen hozzátartozik, hogy legalább ennyi bejegyzést tartalmaznak az Intel Core 2, az AMD Phenom és Athlon processzorok hibalistái is."
Az jelenleg forgalomban lévő C0 steppinges i7 összesen 77 ismert hibát tartalmaz (lista). Ennek egy kisebb részét nem is tervezik kijavítani. A legutolsó B3 steppinges Opteron és Phenom pedig 34 darabot (lista). Itt sem lesz minden javítva.
-
#10
Womb
senior tag
Picturemaker
#9
Womb
senior tag
válasz
Picturemaker
#9
üzenetére
Dehogy bagadelizálják.
Csak van egy felkészült szaklapunk,ami óva int a felesleges hisztériától. -
#9
Picturemaker
őstag
Picturemaker
őstag
Na ja!!
Akkor az AMD-ről leszedték a keresztvizet, Intel is adta a nagyérdemű és a sajtó alá a lovat.
Most az Intel hibáját meg elbagatelizálják? Ez elég gáz dolog.
Nvidiára mindenki "fujjog", hogy megvette a játékgyártókat.
Intelre mikor fujjognak, hogy megvette a sajtót? -
Abu85
HÁZIGAZDA
Az én meglátásomban az AMD hibája sem volt mérvadó, és visszaolvasva a PH is keveset foglalkozott a dologgal.
A jelenlegi helyzetről nekem ez a meglátásom ...Mindenféle szemüveg viselése nélkül írok ide, és nem látok komoly problémát a Core i7 procikban. Majd ha lesz miért megalázni az Intelt akkor megteszem.
-
Atocha
senior tag
Na igen, de:
"Az elmúlt napokban felmerült pánikszerű híresztelések a termék mondhatni jelentéktelen hibáiról inkább nevezhetők szenzációhajhász írásoknak, mint szakszerű olvasói tájékoztatásnak."Amivel én egyet is értek, de anno 1 éve ezt az AMD jól becumizta és hogy lehuzták miatta. Többek közt az olvasok... teljesen értelmetlenül.
Most azt akarjátok itt kihozni, hogy fingom sincs arról, mi az a mikrokód, fingom sincs a procik belső felépítéséről, és így tovább? 
Nézd már meg az évekre visszamenő hozzászólásaimat a témában, mielőtt te is így beszólsz! 
P.H.-val is már nem egyszer beszélgettünk a témáról, szerintem neki sem így jött le...
(Akkor talán nem bottal piszkálnám az x86-os procikat, ti. utálom az x86 ISA-t. 
) Bár most már mindegy, lényegében senki sem programozik asm-ben PC-n, meg máshol sem nagyon. (Még a mikrokontollereknél is a C lett a default.)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ha valóban (mikrokóddal) megkerülhetetlen hibák lennének, nem is került volna piacra a cucc. Ha mégis, akkor már tudnánk róla.
Új hozzászólás Aktív témák
- Apple iPhone 14 Pro / Gyárifüggetlen / 128GB / 12Hó Garancia / 88% akku
- AKCIÓ! MSI Z390 i5 9400F 16GB DDR4 512GB SSD RTX 2060 Super 8GB Corsair Carbide Series 200R 600W
- Bomba ár! Dell Precision 5520 - i7-HQ I 16GB I 512SSD I 15,6" FHD I M1200 4GB I Cam I W10 I Gari!
- Eladó egy wittings steel hr sport hibrid okos óra dobozával töltővel
- BESZÁMÍTÁS! ASROCK B550M R5 5600X 32GB DDR4 1TB SSD RTX 3060 12GB Zalman N5 MF Be Quiet 650W
Állásajánlatok
Cég: FOTC
Város: Budapest