Executie speculativa - Microprocesoare Pentium

Executie speculativa - Microprocesoare Pentium

In sectiunea precedenta a fost introdus conceptul de reordonare a instructiunilor pentru imbunatatirea performatei. Punctul central a fost reordonarea instructiunilor in cadrul unui singur bloc. Acest aspect este analizat in continuare. Programele pentru calculatoare se pot sparge in blocuri de baza (basic blocks), fiecare bloc de baza constand intr-o secventa liniara de cod cu un punct de intrare in capatul de sus si o iesire in capatul de jos. Un bloc de baza nu contine nici un fel de structuri de control (de exemplu instructiuni if sau while) astfel incat translatarea sa in limbaj masina nu contine nici un fel de ramificatii. Blocurile de baza sunt conectate prin instructiuni de control.

Un program in aceasta forma poate fi reprezentat ca un graf orientat, asa cum este prezentat un exemplu in figura 9. Aici se calculeaza suma cuburilor intregilor pari si impari, pana la o anumita limita si se acumuleaza rezultatele lor in evensum si respectiv, oddsum. In cadrul fiecarui bloc de baza, tehnicile de reordonare din sectiunile precedente functioneaza bine. Numai ca majoritatea blocurilor de baza sunt scurte si nu exista suficient paralelism in acestea pentru a le exploata efectiv. In consecinta pasul urmator este sa se permita reordonarea pentru a intersecta granitele blocurilor de baza in incercarea de a umple toate pozitiile de lansare. Cel mai mare castig apare cand o operatie posibil lenta poate fi mutata mai sus in graf pentru a incepe mai devreme. Aceasta ar putea sa fie instructiune LOAD, o operatie in virgula mobila sau chiar startul unui lant lung de dependente. Mutarea de cod in sus peste o ramificatie se numeste inaltare (hoisting).

(a)                                   (b)

Fig. 9.(a) Un fragment de program.

(b) Graful corespunzator blocului

Utilizarea acestei tehnici necesita sprijin din partea compilatorului si a hardware-ului, precum si anumite extensii arhitecturale. In majoritatea cazurilor, reordonarea instructiunilor peste granitele blocurilor de baza este mai presus de capacitatea hardware-ului, deci compilatorul trebuie sa mute instructiunile explicit.

Executia speculativa introduce anumite probleme interesante. Prima ar fi ca, este esential ca in nici una din instructiunile speculative sa nu existe rezultate irevocabile, pentru ca s-ar putea constata mai tarziu ca n-ar fi trebuit executate. In figura 9, se poate citi evensum si oddsum si, de asemenea, se poate face adunarea imediat ce k este disponibil chiar inainte de instructiunea if, dar nu este bine sa se memoreze rezultatele in memorie. In secvente de cod mai complicate, o solutie banala de a preveni scrierea registrelor de catre codul speculativ, inainte sa se stie daca acest lucru este dorit, este sa se redenumeasca toate registrele destinatie utilizate de codul speculativ. In acest fel, sunt modificate numai registrele temporare, asa ca nu este nici o problema daca in ultimul moment codul nu mai este necesar. Daca codul este necesar registrele temporare sunt copiate in adevaratele registre destinatie. Asa cum va puteti imagina, mentinerea tabelei de marcaj pentru pastrarea tuturor acestor informatii nu este simpla, dar se poate face avand suficient hardware.

Exista insa si o alta problema introdusa de codul speculativ, care nu se poate rezolva prin redenumirea registrelor. Ce se poate intampla daca o instructiune executata speculativ cauzeaza o exceptie? Un exemplu neplacut, dar nu fatal, este o instructiune LOAD care cauzeaza o ratare in memoria intermediara pe o masina cu o dimensiune mare a liniei de memorie intermediara (sa zicem, 256 de octeti) si o memorie cu mult mai lenta decat UCP si memoria intermediara. Daca un LOAD, care este de fapt necesar, opreste functionarea masinii pentru mai multe cicluri pana cand linia de memorie intermediara este reincarcata, nu prea este nimic de facut. Totusi blocarea masinii pentru citirea unui cuvant care se dovedeste a nu fi necesar este contraproductiva. Prea multe astfel de "optimizari' pot face UCP mai lenta decat daca nu le-ar avea deloc. Daca masina are memorie virtuala, care este discutata in capitolul 6, un LOAD speculativ poate chiar sa genereze o lipsa de pagina, care necesita o operatie cu discul pentru a incarca pagina dorita. Evenimentele false lipsa de pagina pot avea un efect important asupra performantei, asa ca trebuie evitate.

O posibila solutie ce se gaseste intr-o serie de masini moderne este sa se dispuna de o instructiune speciala SPECULATIVE_LOAD care incearca sa citeasca cuvantul din memoria intermediara, iar daca nu este acolo, renunta. Daca valoarea este acolo cand este de fapt necesara, se poate folosi, dar daca nu, hardware-ul trebuie sa o aduca imediat. Daca valoarea nu este de fapt necesara, nu va exista nici o penalizare pentru ratarea in memoria intermediara.

Un exemplu mai dificil se poate ilustra cu urmatoarea instructiune:

if (x>0) z = y/x;

unde x, y si z sunt variabile in virgula mobila. Sa presupunem ca toate variabilele sunt citite in registre in avans si impartirea in virgula mobila, care este mai lenta este inaltata deasupra testului if. Daca x este 0 rezulta o impartire prin zero si se termina programul. Rezultatul net este ca speculatia a cauzat esecul unui program corect. Mai rau decat atat, programatorul a pus cod explicit pentru a preveni acest lucru si tocmai asta s-a intamplat.

O posibila solutie este sa se dispuna de versiuni speciale de instructiuni care ar putea cauza exceptii. In plus, un bit, numit bit otrava (poison bit), este adunat la fiecare registru. Cand o instructiune speculativa speciala esueaza, in loc sa se genereze o capcana se seteaza bitul otrava din registrul rezultat. Daca acest registru este mai tarziu accesat de o instructiune obisnuita, atunci se activeaza capcana (asa cum ar trebui). Daca rezultatul nu este utilizat niciodata, bitul otrava este sters si in continuare nu apar efecte daunatoare datorate executiei speculative.