Beviteli sor előzetes lekérése - Prefetch input queue
Lekérése az utasítás műveleti kódok : a program memória jó előre ismert előzetes letöltésére , és ez szolgált segítségével előzetes letöltési input queue (PIQ) .A előre lehívott utasítások vannak tárolva az adatok szerkezetét - vagyis egy sorban . Az opkódok lekérése jóval a végrehajtás előtt növeli a processzor általános hatékonyságát, növelve annak sebességét. A processzornak már nem kell várnia a memóriahozzáférési műveletekre, amíg a következő utasítás opcode befejeződik. Ezt az architektúrát jól használták az Intel 8086 mikroprocesszorban .
Bevezetés
A csővezetékeket az 1960 -as években hozták a számítástechnikai architektúra tervezésének középpontjába a gyorsabb és hatékonyabb számítástechnika igénye miatt. A csővezeték a tágabb fogalom, és a legtöbb modern processzor betölti az utasításait néhány óra ciklusban, mielőtt végrehajtja őket. Ez úgy érhető el, hogy a gépi kódot előre betöltik a memóriából az előhívási bemeneti sorba .
Ez a viselkedés csak azokra a von Neumann számítógépekre vonatkozik (azaz nem a Harvard architektúrájú számítógépekre), amelyek képesek önmódosító kódot futtatni, és valamilyen utasításcsatornával rendelkeznek . Szinte minden modern nagyteljesítményű számítógép megfelel ennek a három követelménynek.
Általában a PIQ előzetes lekérési viselkedése láthatatlan a CPU programozási modellje számára. Vannak azonban olyan körülmények, amikor a PIQ viselkedése látható, és ezeket a programozónak figyelembe kell vennie.
Amikor az x86 -Processzorsebesség változik módot realmode a védett mód és fordítva, a PIQ kell öblíteni, vagy pedig a CPU továbbra is lefordítani a gépi kód , mintha írva az utolsó üzemmódban. Ha a PIQ nincs leöblítve, a processzor rosszul fordíthatja le a kódjait, és érvénytelen utasítás kivételt generálhat .
Az önmódosító kód végrehajtásakor a processzor kódjának közvetlenül a végrehajtás jelenlegi helye előtt történő módosítása nem változtathatja meg a processzor értelmezési módját, mivel az már be van töltve a PIQ-ba. Egyszerűen végrehajtja a PIQ -ba már betöltött régi példányát, a RAM -ban és/vagy a gyorsítótárban lévő kód új és módosított változata helyett .
A PIQ ezen viselkedése alapján megállapítható, hogy a kódot emulátoron belül, vagy közvetlenül egy valódi CPU hardverén hajtják végre . A legtöbb emulátor valószínűleg soha nem szimulálja ezt a viselkedést. Ha a PIQ mérete nulla (a kódváltozások mindig azonnal befolyásolják a processzor állapotát), akkor arra lehet következtetni, hogy vagy a kódot egy emulátorban hajtják végre, vagy a processzor érvényteleníti a PIQ-t, amikor a PIQ-ba töltött címekre ír. .
Teljesítményértékelés a sorbanállás elmélete alapján
Ez volt AK Erlang (1878-1929), aki először fogant egy sorba, mint a megoldást, hogy a szűk keresztmetszetet, telefonos forgalmat. Különböző sorbanállási modelleket javasolnak a valós idejű sorban állási rendszerek közelítő szimulációjához, hogy azok matematikailag elemezhetők legyenek a különböző teljesítményspecifikációk alapján.
A sorban állási modelleket Kendall jelölésével lehet ábrázolni :
- A1/A2/A3/A4
ahol:
- A1 az időelosztás két érkező között
- A2 a szolgáltatás időeloszlása
- A3 a szerver teljes száma
- A4 a rendszer kapacitása
- M/M/1 modell (Single Queue Single Server/ Markovian ): Ebben a modellben a sor elemei érkezési sorrendben kerülnek kiszolgálásra. Tekintettel az átlagos érkezési és kiszolgálási arányokra, a tényleges díjak ezen átlagértékek körül véletlenszerűen változnak, és ezért kumulatív valószínűségi eloszlásfüggvény segítségével kell meghatározni .
- M/M/r modell : Ez a modell az általános M/M/1 modell általánosítása, ahol több szerver működik párhuzamosan. Ez a fajta modell forgatókönyveket is modellezhet türelmetlen felhasználókkal, akik azonnal kilépnek a sorból, ha nem kapnak szolgáltatást. Ez egy Bernoulli -folyamat segítségével is modellezhető, amelynek csak két állapota van, a siker és a kudarc. A legjobb példa erre a modellre a szokásos vezetékes telefonrendszereink.
- M/G/1 modell (Takacs véges bemeneti modellje): Ez a modell fejlett esetek elemzésére szolgál. Itt a szolgáltatásidő -elosztás már nem Markov -folyamat . Ez a modell figyelembe veszi azt az esetet, amikor több meghibásodott gépet javít egyetlen szerelő. Ebben az esetben bármely felhasználó szolgáltatási ideje megnő.
Általában olyan alkalmazásokban, mint az előzetes lekérési bemeneti sor, az M/M/1 modellt népszerűen használják a sor funkcióinak korlátozott használata miatt. Ebben a modellben a mikroprocesszoroknak megfelelően a felhasználó viszi a végrehajtó egység szerepét, a szerver pedig a busz interfész egység.
Utasítási sor
A processzor úgy hajt végre egy programot, hogy lekéri az utasításokat a memóriából és végrehajtja azokat. Általában a processzor végrehajtási sebessége sokkal gyorsabb, mint a memória elérési sebessége. Az utasítási sor a következő utasítások előzetes letöltésére szolgál egy külön pufferben, miközben a processzor végrehajtja az aktuális utasítást.
A négy színpadon csővezeték , a sebességet, amellyel utasítások végrehajtásra lehet akár négyszer nagyobb, mint a szekvenciális végrehajtását.
A processzor általában két külön egységgel rendelkezik az utasítások letöltéséhez és az utasítások végrehajtásához.
Egy csővezeték architektúra megvalósítása csak akkor lehetséges, ha a busz interfész egység és a végrehajtó egység függetlenek. Míg a végrehajtó egység dekódolja vagy utasítás végrehajtásakor, amely nem igényel a használata a adatok és cím buszok , a busz interfész egység gyűjti használati utasításból a memóriából.
Ez a folyamat sokkal gyorsabb, mint egy cím kiküldése, az opkód olvasása, majd dekódolása és végrehajtása. A következő utasítás lekérését az aktuális utasítás dekódolása vagy végrehajtása közben pipeliningnek nevezik.
A 8086 architektúra hatbájtos előhívási utasításcsővel rendelkezik, míg a 8088 négybájtos előhívással rendelkezik. Amint a végrehajtó egység végrehajtja az aktuális utasítást, a busz interfész egység legfeljebb hat (vagy négy) bájtnyi opkódot olvas ki előre a memóriából. A sorok hosszát szimulációs vizsgálatok alapján választották ki.
Kivétellel akkor találkozunk, ha a végrehajtó egység elágazó utasítással találkozik, azaz ugrás vagy hívás utasítással. Ebben az esetben a teljes sort ki kell dobni, és az utasításmutató által mutatott tartalmat le kell tölteni a memóriából.
Hátrányok
Az utasítások sorának előhívási algoritmusát megvalósító processzorok technikailag meglehetősen fejlettek. Az ilyen processzorok CPU tervezési szintű összetettsége sokkal magasabb, mint a hagyományos processzoroké. Ennek oka elsősorban az, hogy két különálló egységet, a BIU -t és az EU -t külön kell működtetni.
Ezen chipek összetettségének növekedésével a költségek is nőnek. Ezek a processzorok viszonylag drágábbak, mint társaik, az előzetes lehívási sor nélkül.
Ezeket a hátrányokat azonban nagymértékben ellensúlyozza a processzor végrehajtási idejének javulása. Miután bevezette az előzetes lehívási utasítássort a 8086 -as processzorba, minden egymást követő processzor beépítette ezt a funkciót.
x86 példakód
code_starts_here:
mov bx, ahead
mov word ptr cs:[bx], 9090h
ahead:
jmp near to_the_end
; Some other code
to_the_end:
Ez az önmódosító program felülírja a jmp-t a_end_end- re két NOP-val (amely 0x9090 kódolású ). Az ugrás jmp to_the_end közelében két bájt gépi kódba van összeállítva, így a két NOP csak felülírja ezt az ugrást, és semmi mást. (Vagyis az ugrás helyébe egy „semmit sem tesz” kód lép.)
Mivel az ugrás gépi kódja már be van olvasva a PIQ -ba, és valószínűleg már a processzor is végrehajtja (a szuperskaláris processzorok egyszerre több utasítást hajtanak végre, de "úgy tesznek", hogy nem, mert visszafelé kompatibilisek ). a kód megváltoztatása nem változtatja meg a végrehajtási folyamatot.
Példa program a méret érzékelésére
Ez egy példa a NASM - szintaxis önmódosító x86 - összeállítási nyelvi algoritmusra, amely meghatározza a PIQ méretét:
code_starts_here:
xor bx, bx ; zero register bx
xor ax, ax ; zero register ax
mov dx, cs
mov [code_segment], dx ; "calculate" codeseg in the far jump below (edx here too)
around:
cmp ax, 1 ; check if ax has been altered
je found_size
; 0x90 = opcode "nop" (NO oPeration)
mov byte [nop_field+bx], 0x90
inc bx
db 0xEA ; 0xEA = opcode "far jump"
dw flush_queue ; should be followed by offset (rm = "dw", pm = "dd")
code_segment:
dw 0 ; and then the code segment (calculated above)
flush_queue:
; 0x40 = opcode "inc ax" (INCrease ax)
mov byte [nop_field+bx], 0x40
nop_field:
times 256 nop
jmp around
found_size:
;
; register bx now contains the size of the PIQ
; this code is for [[real mode]] and [[16-bit protected mode]], but it could easily be changed into
; running for [[32-bit protected mode]] as well. just change the "dw" for
; the offset to "dd". you need also change dx to edx at the top as
; well. (dw and dx = 16 bit addressing, dd and edx = 32 bit addressing)
;
Ez a kód alapvetően az, hogy megváltoztatja a végrehajtási folyamatot, és nyers erővel határozza meg, hogy mekkora a PIQ. - Milyen messze kell megváltoztatnom az előttem lévő kódot, hogy az hatással legyen rám? Ha túl közel van (már benne van a PIQ -ban), a frissítésnek nincs hatása. Ha ez elég messze van, a kód megváltoztatása hatással lesz a programra, és a program ekkor megtalálta a processzor PIQ méretét. Ha ezt a kódot többfeladatos operációs rendszer alatt hajtják végre, akkor a kontextusváltó rossz értékhez vezethet.
