Architektura systemów komputerowych	Punkty:
Imię i Nazwisko: - Dydo Karol - Tomasz Gierczak	Temat: Potokowe przetwarzanie instrukcji. Symulator

1. Zapoznanie się z symulatorem(zadanie do wykonania w domu).

   1. Na wstępie zapoznaliśmy się z budowa symulatora CPU-OS Simulator. W tym celu wykorzystaliśmy(wskazaną w poleceniu) pomoc(CPU HELP, Show help Information, Introduction to CPU Simulator, CPU Simulator Instruction Set, Programming Model1, Programming Model2, Investigating CPU Instructions).

   2. Następnie zapoznaliśmy się z podstawami jezyka STL wykorzystując wbudowany w symulator pomoc(CPU Help, Show Help Information, Compiler).

2. Analiza sekwencyjnego przetwarzania instrukcji.

   1. Na początku wprowadziliśmy przykładowy program z pliku „Investigating Instruction Pipelling.pdf”. Wybraliśmy ćw.1 „Exersise 1 – Difference between the sequential and the pipelined execution of CPU instructions”

Po wpisaniu programu, załadowaliśmy go do pamięci używając buttonu „Load in Memory”

1. Po uruchomieniu „Show Pipeline” i zaznaczeniu opcji „No instruction pipeline” otrzymaliśmy następujące wyniki. Wskaźnik CPI(Clock per instruction) = 5.04, SF(Speed-up factor) = 0.99. Przy bez potokowej instrukcji przetwarzania danych, totalna liczba wykonanych instrukcji wyniosła 166. Po przemnożeniu wskaźnika CPI z liczbą wykonanych wszystkich instrukcji otrzymamy ilość wszystkich cyklów zegara, 166 × 5.04 = 836,64. Program zaokrągla tę liczbę do 836. Zaobserwowaliśmy, że każda kolejna instrukcja zostaje wykonana po zakończeniu poprzedniej, czyli np. najpierw instrukcja „JMP 17” zostaje pobrana z pamięci instrukcji(fetch), potem została zdekodowana(decode), następnie zostały odczytane operandy(read operands) po czym instrukcja została wykonana(execute) i rezultat został zapisany do pliku rejestru(write result).
   
   
   
   
   Dopiero po wykonaniu całej instrukcji procesor przechodzi do wykonania kolejnej instrukcji, w tym przypadku porównania rejestrów „CMP R03, R01” oraz pobranie instrukcji „CMP R03, R01” z pamięci instrukcji zostaje wykonane dopiero wtedy, gdy zakończy się etap zapisu wyniku do pliku rejestrów instrukcji „JMP 17”, widoczne jest to na przedstawionym poniższym rysunku.

1. Po uruchomieniu „Show Pipeline” i odznaczeniu opcji „No instruction pipeline” otrzymaliśmy następujące wyniki. Wskaźnik CPI(Clock per instruction) = 1.92 SF(Speed-up factor) = 2.6. Przy potokowej instrukcji przetwarzania danych, totalna liczba wykonanych instrukcji wyniosła 166. Po przemnożeniu wskaźnika CPI z liczbą wykonanych wszystkich instrukcji otrzymamy ilość wszystkich cyklów zegara, 166 × 1.92 = 318,72. Program zaokrągla tę liczbę do 318. Zaobserwowaliśmy, że przy pracy potokowej procesora przy wykonaniu tego samego programu liczba wszystkich cyklów zegara spadła mniej więcej o połowę, co znacznie przyspieszyło wykonanie programu. Działo się to przez wykonanie jednej instrukcji po drugiej. Czyli np. instrukcja „ADD #1, R04” zostaje pobrana z pamięci instrukcji a kolejna instrukcja „MOV R04, R05”, może zostać pobrana z pamięci instrukcji wtedy, gdy poprzednia instrukcja „ADD #1, R04” zaczyna być dekodowana. Należy także wspomnieć o konkurowaniu instrukcji o dostęp do magistrali oraz nieliniowym wykonywaniu instrukcji. Oba problemy mogą zwiększyć średni czas wykonywania instrukcji w potoku. Konkurencja o magistrale może wystąpić zawsze, kiedy instrukcja musi sięgnąć do danej w pamięci. Prostym rozwiązaniem tego problemy jest użycie „przerwy w potoku”. Kiedy procesor staje przed problemem konkurencji o magistralę, najwyższy priorytet otrzymuje instrukcja najbardziej zaawansowana w potoku.

T1	T2	T3	T4	T5	T6	T7	T8	T9
Kod instrukcji	Dekodowanie	Adres	Wartości	Wyliczanie	Zapis
	Kod instrukcji	Dekodowanie	Adres	Wartości	Wyliczanie	Zapis
		Kod instrukcji	Dekodowanie	Adres		Wartości	Wy	Za

Kolorem pomarańczowym została zaznaczona przerwa w potoku. Przerwa w potoku bierze się stąd, że instrukcja numer 1 próbuje zapisać wartość w pamięci podczas gdy jednocześnie instrukcja numer 2 próbuje odczytać z pamięci wartość. Instrukcja numer 3 w związku z przerwą w potoku, wykonuje się przez dwa cykle.

1. Po przeanalizowaniu podpunktu b i c, zaobserwowaliśmy olbrzymią różnice pracy procesora w potoku i bez instrukcji przetwarzania potokowego. Procesor który pracuję w trybie potokowym potrzebuje mniej czasu na wykonanie wszystkich instrukcji, jest wydajniejszy i bardziej efektywny niż procesor bez przetwarzania danych z instrukcją potokową.

1. Analiza hazardu danych.

   1. Na początku wprowadziliśmy przykładowy program z pliku „Investigating Instruction Pipelling.pdf”. Wybraliśmy „Exercise 2 – CPU pipeline data hazards, bubbles and the NOP instruction”

1. Po wybraniu opcji potowego przetwarzania i zaznaczeniu „Do not insert bubbles” uruchomiliśmy program i odczytaliśmy wartość rejestru „R03”, która wynosi teraz 6. Rejestr „R03” po zakończeniu programu powinien mieć wartość 8, jest to wartość oczekiwana przez programistę. Przy odznaczeniu „Do not insert bubbles” wartość rejestru „R03” jest poprawna.

1. Po wstawieniu instrukcji NOP(No operation or null operation), wartość wskaźnika CPI wynosi 2.33 a wartość wskaźnika SF wynosi 2.15. Rejestr „R03” wskazuję poprawną wartość oczekiwaną przez programistę.

2. Po usunięciu instrukcji NOP i odznaczeniu „Do not insert bubbles” wartość rejestru „R03” wynosi 8, jest to wartość oczekiwana przez programiste. Przy instrukcji „ADD R01, R03” pojawia się „Data Hazard”.

3. Po wyłączeniu opcji „Enable operand forwarding” zawartość R03 wynosi 8, co jest oczekiwaną wartością przez programistę.