Uvod

Za početak malo objašnjenje mojih akcija odnosno teme ovog članka. Cijela je priča počela jučerašnjim e-mailom u kojem me moj dragi urednik zamolio da odgovorim na e-mail jednog čitatelja i objasnim mu ovisnost između takta i dužine pipelinea procesora. Budući da sam jučer trebao napisati recenziju Logitechovih Z-3 zvučnika, odgovaranje na čitateljev e-mail je moralo pričekati. No sudbina (ali i moj kronični manjak koncentracije) me odvela u sasvim drugom smjeru. Taman kad sam se spremao navaliti na tekst o zvučnicima palo mi je na pamet pogledati što ima novog na našem forumu, kad tamo - moj znatiželjni čitatelj pokušava saznati što ga zanima alternativnim metodama. Budući da sam sa tugom u očima osvjedočio pokušaje kolega forumaša da temu ovog članka objasne pomoću jedne složene rečenice sa uporabom termina kao što je "šlauf", nije mi preostalo ništa drugo nego napisati ovaj ishitreni članak.

Bez daljnjeg filozofiranja "zagrizimo" u temu.

Pipeline = proizvodna traka

Svaki moderni procesor (onaj koji radi na principu pipelinea) obrađuje informacije na principu tvorničke proizvodne trake. Ako razdijelimo ovu "proizvodnu traku" na osnovne dijelove, operacije koje procesor izvodi pri obradi informacija možemo podijeliti na četiri stupnja, a te stupnjeve nazvati "Fetch", "Decode", "Execute" i "Write".

"Fetch" - dohvaća instrukciju iz cache memorije ili RAM-a

"Decode" - dekodira instrukciju (prevodi instrukciju u oblik razumljiv "Executeu")

"Execute" - izvršava dekodiranu instrukciju

"Write" - vraća rezultat operacije natrag u cache memoriju

Dakle imamo četiri osnovna koraka pri obradi informacija. Neki od ovih koraka se dijele na još manje korake, a zbroj svih koraka predstavlja dužinu pipelinea.

Vratimo se sad na princip proizvodne trake:

Recimo da se u cacheu procesora nalaze četiri instrukcije koje treba obraditi. Procesor ih, analogno proizvodnoj traci, u idealnim uvjetima obrađuje na slijedeći način:

1. "Fetch" dohvaća instrukciju no. 1 iz cachea. "Decode", "Execute" i "Write" ne rade ništa budući da još nisu dobile podatke od "Fetcha".

2. "Fetch" šalje instrukciju no. 1 na "Decode" i dohvaća instrukciju no. 2. "Decode" dekodira instrukciju no. 1. "Execute" i "Write" se dosađuju.

3. "Decode" šalje dekodiranu instrukciju no. 1 na "Execute" i počinje obrađivati instrukciju no. 2 koju je dobio od "Fetcha". "Fetch", shodno tome, dohvaća instrukciju no. 3. "Execute" obrađuje instrukciju no. 1. "Write" i dalje stoji.

4. "Write" napokon ima materijala za rad - dobija rezultat instrukcije no. 1 i zapisuje ga natrag u cache memoriju. "Execute" obrađuje instrukciju no. 2. "Decode" obrađuje instrukciju no. 3 dok "Fetch" dohvaća zadnju instrukciju, instrukciju no. 4. Cijeli se ciklus odvija dok se ne obrade sve instrukcije, odnosno dok se rezultat operacije koju je inicijirala instrukcija no. 4 ne zapiše u cache memoriju.

Kao što vidimo, u određenoj jedinici vremena svaki od ovih osnovnih dijelova pipelinea odrađuju svoj dio posla pa cijeli pipeline u određenoj jedinici vremena može obraditi jednu instrukciju. Da navedeni dijelovi pipelinea nisu povezani, za obradu svake instrukcije bi trebalo potrošiti četiri puta više vremena budući da tijekom aktivnog stanja jedne jedinice (misli se na "Fetch, "Decode"...) ostale jedinice ne bi imale što raditi.

Lako je zamijetiti da efikasnost ovog cijelog jednostavnog pipelinea ovisi o tome da li će svaki njegov dio odraditi svoj dio posla u jednakom vremenu. Ako bilo koji dio kasni, kasni i cijeli pipeline. Ako logički sagledamo naš jednostavni pipeline, jasno je da su dekodiranje i obrada dekodiranih instrukcija (dakle "Decode" i "Execute") imaju mnogo kompleksniju zadaću od "Fetcha" i "Write" pa zato "usporavaju" cijeli proces. Nakon što smo ovo konstaturali u cijelu shemu valja uvesti takt.