Akademia Techniczno-Humanistyczna w Bielsku-Białej
Anatoliy Melnyk
Ćwiczenia laboratoryjne
z przedmiotu „Architektura komputerów”
Bielsko-Biała, 2015
Praca laboratoryjna №1.
Praktyka pracy z architekturnym symulatorem WinMIPS64
Cel wykonania pracy: Opanowanie techniką pracy z architekturnym symulatorem maszyny z 64-bitową RISC architekturą MIPS64.
Zadanie: Zbadać symulowanie wykonania zadanych wykładowcą maszynowych instrukcji. Skrócić czas wykonania fragmentu programu usunąwszy zwłoki w potoku. Według wyników przeprowadzonych laboratoryjnych badań załatwić formalnie sprawozdanie i obronić jego.
Teoretyczna część:
MIPS (Microprocessor without Interlocked Pipeline Stages):" procesor bez blokowań w potoku ".
Główną ideą którą kierował się John Hennessy przy projektowaniu pierwszego MIPS- procesora (1981 rok), jest taka. Mocno uprościwszy wewnętrzny ustrój CPU i wykorzystując bardzo długi (na te czasy) potok, można otrzymać procesor, który nie umie wykonywać stosunkowo skomplikowane instrukcje, natomiast pracuje na bardzo wysokiej taktownej częstości, co pozwala kompensować straty wydajności na emulacju tych skomplikowanych instrukcji. Najpierw przypuszczało się, że MIPS- procesory nie będą aparatny podtrzymywać nawet operacji mnożenia i dzielenia - dzięki czemu można było obejść się bez skomplikowanych w realizacji blokowań potoku.
Jednak nawet w samych pierwszych MIPS procesorach blokowanie w poyoku, tak samo jak i aparatne instrukcje mnożenia i dzielenia, jednak są obecne. "W czystym wyglądzie" idea okazała się mało przydatną dla stworzenia komercyjnych procesorów.
MIPS64 ma poyokowę strukturę procesora z prostym układem rozkazów [1, str. 189].
Procesor ma 32 64-bitowych registra dla całych liczb i 32 64-bitowych registra dla liczb z ruchomym przecinkiem (rys.1). Register R0 zawsze ma znaczenie 0.
Rys.1 Programne dostępne registry i registry specjalnego mianowania procesora MIPS64 [2, str.2]
Współdziałanie z pamięcią danych odbywa się tylko przez instrukcje Load/Store.
Całe instrukcje 32-bitowe. Sposoby adresowania, formaty rozkazów procesora, zestaw instrukcji i przykłady ich użycia są naprowadzane w pracy [2].
Rozruch i konfiguracja symulatora WinMIPS64
Symulator procesora MIPS pracuje na zapleczu operacyjnego układu Windows.
Rys.2. Symulator WinMIPS64 (jest dociążony program sum.s)
Główne okno symulatora zawiera sześć filialnych okien i status linią pod nimi (rys.2). Filialne okna: Pipeline (potok), Code (kod), Data (pamięć danych), Registers (registry), Statistics (statystyka) i Cycles (okno czasowego wykresu).
Rozpatrzymy dokładniejsze mianowanie filialnych okien symulatora.
Tablica 1 - Filialne okna symulatora WinMIPS64
| Okno Pipeline - okno potoku instrukcji. | Okno zawiera "schematyczne" przedstawienie pięciu schodkowego potoku instrukcji 64-bitowego procesora MIPS64 razem z aparatnymi sekcjami wykonania operacji ruchomego przecinka, a mianowicie, dodawanie/odejmowania (add/sub), mnożenia (mult) i dzielenia(div). Ruchome dzielenie nie jest potokowym. 5 schodków potoku: 1. IF - wybieranie instrukcji z pamięci rozkazów, 2. ID - dekodowanie instrukcji, wybieranie operandow, 3. EX - wykonanie, 4. MEM - zwrócenie do pamięci (zapis/czytania), 5. WB - wsteczny zapis wyniku do rejestrowego plika) To okno pokazuje, na którym schodku potoku znajduje się ta czy inna instrukcja. |
| Okno Code - okno kodu | Okno odzwierciedla trzy kolumienki pamięci instrukcji, amianowicie, (od lewej strony do prawej) : adres bajta, 32-beatową maszynową instrukcję i asemblerowę instrukcję. Podwójny lewy klik myszą na pewnej instrukcji ustala/zdejmuje punkt zatrzymania. Kolor linii kodu wskazuje na którym schodku potoku znajduje się rozkaz. |
| Okno Data – okno danych | To okno pokazuje zawartość pamięci danych z adresowaniem kazdego bajta. Jednak w oknie zawartość podawane przez 64-beatowe pakiety, czyli jak ta zawartość postrzega 64- beatowym procesorem. Byle zredagować pewne dane, należy zrobić na nich podwójny lewy klik myszą (double - left - click). Byle zobaczyć i zredagować dane z ruchomym przecinkiem, należy wykonać podwójny prawy klik (double - right - click). |
| Okno Register – okno registrów | Okno podaje zawartość registrów. Zawartość registrów podają szarym kolorem w chwili, kiedy zawartość tych registrów zmienia się pod działaniem programu, co symuluje się. Kiedy zawartość registru podaje się kolorem, wtedy ten kolor odpowiada kolorowi schodka potoku, gdzie znajduje się odpowiednia instrukcja pod warunkiem, że z tego schodka jest możliwa tak zwana wyprzedzająca przesyłka (forwarding). To okno również pozwala interaktywną przemianę zawartości registrów dla całych liczb i liczb z ruchomym przecinkiem, pod warunkiem jeżeli registry nie znajdują się w trakcie programowej przemiany zawartości i to znaczenie nie wykorzystywa się dla wyprzedzenia danymi. Byle zmienić zawartość registra po nim trzeba dwukrotnie kliknuć lewym przyciskiem myszy. Pojawi się okno, w którym można wprowadzić nowe znaczenie - 64-beatową szestnadctkową liczba (dla przykładu 0х0000000000000777). Dla zachowania przemian naciśnijcie OK. |
| Okno Cycles - okno czasowego wykresu | Okno zawiera czasowe zachowanie potoku pod czas symulowania potocznego programu. Ono utrwala historię każdej instrukcji. Kiedy pewna instrukcja sprawia zwłokę potoku, wtedy jej symbolowe przedstawienie w lewej części wianka zmienia kolor z czarnego na niebieskiej. Następne instrukcje, wykonanie których przerwano zwłoką stają szarego koloru. |
| Okno Statistics - okno statystyki | Okno podaje nagromadzeni i potoczne statystycy programu, co symuluje się, a mianowicie, liczba taktownych interwałów (Cycles) na symulację, liczba dokonanych za te cykle instrukcji (Instructions), średnia liczba cykli na jedną instrukcję (Cycles Per Instruction, czyli CPI), typy zwłok (Stalls) i rozmiar kodu programu (Code Size). |
| Status Line - linia stanu symulatora | Status linia внизу głównego okna stymulatora normalnie wydaje zawiadomienie "Ready", jednak w ciągu symulowania podaje różną pożyteczną użytkownikowi informację co do potocznego stanu procesu symulowania. |
Byle doprowadzić symulator początkowego (startowego) stanu przed symulowaniem programu najpierw jego zrzucają przez punkt jadłospisu File -> Reset MIPS64.
Ten symulator pozwala przejrzeć i wprowadzić zmiany do początkowej konfigurację (czyli wirtualną aparatną część) w punkcie mapy serwisu Configuration (Konfiguracja).
Rys. 3 - Punkt menu Configuration (jest dozwolone tylko wyprzedzenie)
Opcje, dostępne przez punkt menu Configuration:
Multi-Step (wykonanie kilku kroków symulowania za raz);
Enable Forwarding (pozwolenie wyprzedzenia);
Enable Branch Target Buffer (pozwolenie użycia buforu adresów przejści);
Enable Delay Slot (pozwolenie zwłoki przejścia).
Trzy ostatnie opcje odpowiadają realizacjom metod zmniejszenia wpływowi konfliktów na wydajność wykonania rozkazów w potoku. Dokładniej o klasach konfliktów, które powstają w potoku i metody ich usunięcia można zapoznać się w pracy [1. str. 167].
Można zmieniać strukturę i czas wykonania ruchomych operacji w potoku, pojemność pamięci kodu/danych w punkcie menu Configuration -> Architecture (rys. 4).
Rys. 4 - Okno konfiguracji aparatnej architektury.
W naprowadzanym oknie odnotowano iloszć bitów (i odpowiednio, pojemność) pamięci danych i pamięci rozkazów. W tym wypadku oni dorównują 210 = 1024 = 1К 32-bitowch maszynowych instrukcji i 210 = 1024 = 1Кbajtów danych.
Latency - utajona zwłoka wykonania. Zwłoki wykonania operacji ruchomego przecinka (FP) składają: 4 cykle (taktowne interwały) dla ruchomego dodawania/odejmowania (czyli 4 schodki liczbowego potoku dodawania/odejmowania), 7 cykli dla ruchomego mnożenia (7 schodków jeszcze jednego, paralelnego do potoku dodawania/odejmowania, liczbowego potoku mnożenia) i 24 cykle dla nie potokowego urządzenia dzielenia liczb z ruchomym przecinkiem. Całe operacje dla utrwalonego przecinka wykonują się za jeden cykl, czyli, nie mają łatentnych (utajonych) zwłok.
2. Ładowanie programu
Za pomocą standardowego tekstowego redaktora stworzyć programowy plik, na przykład, sum.s. Ten program zawiera kod dla MIPS64, co wylicza sumę dwóch całych liczb A i B. Liczbowe kody najpierw trzeba wybrać z komórek pamięci za adresami A i W do registrów, potem dodać na registrach i, nareszcie, zapisać otrzymaną sumę do komórki pamięci za adresem С.
Tekst programu-asemblera:
;*** winMIPS64 //sum.s// C=A+B *****
;*** (c) 2003 CA226, DCU *****
.data
A: .word 10
B: .word 8
C: .word 0
.text
main:
ld r4,A(r0)
ld r5,B(r0)
dadd r3,r4,r5
sd r3,C(r0)
halt
Zauważymy, że niewielka według rozmiaru użyteczność asm.exe pozwala jeszcze do symulowania sprawdzić składnię programu, co powinno symulować się. Byle sprawdzić składnię trzeba wykonać rozkaz operacyjnego układu:
C:\winmips64> asm sum.s
Wynik zobaczymy na wyświetlaczu.
Jeśli wykonać
C:\winmips64> asm sum.s > report.txt
wynik będzie zawierać nie ekran, a plik report.txt, zawartość którego dla programu sum.s niżej podano:
Pass 1 completed with 0 errors
;***************************************
;*** winMIPS64 //sum.s// C=A+B *****
;*** (c) 2003 CA226, DCU *****
;***************************************
00000000 .data
00000000 000000000000000a A: .word 10
00000008 0000000000000008 B: .word 8
00000010 0000000000000000 C: .word 0
00000000 .text
00000000 main:
00000000 dc040000 ld r4,A(r0)
00000004 dc050008 ld r5,B(r0)
00000008 0085182c dadd r3,r4,r5
0000000c fc030010 sd r3,C(r0)
00000010 04000000 halt
Pass 2 completed with 0 errors
Code Symbol Table
main = 00000000
Data Symbol Table
A = 00000000
B = 00000008
C = 00000010
Do startu symulacji, trzeba załadować do pamięci symulatora syntaktyczny sprawdzony program. To wykonuje się przez menu File/Open.
Po zakończeniu można zobaczyć odnowioną zawartość okien kodu i danych (ostatnie, kiedy program zawiera dane albo rozmieszcza wyniki w pamięci). U góry okna symulatora pojawia się rządek z drogą do programu, w tym wypadku – do programu sum.s.
Teraz program jest dociążony do pamięci i symulator jest przygotowany do funkcjonowania.
3. Symulowanie
Rozpatrzymy krok za krokiem symulowania dociążonego programu sum.s.
F10 - Reload dla uruchamiania ponownego symulowania.
Zauważymy, że na starcie pierwsza kolorowa linia w oknie Code z adresem 0х0000 (0000) zabarwiona żółtym. Schodek przenośnika IF w oknie Pipeline również jest zabarwiony żółtym i zawiera asembler mnemonikę pierwszej instrukcji programu. W oknie Data można znaleźć programowe zmienne A i B.
Takt 1
Dla krok za krokiem wykonania trzeba wykonać rozkaz Execute/Single cykl (Wykonać/jeden takt), albo nacisnąć klawisz F7. Symulator wykona pierwszy cykl (taktowny interwał) programu. Zwróćcie uwagę! Nie pierwszą instrukcję, a tylko pierwszy cykl, co dla pięciu schodkowego potoku odpowiada wykonaniu 1/5 instrukcji w najlepszym wypadku, czyli, kiedy nie ma wymuszonych zwłok potoku.
Rys. 5 - Pierwszy takt wykonania dociążonego programu sum.s.
W oknie Code kolor pierwszej instrukcji zmienia się na błękitny i już druga instrukcja jest zabarwiona żółtym (rys. 5).
Takie zabarwienie wskazuje na schodek przenośnika, gdzie znajduje się odpowiednio zabarwiona instrukcja:
żółty dla IF (wybieranie instrukcji z pamięci instrukcji, dokładniej z cashu instrukcji);
błękitny dla ID (dekodowanie instrukcji i poberanie operandow z rejestrowego plika albo bezpośrednie znaczenie z pola rozkazu);
czerwienny dla EX (wykonanie instrukcji, 1 takt dla utrwalonych liczb i więcej taktów dla liczb z ruchomym przecinkiem);
zielony dla MEM (zapis/czytania do/z komórek pamięci danych);
purpurowy dla WB (zapis wyniku do registrow i rejestrowego plika).
Jeśli popatrzeć na schodek przenośnika IF w oknie Pipeline, można zobaczyć, że druga instrukcja programu ld r5,B(r0) pojawiła się na niej, w ten czas, jak pierwsza instrukcja ld r4,A(r0) przesunęła się na drugi schodek potoku - ID.
Takt 2
Na następnym kroku do potoku nadeszła instrukcja dadd r3,r4,r5. Pierwsza instrukcja przesunęła się na schodek EX, gdzie oblicza się adres komurki pamięci do której będziemy zwracać się w następnym takcie.
Takt 3
Trzeci nacisk na F7 znów zmienia kolor instrukcji w oknie Code. Pierwsza instrukcja dosięgła schodka MEM, jej rządek zielonego koloru. Do potoku wchodzi instrukcja sd r3,C(r0). W oknie Cycles widzimy historię wykonania każdej instrukcji programu, czyli schodek, na którym znajduje się każda instrukcja przed nadsyłaniem kolejnego taktownego impulsu (rys.6).
Rys.6. Trzeci takt wykonania programu sum.s
Takt 4
Znów naciskamy F7. Teraz na każdym schodku potoku znajduje się instrukcja (rys.7).
Na tym takcie dla pierwszych trzech instrukcji odbywają siętakie działania:
do registra r4 zapisują się dane, sczytują z komorki pamięci za adresem A;
z pamięci za adresem B sczytują się dane;
wykonuje się operacja dodania add r3,r4,r5;
Dla wykonania instrukcji dodawania są konieczne odnowione zamieść registrów r4 i r5, które są jeszcze nie zapisane do rejestrowego plika. Ich można otrzymać zawczasu (mówią – z wyprzedzeniem w czasie).
Rys.7. Czwarty takt wykonania programu
Prosto z wyjścia pamięci danych, czyli, z wyjścia schodka МЕМ (forwarding from the MEM stage) zabieramy nowy, jeszcze nie zapisany do registru mianowania operand (to i jest wyprzedzenie), a dalej równolegle wykonujemy dodawania tego nowego operandui w owym samym czasie piszemy ten operand do registru rejestrowego plika (można zobaczyć, że r4 zabarwia się zielonym w oknie Registers, co oznacza, że zawartość registra dostępne dla wyprzedzenia z schodka MEM).
Na tym takcie ostatnia instrukcja programu halt (programista powinien ręcznie hamować wykonanie programu akurat taką instrukcją) już jest wprowadzona do potoku.
Takt 5
Rys.8. Piąty takt wykonania. Status: Powstała zwłoka RAW (Read after Write).
Naciskamy F7. Odczytane dane, przeznaczone dla registra r5, stają się dostępnymi dla wyprzedzającej przesyłki. Jednak, oni nie byli dostępne na zeszłym takcie dla wykonania operacji dodawania instrukcji dadd r3,r4,r5 na schodku EX. Toż instrukcja została na schodku EX, powstała zwłoka. Status linia podaje informację "RAW stall in EX (R5)", co opisuje na którym schodku potoku powstała zwłoka, i niedostępność którego registra ją spowodowała.
Okna Cycles i Pipeline wyraźnie wskazują na to, że instrukcja dadd "utknęła" w schodku EX, i że całe instrukcje za niąrównież bezsilne przesuwać się potokiem dalej. W oknie Cycles instrukcja dadd podświetliono błękitną, a instrukcje, co jest rozmieszczone za nią "poszarzały".
Takt 6
Rys.9 Szósty takt wykonania programu
Naciskamy F7. Instrukcja dadd r3,r4,r5 nareszcie wykonujesię, a przed chwilą otrzymana suma, przeznaczona dla zapisudo r3, równolegle staje się osiągalną dla wykonania wyprzedzenia (z schodka EX, toż kolor r3 w oknie Registers stał się czerwiennym). Otrzymano znaczenie 0х12, co jest sumą 10 8 = 18 w dziesiętnym systemie. To i jest odpowiedź programu. Jednak, nas więcej ciekawi nie ta odpowiedź, a czasowe wytraty na wykonanie programu (mierzymy liczbą taktownych impulsów) i skrócenie tego czasu różnymi metodami.
Takt 7
Naciskamy F7. Instrukcja halt, już wprowadzona do potoku, sprawia efekt "zamknięcia" potoku. Po niej już żadna inna instrukcja nie wprowadza się do potoku, a sam potok stopniowo opróżnia się, od schodka IF do schodka WB.
Takt 8
Rys.10. Wynik wykonania programu jest zapisany do komorki pamięci za adresem С.
Naciskamy F7. Sprawdzamy pamięć danych Data, gdzie utrwalamy, że zmienna C zyskała znaczenia 0х12. Instrukcja sd r3,C(r0) zapisała to znaczenie do pamięci na schodku MEM potoku, wykorzystując zdystansowane dane z wyjścia EX instrukcji dadd r3,r4,r5.
Takt 9
Naciskamy F7.
Takt 10
Naciskamy F7. Program finiszuje.
Przeanalizujemy zawartość okna statystyki (Statistics).
Rys.11. Okno Statystyki
W ogólnym zużyły 10 taktownych cykli na wykonanie pięciu instrukcji. Więc, otrzymały średnią liczbę taktownych impulsów CPI=2 na jedną instrukcję. СРІ - to (średnia) liczba taktownych interwałów (cycles per instruction), co przypadło na wykonanie każdej instrukcji programu. W idealnym wypadku dla naszego pięć schodkowego potoku mamy СРІ=1, lecz zależność między instrukcjami przez dane (konflikty według danych: RAW, WAR, WAW) zwiększa СРІ, czyli czasowe wytraty na wykonanie programu.
W tym wypadku wynik do dwóch razy jest gorszy od ideału i tu jest gdzie doskonalić się. Odbyło się 1 przyhamowanie RAW, wezwane przez konflikt według danych.
Zbadamy wpływ na wydajność zakazu wyprzedzenia (co jests kutkiem uproszczenia aparatnej części, a tanie nie bywa optymalnym). Który czas nam będe potrebny bez użycia wyprzedzenia?
Dla zakazu wyprzedzenia (forwarding) trzeba skasować opcję Enable Forwarding.
Rys.12 - Zakaz wyprzedzenia
Zawartość okna statystyki odzwierciedli wynik na dowolne przemiany w architekturze. Powtórzmy krok za krokiem wykonania programu i porównamy wyniki statystyki.
Rys.13 Statystyka wykonania programu z zakazem wyprzedzenia.
Ilość zwłok wezbrała. Podczas wykonania powstaje 4 przyhamowania klasie RAW (dodatkowo utracono 4-1=3 takty). Przyhamowanie powstają na schodku ID, tak jak dla wybierania operandów trzeba doczekać się tymczasem poprzednia instrukcja zapisze wynik do rejestrowego plika.
Więc wykonanie programu zajmuje 10 3=13 taktownych cykli. Średnia liczba taktów na wykonanie instrukcji pogorszyła się i składa CPI=2.600. Więc, wydajność uproszczonej wersji procesora jest niższa.
3.2. Inne reżimy symulowania
Za jeden krok można wykonywać więcej jednego taktu. Byle zrobić to, wywołują Execute/Multi cycle albo F8. Liczbę dokonanych jednym naciskiem taktów zmieniają przez Configure/Multistep.
Pełne wykonanie programu wykonuje się za pomocą F4 albo ż Execute/Run to.
Można wykorzystywać punkty zatrzymania. Najpierw naciśniemy na F10 żeby ponownie uruchomiać symulowanie. Byle ustalić punkty zatrzymania trzeba dwukrotnie natisnuć lewym przyciskiem myszy po instrukcje, na przykład na instrukcji dadd r3,r4,r5.
Dalej naciśniemy na F4. Program rozpocznie wykonywać się w automatycznym reżimie i zahamuje się kiedy rozpocznie sięf aza (schodek) IF oznaczonej instrukcji dodawania. Jeszcze jeden podwójny klik na tej samej instrukcji zdejmuje punkt zatrzymania.
Praca laboratoryjna 2.
Badanie wykonania cyklu na potoku rozkazów
Cel wykonania pracy laboratoryjnej: Opanować technikę potokowego wykonania rozkazów przehodóow warunkowych
Zadanie: Symulatorem WinMIPS64 wykonać badanie potokowego wykonania fragmentów programów komputerowych z cyklami. Optymizować kod programowy i wykonać badanie kodu.
Według wyników przeprowadzonych laboratoryjnych badań załatwić formalnie sprawozdanie i obronić jego.
Bazowe opcje wykonania pracy laboratoryjnej.
Jest symulowany program jaki zapisany w języku Asembler. Program szuka sumy 10 liczb od 1 do 10 z krokiem 1. Odpowiedź jest 0х37 = 55 dziesiętne. W pamięci programowy rezerwują (.word) z inicjalizacją 10 komórek ze składnikami, a także (bez inicjalizacji, .space) miejsce dla wyniku (sumy).
;Program: loop.s
;Sum of 10 integer values
.data
values: .word 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ; 64-bit integers
result: .space 8
.text
MAIN:
daddui R1,R0,10 ; R1 <- 10
dadd R2,R0,R0 ; R2 <- 0 POINTER REG
dadd R3,R0,R0 ; R3 <- 0 RESULT REG
LOOP:
ld R4,values(R2) ;GET A VALUE IN R4
dadd R3,R3,R4 ; R3 <- R3 + R4
daddi R2,R2,8 ; R2 <- R2 + 8 POINTER INCREMENT
daddi R1,R1,-1 ; R1 <- R1 - 1 DECREMENT COUNTER
bnez R1,LOOP
nop
sd R3,result(R0) ; Result in R3
HALT ; the end
Będziemy wykorzystywać takie nastrajania wirtualnej aparatury :
wciągnęty aparatne mechanizmy wyprzedzenia danymi (Enable Forwarding);
prognozowanie kierunku warunkowego przejścia za pomocą bufora docelowych adresów przejścia (Branch Target Buffer).
Rys.1. Optymizowana konfiguracja potokowego procesora dla wykonania zadanego programu
Niżej pokazano okno symulatora.
Rysunek. 2 –Główne okno symulatora z załadowanym programem. Wykorzystano zasoby przesyłania i prognozowanie kierunku przejścia warunkowego (branch target buffer)
Rysunek. 3 – Główne okno symulatora w jakie widać zawartośc pamięci do startu wykonania programu.
Rysunek. 4 – Główne okno symulatora, wykonano 7 cyklów symulowania, jest pierwszy konflikt RAW (read after write)
Rysunek. 5 – Potok symulatora, Pierwszy RAW hamowanie. 7 taktów symulowania.
Rysunek 6. – Drugi RAW hamowania. Wykonano 10 taktów.
Rysunek 7 –Po wykonaniu 11 taktów wystąpiło pierwsze hamowanie, przez wykonanie przechodu warunkowego (branch taken stall).
Przy użyciu bufora docelowych adresów przejścia pod czas perwszego wykonania rozkazu przejścia do bufora zapisuje się adres rozkazu przejścia (bnez R1,LOOP) i adres rozkazu, do którego spełnia się przejście (ld R4, values (R2)).
Rysunek 8. Pojawienie się pierwszego błędu w prognozowaniu kierunku przesyłania warunkowego (Branch misprediction stall)
Przy realizacji metod dynamicznej przepowiedni tworzy się tablica historii przejści. Bardzo prostym wariantem jest jednobitowa tablica historii przejści, w której zachowuje się wynik ostatniego wykonania rozkazu przejścia. Jeśli ten rozkaz skończył się przejściem, to do odpowiednej komorki tablicy zapisuje się jedynka, w innym wypadku - zero. Przepowiednia przejścia dla kolejnego rozkazu zbiega się z wykonalnym przejściem poprzedniej. Po wykonaniu tego rozkazu, jeśli przepowiednia nie urzeczywistniła się, zawartość komurki tablicy koryguje się.
Tablica historii przejści zrealizuje się w składzie bufora adresów przejścia. Każdy rządek bufora adresów przejścia włącza adres rozkazu przejścia, prognozowany adres następnego rozkazu (adres przejścia) i prehistorię rozkazu. Bity prehistorii są informacją o wykonaniu albo niewykonaniu warunków przejścia danego rozkazu w przeszłości. Zwrócenie do bufora adresów przejścia (porównanie z polami adresów rozkazów przejścia) przeprowadza się za pomocą potocznego znaczenia programowego licznika na etapi wybierania kolejnego rozkazu [1, str.185].
Więc, pod czas wykonaniu programu z optymizowanej aparaturą straty potoku instrukcji złożyły 20 RAW-przyhamowan, 2 przyhamowania podczas wykonania warunkowych przejści (Branch taken) i jeszcze 2 przyhamowania przez błędy przepowiedni kierunku warunkowego przejścia aparatnymi środkami.
Rys.9. Wynik wykonania programu przy optymizowanej aparaturze.
Jasno, że przy użyciu nie optymizowanej aparatury czas wykonania programu zrośnie. Symulowaniem należy podać odpowiedź i pytanie - kiedy, dlaczego, na ile?
Wykorzystane źródła:
1. А.О. Melnyk. Architektura komputera. Naukowa edycja. Łuck. 2008. - 470 p.
Ernesto Sanchez, MIPS64 Introduction.
MIPS64™ Architecture For Programmers : Introduction tothe MIPS64™ Architecture. Vol I, II, III. MIPS Technologies,Inc.