Κεφάλαιο 4: Pipelining 75

Transcript

1 Κεφάλαιο 4: Pipelining Pipelining Το pipelining (στα ελληνικά ορισμένες φορές καλείται σωλήνωση αλλά θα αποφύγουμε τη χρήση αυτού του όρου εδώ) είναι η λειτουργία κατά την οποία η εκτέλεση μιας διαδικασίας χωρίζεται σε διαφορετικές φάσεις οπότε διαφορετικές διαδικασίες μπορούν να εκτελούνται ταυτόχρονα ευρισκόμενες σε διαφορετική φάση η κάθε μια. Για παράδειγμα, έστω ότι κατασκευή ενός ποδηλάτου αποτελείται από πέντε φάσεις, τις Α, Β, Γ, Δ, Ε: Φάση Α: συγκόλληση του σκελετού με τις ρόδες Φάση Β: τοποθέτηση ταχυτήτων Φάση Γ: τοποθέτηση φρένων Φάση Δ: τοποθέτηση σέλας και τιμονιού Φάση Ε: τοποθέτηση φώτων, σχάρας, και δυναμό Έστω τώρα ότι πέντε διαφορετικοί εργάτες αναλαμβάνουν να εκτελέσουν αυτές τις φάσεις. Ο πρώτος αναλαμβάνει να εκτελέσει τη φάση Α, ο δεύτερος τη φάση Β, κοκ. Κατά τη λειτουργία του pipelining και οι πέντε εργάτες θα εργάζονται ταυτόχρονα αλλά σε διαφορετικό ποδήλατο ο καθένας όπως φαίνεται στο παρακάτω Σχήμα Χρόνος Ποδήλατο 1 Α Β Γ Δ Ε Ποδήλατο 2 Α Β Γ Δ Ε Ποδήλατο 3 Α Β Γ Δ Ε Ποδήλατο 4 Α Β Γ Δ Ε Ποδήλατο 5 Α Β Γ Δ Ε Τη χρονική περίοδο 1 ο εργάτης Α είναι απασχολημένος με το ποδήλατο 1, ενώ οι υπόλοιποι εργάτες περιμένουν τη σειρά τους. Τη χρονική περίοδο 2 ο εργάτης Α ασχολείται με το ποδήλατο 2 αφού το ποδήλατο 1 τώρα βρίσκεται στη φάση Β. Τη χρονική περίοδο 3 ο εργάτης Α ασχολείται με το ποδήλατο 3, ο εργάτης Β με το ποδήλατο 2 και ο εργάτης Γ με το ποδήλατο 1. Με τον ίδιο τρόπο συνεχίζουμε την παραγωγή ποδηλάτων ώστε κάθε εργάτης παραλαμβάνει ένα μισοτελειωμένο ποδήλατο από τον προηγούμενο εργάτη, προσθέτει το τμήμα εκείνο που πρέπει αυτός να προσθέσει και το παραδίδει στον επόμενο εργάτη ή το τελειώνει (αν είναι ο εργάτης Ε). Κάθε ποδήλατο είναι έτοιμο αφού ολοκληρωθεί και η φάση Ε. Έτσι το ποδήλατο 1 είναι έτοιμο μετά την χρονική περίοδο 5, το ποδήλατο 2 είναι έτοιμο μετά τη χρονική περίοδο 6 κλπ. Μέσα σε 9 χρονικές περιόδους έχουν ολοκληρωθεί 5 ποδήλατα. Είναι εύκολο να δει κανείς ότι μετά από Ν περιόδους θα έχουν ολοκληρωθεί Ν 4 ποδήλατα (ομοίως P ποδήλατα απαιτούν P+4 περιόδους για την παραγωγή τους). Ο λόγος είναι ότι τις 4 πρώτες περιόδους δεν απασχολούνται και οι 5 εργάτες, όχι γιατί δεν έχουν δουλειά αλλά γιατί περιμένουν τους προηγούμενους να τελειώσουν πρώτα. Οι 4 αυτές πρώτες χρονικές περίοδοι λέγονται και χρόνος γεμίσματος

2 Κεφάλαιο 4: Pipelining 76 της pipeline. Μέχρι να «γεμίσει» η pipeline δεν παράγεται κανένα ποδήλατο. Αφού όμως γεμίσει παράγεται ένα ποδήλατο κάθε μια χρονική περίοδο. Επιτάχυνση Το πραγματικό χρονικό διάστημα κάθε περιόδου είναι προφανώς άνευ σημασίας (αν π.χ. είναι 1 ώρα, 1 λεπτό, ή 1 δευτερόλεπτο). Αυτό που έχει σημασία είναι ότι όλες οι περίοδοι έχουν ίση διάρκεια διαφορετικά γίνεται αδύνατος ο συγχρονισμός της pipeline. Για παράδειγμα, ας υποθέσουμε ότι κάθε φάση απαιτεί 10 λεπτά (min) για την εκτέλεσή της. Σε αυτήν την περίπτωση χρειάζονται P+4 χρονικές περίοδοι για την παραγωγή P ποδηλάτων δηλαδή χρόνος (10P+40)min. Αν ασχολείταν μόνο ένας εργάτης για την παραγωγή των ποδηλάτων θα απαιτούνταν 50min για κάθε ποδήλατο, δηλαδή 50Pmin για P ποδήλατα. Ορίζουμε Επιτάχυνση = [Χρόνος παραγωγής P ποδηλάτων με ένα εργάτη] / [Χρόνος παραγωγής P ποδηλάτων με pipeline] Με άλλα λόγια, επιτάχυνση είναι ο λόγος του χρόνου παραγωγής ενός όγκου δουλειάς (π.χ. P ποδηλάτων) από μόνο ένα εργάτη ως προς το χρόνο παραγωγής του ίδιου όγκου δουλειάς από την pipeline. Η επιτάχυνση της παραγωγής ποδηλάτων στη συγκεκριμένη περίπτωση είναι Επιτάχυνση = (50P) / (10P+40) = 5 / (1+4/P) Βλέπουμε ότι όσο περισσότερα ποδήλατα παράγονται (P ) τόσο η επιτάχυνση τείνει στο όριο 5/1 αφού ο όρος 4/P τείνει στο μηδέν. Αυτό απλά μας λέει ότι όσο πιο πολλά ποδήλατα παράγονται τόσο πιο αμελητέος γίνεται συγκριτικά ο χρόνος γεμίσματος της pipeline σε σχέση με το συνολικό χρόνο παραγωγής. Επίσης όλοι οι εργάτες είναι απασχολημένοι κατά 100% του χρόνου (αν εξαιρέσουμε το γέμισμα της pipeline και το τέλος της παραγωγής) αφού κάθε φάση απαιτεί χρόνο εκτέλεσης 10min όσο δηλαδή διαρκεί και μια χρονική περίοδος. Αυτό απλά σημαίνει ότι μόλις ένας εργάτης τελειώσει την εργασία του σε ένα ποδήλατο πιάνει αμέσως το επόμενο. Πολύ συχνά ωστόσο συμβαίνει οι διάφορες φάσεις παραγωγής να μην απαιτούν τον ίδιο χρόνο εκτέλεσης. Για παράδειγμα, μπορεί η τοποθέτηση των φρένων στο ποδήλατο (Φάση Γ) να είναι πιο γρήγορη από όλες τις άλλες φάσεις, ενώ η τοποθέτηση φώτων, σχάρας και δυναμό (Φάση Ε) να είναι πιο αργή από όλες τις άλλες φάσεις. Για να μιλάμε πιο συγκεκριμένα, ας υποθέσουμε ότι οι χρόνοι εκτέλεσης των διαφόρων φάσεων έχουν ως εξής: Φάση Α: 10min Φάση Β: 9min Φάση Γ: 7min Φάση Δ: 10min Φάση Ε: 12min

3 Κεφάλαιο 4: Pipelining 77 Συνολικά ένας εργάτης μόνος του θα χρειαζόταν χρόνο ( )min = 48min για να εκτελέσει και τις 5 φάσεις παραγωγής ενός ποδηλάτου. Έτσι για P ποδήλατα θα χρειαζόταν 48Pmin. Η pipeline αντίστοιχα θα είχε χρόνο περιόδου 12min όσο δηλαδή και η διάρκεια της πιο χρονοβόρας φάσης (φάση Ε). Έτσι η pipeline θα χρειαζόταν χρόνο (12P+48)min για την παραγωγή P ποδηλάτων. Με άλλα λόγια η επιτάχυνση σ αυτήν την περίπτωση θα ήταν Επιτάχυνση = (48P) / (12P+48) = 4 / (1+4/P) δηλαδή θα έτεινε στο όριο 4/1 για μεγάλη παραγωγή ποδηλάτων (P ) και όχι στο όριο 5/1 που επιτυγχάναμε στο προηγούμενο παράδειγμα. Ο λόγος είναι η μη ομοιόμορφη κατανομή του χρόνου εργασίας ανάμεσα στις διάφορες φάσεις. Το αποτέλεσμα είναι αυτό που φαίνεται στον παρακάτω πίνακα Φάση Χρόνος απασχόλησης ανά περίοδο Χρόνος αναμονής ανά περίοδο Ποσοστό απασχόλησης Α 10min 2min 83.3% Β 9min 3min 75.0% Γ 7min 5min 58.3% Δ 10min 2min 83.3% Ε 12min 0min 100.0% Στον πίνακα αυτό υπονοείται ότι η περίοδος της pipeline είναι 12min. Με τα δεδομένα του προβλήματος είναι φανερό ότι ο εργάτης Α απασχολείται μόνο κατά τα 10 πρώτα λεπτά της περιόδου ενώ τα υπόλοιπα 2 λεπτά κάθεται και περιμένει, έχει δηλαδή ποσοστό απασχόλησης 83.3% (=10/12 100%). Ίδιους χρόνους αναμονής και ποσοστό απασχόλησης έχει ο εργάτης Δ. Αντίστοιχα ο εργάτης Β απασχολείται κατά 75% του χρόνου ενώ ο εργάτης Γ απασχολείται μόνο κατά 58.3% του χρόνου. Μόνο ο εργάτης Ε απασχολείται 100% του χρόνου αφού εκτελεί και την πιο χρονοβόρα διαδικασία. Αυτός ο εργάτης είναι και ο πιο άτυχος από όλους και αποτελεί το λαιμό του μπουκαλιού (bottleneck) της όλης διαδικασίας. Αν αυτός μπορούσε π.χ. να εκτελέσει την εργασία του σε 10 λεπτά αντί για 12 τότε θα μειωνόταν η περίοδος της pipeline, θα αναγκάζονταν και οι άλλοι εργάτες να απασχολούνται για περισσότερο ποσοστό του χρόνου και τελικά θα επιταχυνόταν η παραγωγή ποδηλάτων. Από την παραπάνω συζήτηση εξάγονται τα ακόλουθα συμπεράσματα 1. σκοπός της τεχνικής pipelining είναι η επιτάχυνση της εκτέλεσης μιας διαδικασίας με τον τεμαχισμό της σε επί μέρους φάσεις οι οποίες μπορούν να εκτελούνται ταυτόχρονα για ξεχωριστές διαδικασίες

4 Κεφάλαιο 4: Pipelining η επιτάχυνση που επιτυγχάνεται δεν είναι μόνο συνάρτηση του αριθμού των φάσεων αλλά και της εξισορρόπησης μεταξύ των χρόνων εκτέλεσης των διαφόρων φάσεων. Με άλλα λόγια αν τεμαχίσουμε μια διαδικασία σε 10 επί μέρους φάσεις αυτό δε σημαίνει ότι θα επιτύχουμε επιτάχυνση της διαδικασίας κατά 10 φορές αν δεν έχουμε προηγουμένως φροντίσει οι φάσεις αυτές να απαιτούν τον ίδιο (ή περίπου τον ίδιο) χρόνο εκτέλεσης. Pipelining στην αρχιτεκτονική των υπολογιστών Στην τεχνολογία των επεξεργαστών η τεχνική του pipelining είναι εξαιρετικά διαδεδομένη και πλέον αποτελεί αναπόσπαστο κομμάτι της αρχιτεκτονικής. Οι αρχές του pipelining είναι οι ίδιες με αυτές που εφαρμόζονται και στην περίπτωση των ποδηλάτων που είδαμε μόλις παραπάνω. Ωστόσο υπάρχουν πολλές λεπτομέρειες και τεχνικές που εφαρμόζονται για την βελτιστοποίηση της pipeline ενός επεξεργαστή. Οι πιο συνηθισμένες περιπτώσεις όπου εφαρμόζεται το pipelining σε ένα επεξεργαστή είναι το τμήμα εκτέλεσης των εντολών και η αριθμητική μονάδα κινητής υποδιαστολής. Αυτές οι δύο περιπτώσεις αναλύονται λεπτομερώς στις επόμενες ενότητες. 4.1 Το pipeline των εντολών Για να γίνει πιο εύκολα κατανοητή η σχεδίαση μιας pipeline για την εκτέλεση των εντολών ενός επεξεργαστή είναι σκόπιμο να χρησιμοποιήσουμε ένα συγκεκριμένο παράδειγμα. Το παράδειγμα αυτό είναι βασισμένο πάνω σε μια υποθετική γλώσσα που θα ονομάσουμε DLX και η οποία μοιάζει πολύ με τις γλώσσες των επεξεργαστών RISC. Η pipeline που θα μελετήσουμε θα είναι σχεδιασμένη ειδικά για την υποστήριξη της γλώσσας αυτής. Η γλώσσα αυτή είναι αρκετά απλή για να είναι εκπαιδευτικά χρήσιμη χωρίς να είναι αχρείαστα πολύπλοκη ενώ είναι αρκετά πολύπλοκη έτσι ώστε να διαφαίνονται τα βασικά προβλήματα που αντιμετωπίζει κάποιος ο οποίος προτίθεται να σχεδιάσει την pipeline για κάποια άλλη γλώσσα γενικά Η γλώσσα DLX Ο επεξεργαστής DLX υποτίθεται ότι έχει 32 καταχωρητές (registers) γενικού σκοπού μεγέθους 32 bits ο καθένας. Οι καταχωρητές αυτοί ονομάζονται R0, R1,..., R31. Επίσης υπάρχουν 32 καταχωρητές για πράξεις κινητής υποδιαστολής (F0, F1,..., F31) μεγέθους 32 bits. Σε περίπτωση που θέλουμε πράξεις κινητής υποδιαστολής διπλής ακρίβειας (double precision) χρησιμοποιούμε ζεύγη αυτών των καταχωρητών. Ειδικά ο καταχωρητής R0 περιέχει πάντα την τιμή 0 και δεν είναι δυνατό να γράψουμε άλλη τιμή σ αυτόν. Οι τρόποι διευθυνσιοποίησης στον DLX είναι μόλις 2, ο άμεσος (immediate) και η μετατόπιση (displacement) όπως φαίνεται και στα παρακάτω παραδείγματα Add R1,R2,#17 ;Πρόσθεσε στον καταχωρητή R2 ;τον αριθμό 17 (δεκαδικό) και το αποτέλεσμα

5 Κεφάλαιο 4: Pipelining 79 LW R1,120(R2) ;στον R1(άμεση κλήση) ;Φόρτωσε στον καταχωρητή R1 το ;περιεχόμενο της θέσης μνήμης 120+R2 ;(κλήση με μετατόπιση) Με τους δύο αυτούς τρόπους κλήσεως της μνήμης μπορούμε να υλοποιήσουμε άλλους δύο ακόμα τρόπους, την έμμεση κλήση (indirect) και την απόλυτη κλήση (absolute) χρησιμοποιώντας το μηδέν ή τον ειδικό καταχωρητή R0: LW R4,0(R1) LW R2,1520(R0) ;Φόρτωσε στον καταχωρητή R4 το ;περιεχόμενο της θέσης μνήμης R1 ;(έμμεση κλήση) ;Φόρτωσε στον καταχωρητή R2 το ;περιεχόμενο της θέσης μνήμης 1520, αφού ;ο καταχωρητής R0 είναι καρφωμένος στο μηδέν ;(απόλυτη κλήση) Οι εντολές της DLX Όλες οι εντολές της γλώσσας DLX είναι του ιδίου μήκους: 32 bits. Από αυτά, τα πρώτα 6 bits ορίζουν ένα ξεχωριστό κωδικό για κάθε εντολή (Opcode) ενώ τα υπόλοιπα πεδία είναι διαφορετικές παράμετροι που χρησιμοποιούνται από τις διαφορετικές εντολές. Συγκεκριμένα οι εντολές είναι τριών τύπων, όπως φαίνεται στο Σχήμα 22.

6 Κεφάλαιο 4: Pipelining Opcode rs1 rd Immediate Εντολές τύπου I, π.χ. εντολές load, store, εντολές με άμεσο όρισμα (rd rs1 πράξη Immediate), άλματα υπό συνθήκη όπου ελέγχεται η συνθήκη στον καταχωρητή rs1 (στην περίπτωση αυτή το πεδίο rd δεν χρησιμοποιείται) Opcode rs1 rs2 rd func Εντολές τύπου R, π.χ. πράξεις μεταξύ καταχωρητών (rd rs1 πράξη rs2). Το είδος της πράξης κωδικοποιείται από το πεδίο func, π.χ. func : Add, Sub, Mul, κλπ Opcode Offset Εντολές τύπου J, π.χ. άλματα χωρίς συνθήκη, διακοπές, επιστροφή από διακοπές, κλπ. Το offset που προστίθεται στον μετρητή προγράμματος (PC) είναι μεγέθους 26 bits. Σχήμα 22. Η μορφή των εντολών της γλώσσας DLX. Όλες οι εντολές έχουν μήκος 4 bytes και χωρίζονται σε εντολές τύπου I (immediate), τύπου R (register-to-register) και τύπου J (jumps) Οι φάσεις εκτέλεσης μιας εντολής Κάθε εντολή της γλώσσας DLX μπορεί να εκτελεστεί το πολύ σε 5 κύκλους του ρολογιού. Οι πέντε αυτοί κύκλοι είναι οι εξής 1. Φάση λήψης εντολής (Instruction Fetch) IR Mem[PC] NPC PC + 4 Κατά τη φάση αυτή διαβάζεται η εντολή από τη θέση μνήμης όπου δείχνει ο μετρητής εντολών (PC Program Counter) και αυτή καταχωρείται στον καταχωρητή εντολών (IR Instruction Register). Ο καταχωρητής NPC δείχνει στην επόμενη εντολή. 2. Φάση αποκωδικοποίησης / ανάγνωσης καταχωρητών (Instruction decode / register fetch)

7 Κεφάλαιο 4: Pipelining 81 A Reg[IR(6..10)] B Reg[IR(11..15)] Imm IR(16..31) Κατά τη φάση αυτή διαβάζονται οι τιμές των καταχωρητών που δείχνονται στα αντίστοιχα πεδία της εντολής, ενώ ταυτόχρονα αποκωδικοποιείται η εντολή. Επειδή στην φάση αυτή δεν ξέρουμε αν η εντολή είναι τύπου I, R, ή J, δεν ξέρουμε αν πρέπει να διαβάσουμε την τιμή του register που δείχνεται από τα bits του IR και να θεωρήσουμε τα bits ως τιμή immediate (εντολή τύπου Ι) ή πρέπει να διαβάσουμε τις τιμές των registers που δείχνονται από τα πεδία και του IR (περίπτωση εντολής τύπου R). Για το λόγο αυτό διαβάζουμε προληπτικά τις τιμές των registers που δείχνονται από τα πεδία και σε δύο προσωρινούς καταχωρητές A, B και το πεδίο των bits σε ένα προσωρινό καταχωρητή Imm. Σε επόμενη φάση θα αποφασίσουμε τι απ όλ αυτά μας χρειάζεται. 3. Φάση εκτέλεσης (Execution) Αν έχουμε εντολή κλήσης στη μνήμη ALUOutput A + Imm Αν έχουμε εντολή πράξης μεταξύ καταχωρητών ALUOutput A πράξη B Αν έχουμε εντολή πράξης μεταξύ καταχωρητή και άμεσου τελεστή ALUOutput A πράξη Imm Αν έχουμε εντολή άλματος υπό συνθήκη ALUOutput NPC + Imm Cond (A σύγκριση 0) Αν έχουμε εντολή άλματος χωρίς συνθήκη ALUOutput NPC + IR(6..31) Cond True Κατά τη φάση της εκτέλεσης γίνεται χρήση της μονάδας αριθμητικών και λογικών πράξεων (Arithmetic-Logical Unit ALU). Αν η εντολή είναι κλήση στη μνήμη (load, store) προστίθενται τα περιεχόμενα των καταχωρητών Α και Imm για να υπολογιστεί η διεύθυνση της μνήμης που θα χρησιμοποιηθεί κατά την κλήση. Αν η εντολή είναι κάποια πράξη μεταξύ καταχωρητών τότε γίνεται η πράξη μεταξύ των καταχωρητών A, B. Αν η εντολή είναι κάποια πράξη μεταξύ καταχωρητή και Immediate τότε προστίθενται πάλι οι καταχωρητές A και Imm. Αν η εντολή είναι άλμα υπό συνθήκη

8 Κεφάλαιο 4: Pipelining 82 υπολογίζεται η διεύθυνση στόχου, δηλαδή εκεί όπου καταλήγει το άλμα αν επιτύχει η συνθήκη, και υπολογίζεται το αποτέλεσμα της σύγκρισης του καταχωρητή A με το 0. Στην περίπτωση της σύγκρισης μεταξύ A και 0 ο τελεστής σύγκρισης είναι μια από τις σχέσεις,,,,,. Τέλος, αν έχουμε εντολή άλματος χωρίς συνθήκη προσθέτουμε το offset στον καταχωρητή NPC και θέτουμε το Condition flag = 1. Για όλες τις παραπάνω περιπτώσεις το αποτέλεσμα της πράξης που γίνεται στην ALU φυλάσσεται στον καταχωρητή ALUOutput. 4. Φάση πρόσβασης στη μνήμη / ολοκλήρωση αλμάτων (Memory access) Αν έχουμε εντολή κλήσης στη μνήμη LMD Mem[ALUOutput] (για load) ή Mem[ALUOutput] B (για store) Αν έχουμε εντολή άλματος (με ή χωρίς συνθήκη) If (Cond) then PC ALUOutput else PC NPC Κατά τη φάση αυτή οι μόνες εντολές που είναι ενεργές είναι οι εντολές load/store και τα άλματα. Αν η εντολή είναι load τότε διαβάζεται η θέση μνήμης που δείχνεται από τον καταχωρητή ALUOutput και το περιεχόμενο τοποθετείται στον προσωρινό καταχωρητή LMD (Load Memory Data). Αν πρόκειται για εντολή store τότε γράφεται στη μνήμη στη θέση που δείχνεται από τον καταχωρητή ALUOutput το περιεχόμενο του καταχωρητή B. Αν τέλος έχουμε εντολή άλματος (με ή χωρίς συνθήκη) τότε ενημερώνεται ο μετρητής προγράμματος PC είτε με την διεύθυνση της επόμενης εντολής που βρίσκεται στον καταχωρητή NPC, είτε με το στόχο του άλματος που βρίσκεται στον καταχωρητή ALUOutput. 5. Φάση εγγραφής καταχωρητών / μνήμης (Write back) Αν έχουμε εντολή πράξης μεταξύ καταχωρητών Reg[IR(16..20)] ALUOutput Αν έχουμε εντολή πράξης μεταξύ καταχωρητή και immediate Reg[IR(11..15)] ALUOutput Αν έχουμε εντολή load Reg[IR(11..15)] LMD

9 Κεφάλαιο 4: Pipelining 83 Η φάση εγγραφής των καταχωρητών είναι και η τελευταία φάση εκτέλεσης των εντολών. Αν η εντολή είναι πράξη μεταξύ καταχωρητών ή μεταξύ ενός καταχωρητή και ενός immediate τότε το περιεχόμενο του καταχωρητή της ALU (ALUOutput) αντιγράφεται στον κατάλληλο καταχωρητή γενικού σκοπού. Τέλος, αν η εντολή είναι load τότε το περιεχόμενο του καταχωρητή LMD αντιγράφεται στον κατάλληλο καταχωρητή γενικού σκοπού Η pipeline του DLX Instruction Fetch (IF) Instruction Decode (ID) Execute (EX) Memory Access (MEM) Write Back (WB) Zero? Cond M U X PC 4 Add Instruction Memory NPC IR R e g i s t e r s A B M U X M U X ALU ALU Out Data Memory Imm LMD M U X Σύμφωνα με τις φάσεις εκτέλεσης των εντολών που περιγράψαμε στην προηγούμενη ενότητα η pipeline του επεξεργαστή DLX φαίνεται στο παραπάνω Σχήμα. Στο σχήμα αυτό φαίνονται όλοι οι καταχωρητές, οι πολυπλέκτες (Multiplexers MUX) και οι μονάδες αριθμητικής-λογικής επεξεργασίας (ALU). Για λόγους απλούστευσης δεν φαίνονται όλα τα σήματα ελέγχου τα οποία ρυθμίζουν τη λειτουργία των πολυπλεκτών καθώς και το λογικό κύκλωμα αποκωδικοποίησης των εντολών το οποίο ουσιαστικά παράγει αυτά τα σήματα ελέγχου.

10 Κεφάλαιο 4: Pipelining 84 Instruction Fetch (IF) Instruction Decode (ID) Execute (EX) Memory Access (MEM) Write Back (WB) Zero? M U X PC 4 Add Instruction Memory R e g i s t e r s M U X M U X ALU Data Memory M U X IF/ID ID/EX EX/MEM MEM/WB Σχήμα 23. Η pipeline του επεξεργαστή DLX. Σ αυτό το διάγραμμα οι διάφορες φάσεις χωρίζονται με καταχωρητές κατάστασης, οι οποίοι παίρνουν το όνομα των φάσεων που συνδέουν, όπως IF/ID, ID/EX, EX/MEM, και MEM/WB. Στο Σχήμα 23 φαίνεται πώς πραγματικά υλοποιείται η pipeline των εντολών του DLX χρησιμοποιώντας καταχωρητές μεταξύ των φάσεων οι οποίοι φυλάσσουν όλη την πληροφορία που χρειάζεται η κάθε φάση από την προηγούμενη. Η σχεδίαση αυτή είναι πιο ξεκάθαρη από την προηγούμενη και συνήθως προτιμάται. Για παράδειγμα στο Σχήμα 5.2 ο καταχωρητής που συνδέει τις φάσεις IF και ID παίρνει το όνομα IF/ID και περιέχει μέσα του τους καταχωρητές NPC και IR οι οποίοι και εξαφανίζονται από το σχήμα. Αντίστοιχα, ο καταχωρητής ID/EX συνδέει τις φάσεις ID και ΕΧ. Αυτός περιέχει μέσα του τους καταχωρητές A, B, και Imm του αρχικού σχήματος. Ομοίως ο καταχωρητής EX/MEM περιέχει μέσα του τους καταχωρητές ALUOutput και το Cond bit του αρχικού σχήματος. Τέλος ο καταχωρητής MEM/WB περιέχει μέσα του τον καταχωρητή LMD. Εκτός από όλα αυτά οι παραπάνω καταχωρητές μεταφέρουν και όλα τα αναγκαία σήματα ελέγχου που χρειάζονται σε κάθε φάση της pipeline. Στην ιδανική περίπτωση, αν υποθέσουμε ότι δεν υπάρχει καμία σύγκρουση μεταξύ των εντολών, η εκτέλεση των εντολών θα γίνεται με τον τρόπο που φαίνεται στον παρακάτω πίνακα όπου σε κάθε κύκλο μηχανής ολοκληρώνεται και από μια εντολή.

11 Κεφάλαιο 4: Pipelining 85 Κύκλοι μηχανής Εντολή 1 IF ID EX MEM WB Εντολή 2 IF ID EX MEM WB Εντολή 3 IF ID EX MEM WB Εντολή 4 IF ID EX MEM WB Εντολή 5 IF ID EX MEM WB Στην πράξη συχνά ξεφεύγουμε από το ιδανικό αυτό χρονοδιάγραμμα εκτέλεσης. Οι λόγοι είναι πολλοί και θα τους αναλύσουμε με λεπτομέρεια στην επόμενη ενότητα. Κατά βάθος ωστόσο η αιτία είναι μια: ότι δηλαδή δύο διαφορετικές εντολές μπορεί να ζητήσουν να χρησιμοποιήσουν το ίδιο κομμάτι υλικού (π.χ. την ALU) για να εκτελέσουν την ίδια στιγμή δύο διαφορετικές ενέργειες. Αυτό φυσικά είναι αδύνατο και τότε λέμε ότι υπάρχει σύγκρουση μεταξύ των εντολών. Το πρόβλημα μπορεί να αντιμετωπιστεί με διάφορους τρόπους όπως θα δούμε παρακάτω. Σημειώνουμε ότι ο σχεδιασμός της pipeline συχνά απαιτεί επί πλέον υλικό το οποίο δεν θα υπήρχε αν δεν χρησιμοποιούσαμε pipelining. Για παράδειγμα, στην pipeline του Σχήματος 5.2 υπάρχουν 2 ALU, μια στη φάση IF και μια στη φάση EX. Η πρώτη χρειάζεται απλά για να προστίθεται το 4 στον PC ενώ η δεύτερη είναι ουσιαστικά η ALU για όλες τις αριθμητικές/λογικές πράξεις που εκτελεί ο επεξεργαστής. Αν δεν είχαμε pipeline θα μπορούσαμε να έχουμε μόνο μια ALU η οποία θα εκτελούσε την αντίστοιχη ενέργεια ανάλογα με τη φάση της εντολής. Στην υλοποίηση χωρίς pipeline κάθε εντολή θα απαιτούσε 5 κύκλους μηχανής για να εκτελεστεί και δεν θα υπήρχε επικάλυψη των φάσεων εκτέλεσης μεταξύ διαφορετικών εντολών: πρώτα θα τελείωνε μια εντολή και μετά θα άρχιζε η επόμενη. Φυσικά ένας τέτοιος υπολογιστής θα έτρεχε έως και 5 φορές πιο αργά. Επίσης στην pipeline μας χρησιμοποιούμε δύο διαφορετικές μνήμες, μια μνήμη εντολών (instruction memory) στη φάση IF και μια μνήμη δεδομένων (data memory) στη φάση MEM. Συνήθως αυτές οι δύο μνήμες υλοποιούνται με δύο διαφορετικές cache, μια για εντολές (instruction cache) και μια για δεδομένα (data cache). Ο λόγος είναι ότι αν χρησιμοποιούσαμε την ίδια μνήμη και για τις δύο περιπτώσεις τότε θα είχαμε σύγκρουση ανάμεσα σε μια εντολή που βρίσκεται στη φάση IF και σε μια άλλη εντολή που την ίδια στιγμή βρίσκεται σε φάση MEM. Και οι δύο εντολές θέλουν ταυτόχρονα να προσπελάσουν την ίδια μνήμη, και αυτό προκαλεί μεγάλο πρόβλημα. Αν δεν χρησιμοποιούσαμε pipelining δεν θα υπήρχε κανένας λόγος να έχουμε δύο ξεχωριστές μνήμες αφού μόνο μια εντολή εκτελείται κάθε στιγμή. Ένα ακόμα στοιχείο πολυπλοκότητας της pipeline είναι το γεγονός ότι πρέπει να μπορούμε ταυτόχρονα να διαβάζουμε δύο καταχωρητές και να γράφουμε έναν. Οι δύο αναγνώσεις προκύπτουν από τη φάση ID μιας εντολής ενώ η εγγραφή γίνεται στη φάση WB κάποιας άλλης εντολής που εκτελείται ταυτόχρονα με τη φάση ID της πρώτης εντολής.

12 Κεφάλαιο 4: Pipelining 86 Θεωρητικά, η αύξηση της ταχύτητας του επεξεργαστή χρησιμοποιώντας pipelining είναι το πολύ ανάλογη του αριθμού των φάσεων (ή βαθμίδων) της pipeline. Για παράδειγμα αν η pipeline μας έχει 5 βαθμίδες τότε η μέγιστη αύξηση της επίδοσης του επεξεργαστή είναι 5 φορές. Είδαμε ωστόσο ότι συνολικά η μέθοδος pipelining επιφέρει και σημαντική αύξηση της πολυπλοκότητας του υλικού. Η αύξηση της πολυπλοκότητας επιφέρει επίσης και μια επιμήκυνση του κύκλου του ρολογιού, με άλλα λόγια ο ρυθμός του ρολογιού γίνεται πιο αργός. Αυτός είναι ένας από τους παράγοντες που μετριάζει την απόδοση του pipelining. Ένας άλλος λόγος είναι η μη τέλεια κατάτμηση των φάσεων έτσι ώστε όλες οι φάσεις να μην απαιτούν ακριβώς τον ίδιο χρόνο για να εκτελεστούν. Όπως έχουμε ήδη δει η έλλειψη ομοιομορφίας ανάμεσα στο χρόνο εκτέλεσης των διαφόρων φάσεων μειώνει την επιτάχυνση που επιτυγχάνεται με το pipelining. Παράδειγμα. Ας θεωρήσουμε την pipeline του DLX που φαίνεται στο Σχήμα 23. Έστω ότι ο κύκλος του ρολογιού είναι 1nsec και έστω ότι για τις αριθμητικές πράξεις και τα άλματα απαιτούνται 4 κύκλοι του ρολογιού ενώ για τις εντολές πρόσβασης στη μνήμη απαιτούνται 5 κύκλοι. Ας υποθέσουμε ακόμα ότι οι αριθμητικές εντολές και οι εντολές πρόσβασης στη μνήμη έχουν συχνότητα 40% ενώ τα άλματα έχουν συχνότητα 20%, ενώ η πολυπλοκότητα της pipeline προσθέτει επί πλέον 0.1nsec στον κύκλο του ρολογιού. Με αυτά τα δεδομένα θέλουμε να υπολογίσουμε την επιτάχυνση που επιτυγχάνουμε με το pipelining σε σχέση με την απλή υλοποίηση χωρίς pipeline αν αγνοήσουμε τα άλλα προβλήματα όπως π.χ. τις συγκρούσεις μεταξύ των εντολών, κλπ. Στην περίπτωση χωρίς pipeline ο μέσος χρόνος εκτέλεσης (ΜΧΕ) μιας εντολής είναι [ΜΧΕ] χωρίς pipeline = 1nsec (40% % % 5) = 4.4nsec Στην περίπτωση του pipelining σε κάθε κύκλο του ρολογιού ολοκληρώνεται κατά μέσο όρο και από μια εντολή. Όμως τώρα ο κύκλος ρολογιού είναι 1nsec + 0.1nsec = 1.1nsec: [ΜΧΕ] με pipeline = 1.1nsec Η επιτάχυνση λοιπόν είναι τελικά Επιτάχυνση = [ΜΧΕ] χωρίς pipeline / [ΜΧΕ] με pipeline = 4.4nsec/1.1nsec = 4 αντί για την ιδανική τιμή Οι κίνδυνοι της pipeline (pipeline hazards) Το σημαντικότερο πρόβλημα στην επίτευξη μέγιστης επιτάχυνσης από την pipeline είναι οι λεγόμενοι κίνδυνοι (hazards) οι οποίοι προκύπτουν από τρεις διαφορετικές αιτίες

13 Κεφάλαιο 4: Pipelining οι δομικοί κίνδυνοι προκύπτουν στις περιπτώσεις όπου το υλικό δεν αρκεί για να καλύψει τις ανάγκες όλων των δυνατών συνδυασμών εντολών που μπορούν να προκύψουν στην pipeline. 2. οι κίνδυνοι των δεδομένων προκύπτουν όταν η εκτέλεση μιας εντολής εξαρτάται από το αποτέλεσμα μιας προηγούμενης εντολής 3. οι κίνδυνοι ελέγχου προκύπτουν από τις εντολές άλματος οι οποίες αλλάζουν τη ροή του προγράμματος Δομικοί κίνδυνοι (structural hazards) Όταν σχεδιάζουμε μια pipeline πρέπει να λαμβάνουμε υπ όψη μας όλους τους πιθανούς συνδυασμούς εντολών έτσι ώστε το υλικό (hardware) να επαρκέσει για την κάλυψη όλων των περιπτώσεων. Έτσι όπως είδαμε και στην pipeline του Σχήμα 23 για την DLX ίσως χρειάζεται να έχουμε επανάληψη υλικού για να ανταπεξέλθουμε στις απαιτήσεις. Αν όμως για λόγους οικονομίας ή για άλλους λόγους παραλείψουμε κάποιο τμήμα του υλικού τότε θα προκύψουν δομικοί κίνδυνοι. Για παράδειγμα, αν δεν βάλουμε δύο μνήμες στις βαθμίδες IF και MEM της pipeline αντίστοιχα τότε θα έχουμε μόνο μνήμη την οποία θα πρέπει να μοιράζονται οι δύο αυτές βαθμίδες. Έτσι μια εντολή i που χρησιμοποιεί τη μνήμη στη φάση EX (π.χ. load, store) δεν πρέπει να εκτελείται ταυτόχρονα με οποιαδήποτε άλλη εντολή j που βρίσκεται στη φάση IF. Το πρόβλημα αυτό είναι ένας τυπικός δομικός κίνδυνος και είναι καθαρά πρόβλημα υλικού. Η λύση αυτού του προβλήματος επιτυγχάνεται μόνο με την εισαγωγή ενός νεκρού κύκλου στην εντολή j. Ας δούμε το παράδειγμα που φαίνεται στον παρακάτω πίνακα χρονοδιαγράμματος Κύκλοι μηχανής Load IF ID EX MEM WB Εντολή 1 IF ID EX MEM WB Εντολή 2 IF ID EX MEM WB Εντολή 3 IF ID EX MEM WB Εντολή 4 IF ID EX MEM

14 Κεφάλαιο 4: Pipelining 88 Εδώ η εντολή Load συγκρούεται με την Εντολή 3 διότι και οι δύο προσπελαύνουν την μνήμη ταυτόχρονα, η μεν load ευρισκόμενη στη φάση MEM η δε Eντολή 3 στη φάση IF (η σύγκρουση φαίνεται με σκιασμένα τετράγωνα). Το πρόβλημα αντιμετωπίζεται με την εισαγωγή ενός νεκρού κύκλου (stall) στην pipeline τη χρονική στιγμή 4 (βλέπε τον παρακάτω πίνακα). Κύκλοι μηχανής Load IF ID EX MEM WB Εντολή 1 IF ID EX MEM WB Εντολή 2 IF ID EX MEM WB Εντολή 3 νεκρό IF ID EX MEM WB Εντολή 4 IF ID EX MEM Απλά η εντολή 3 καθυστερεί την έναρξή της κατά ένα κύκλο και έτσι δεν συγκρούεται με την εντολή Load. Φυσικά το κόστος που πληρώνουμε είναι η καθυστέρηση της pipeline κατά ένα κύκλο κάθε φορά που έχουμε τέτοιο δομικό κίνδυνο. Παράδειγμα Η pipeline υπό ιδανικές συνθήκες εκτελεί μια εντολή ανά κύκλο μηχανής, δηλαδή έχουμε [ΚΑΕ] ιδανικό = 1 κύκλος Έστω ότι οι εντολές load/store που δημιουργούν τον παραπάνω δομικό κίνδυνο έχουν συχνότητα 40%, και επομένως 40% των εντολών παράγονται με ρυθμό μια εντολή κάθε 2 κύκλους αντί μια εντολή κάθε 1 κύκλο. Στην περίπτωση αυτή λοιπόν έχουμε [ΚΑΕ] πραγματικό = (1 + 40% 1) = 1.4 κύκλοι Με άλλα λόγια η pipeline επιβραδύνεται κατά μέσο όρο κατά 40% και άρα ο παραπάνω δομικός κίνδυνος έχει πολύ μεγάλη επίδραση στην επίδοση της pipeline Κίνδυνοι δεδομένων (data hazards) Η σημαντικότερη επιπλοκή της χρήσης pipelining είναι ότι αλλάζει η χρονική συσχέτιση της εκτέλεσης των φάσεων των διαφορετικών εντολών. Έτσι αν το αποτέλεσμα μιας πράξης που γίνεται σε μια εντολή i χρησιμοποιείται από μια επόμενη εντολή j είναι

15 Κεφάλαιο 4: Pipelining 89 δυνατόν, λόγω του pipelining, να χρησιμοποιείται το αποτέλεσμα στην εντολή j πριν αυτό παραχθεί από την εντολή i. Θεωρήστε για παράδειγμα την εξής ακολουθία εντολών ADD R1, R2, R3 SUB R4, R5, R1 AND R6, R1, R7 OR R8, R1, R9 XOR R10,R1,R11 όπου σε κάθε εντολή ο πρώτος καταχωρητής είναι το αποτέλεσμα και οι δύο τελευταίοι καταχωρητές είναι οι τελεστές των πράξεων. Έτσι το αποτέλεσμα της πρώτης εντολής ADD είναι ο καταχωρητής R1, και το αποτέλεσμα αυτό χρησιμοποιείται από όλες τις επόμενες εντολές. Ο επόμενος πίνακας δείχνει την ιδεώδη ροή χρονισμού της pipeline. Κύκλοι μηχανής ADD R1,R2,R3 IF ID EX MEM WB SUB R4,R5,R1 IF ID EX MEM WB AND R6,R1,R7 IF ID EX MEM OR R8,R1,R9 IF ID EX XOR R10,R1,R11 IF ID Όπως φαίνεται με σκιασμένα τετράγωνα στον πίνακα, υπάρχουν κίνδυνοι δεδομένων στην ακολουθία εντολών που μας δόθηκε, και συγκεκριμένα μεταξύ της φάσης Write-Back της εντολής ADD η οποία παράγει το αποτέλεσμα R1, και των φάσεων ID των εντολών SUB, AND, και OR οι οποίες διαβάζουν το αποτέλεσμα R1 πριν αυτό παραχθεί από την ADD. Υπενθυμίζουμε ότι έτσι όπως έχουμε σχεδιάσει τις φάσεις των εντολών το αποτέλεσμα μιας πράξης γράφεται στη φάση WB στον κατάλληλο καταχωρητή, ενώ οι τελεστές μιας πράξης διαβάζονται στη φάση ID. Για το λόγο αυτό ακριβώς δημιουργείται και ο κίνδυνος δεδομένων που προαναφέραμε. Παρατηρήστε ότι δεν υπάρχει κίνδυνος δεδομένων μεταξύ της φάσης WB της ADD και της φάσης ID της XOR γιατί η φάση ID της XOR έπεται χρονικά της φάσης WB της ADD και επομένως θα έχει ήδη παραχθεί το αποτέλεσμα της ADD όταν θα το ζητήσει η XOR. Παρ όλ αυτά το πρόβλημα με τις άλλες τρεις εντολές παραμένει. Η μέθοδος της προώθησης (forwarding)

16 Κεφάλαιο 4: Pipelining 90 Το πρόβλημα που αναφέραμε παραπάνω μπορεί να αντιμετωπιστεί με μια απλή τεχνική που καλείται προώθηση (forwarding). Η μέθοδος αυτή βασίζεται στην παρατήρηση ότι το αποτέλεσμα της πράξης ADD είναι ήδη έτοιμο μετά την εκτέλεση της αριθμητικής πράξης, δηλαδή μετά τη φάση EX της εντολής ADD. Αν λοιπόν το αποτέλεσμα ήταν διαθέσιμο στις επόμενες εντολές από τη στιγμή εκείνη και όχι μετά την ολοκλήρωση της φάσης WB τότε το πρόβλημα θα είχε λυθεί χωρίς να χρειαστεί να εισάγουμε νεκρούς κύκλους (stall cycles). Χρησιμοποιώντας την παρατήρηση αυτή η μέθοδος προώθησης περιγράφεται ως εξής: α. Το αποτέλεσμα της πράξης που γίνεται στην ALU ανατροφοδοτείται από τον καταχωρητή EX/MEM πίσω στην είσοδο της ALU β. Αν το κύκλωμα προώθησης ανιχνεύσει ότι κάποια επόμενη εντολή ζητάει το αποτέλεσμα της προηγούμενης πράξης χρησιμοποιεί την τιμή που ανατροφοδοτείται από την έξοδο της ALU και όχι την τιμή που βρίσκεται στον αντίστοιχο καταχωρητή γενικού σκοπού. Κύκλοι μηχανής ADD R1,R2,R3 IF ID EX MEM WB SUB R4,R5,R1 IF ID EX MEM WB AND R6,R1,R7 IF ID EX MEM OR R8,R1,R9 IF ID EX XOR R10,R1,R11 IF ID Όπως φαίνεται και στον παραπάνω πίνακα χρονισμού η εισαγωγή της προώθησης επιλύει το πρόβλημα χωρίς νεκρούς κύκλους (stalls). Έτσι, για παράδειγμα, η εντολή SUB στη φάση ID (κύκλος 3) θα διαβάσει τη λάθος τιμή του καταχωρητή R1 αλλά αυτή η τιμή δε θα χρησιμοποιηθεί ποτέ διότι το κύκλωμα προώθησης θα χρησιμοποιήσει στη φάση EX (κύκλος 4) την έξοδο της ALU αντί για την τιμή του R1. Η έξοδος της ALU είναι το αποτέλεσμα της πράξης ADD που τελικά θα πάει στον R1 μετά από 2 κύκλους. Απλά στους κύκλους 4, 5, και 6 χρησιμοποιούμε πρόωρα αυτήν την τιμή χρησιμοποιώντας την έξοδο της ALU και όχι την τιμή που διαβάστηκε από τον καταχωρητή R1 στους κύκλους 3, 4, και 5 αντίστοιχα.

17 Κεφάλαιο 4: Pipelining 91 Zero? M U X M U X M U X ALU A L U O u t Data Memory M E M o u t A L U O u t ID/EX EX/MEM MEM/WB Σχήμα 24. Υλοποίηση της προώθησης στην pipeline του DLX. Οι γραμμές προώθησης φαίνονται με διακεκομμένες γραμμές. Η έξοδος της ALU (ALUOutput) που είναι τμήμα του καταχωρητή EX/MEM ανατροφοδοτείται και στις δύο εισόδους της ALU. Ομοίως ανατροφοδοτείται και η τιμή ALUOutput που είναι τμήμα του καταχωρητή MEM/WB. Επίσης η έξοδος της μνήμης που είναι τμήμα του καταχωρητή MEM/WB ανατροφοδοτείται στις εισόδους της ALU. Έτσι μπορούμε να έχουμε προώθηση τόσο της τιμής ALUOutput όσο και της τιμής MEMoutput μεταξύ των φάσεων EX και EX, και μεταξύ των φάσεων MEM και ΕΧ ανάμεσα σε διαφορετικές εντολές. Ένα κάπως διαφορετικό παράδειγμα κινδύνου δεδομένων που αντιμετωπίζεται με προώθηση είναι αυτό που προκύπτει από την ακολουθία εντολών ADD R1,R2,R3 LW R4,8(R1) SW 12(R1),R4 Στην περίπτωση αυτή έχουμε δύο κινδύνους. Ο πρώτος κίνδυνος είναι η χρήση του R1 στις εντολές LoadWord (LW) και StoreWord (SW) αφού προηγουμένως το R1 παράγεται από την εντολή ADD. Ο δεύτερος κίνδυνος είναι η χρήση του R4, η τιμή του οποίου επηρεάζεται από την εντολή LW, και κατόπιν χρησιμοποιείται από την εντολή StoreWord (SW). Αν δε χρησιμοποιηθεί προώθηση τότε οι κίνδυνοι φαίνονται με σκιασμένα τετράγωνα και διακεκομμένες γραμμές στο παρακάτω πίνακα χρονισμού της pipeline

18 Κεφάλαιο 4: Pipelining 92 Κύκλοι μηχανής ADD R1,R2,R3 IF ID EX MEM WB LW R4,8(R1) IF ID EX MEM WB SW 12(R1),R4 IF ID EX MEM Σύμφωνα με αυτό το χρονοδιάγραμμα η τιμή του καταχωρητή R1 παράγεται στον κύκλο 5 από την εντολή ADD και καταναλίσκεται στους κύκλους 3 και 4 από τις εντολές LW και SW αντίστοιχα κατά τις αντίστοιχες φάσεις ID. Επίσης, η τιμή του καταχωρητή R4 παράγεται στον κύκλο 6 από την εντολή LW και καταναλίσκεται επίσης στον κύκλο 6 από την εντολή SW. Έτσι έχουμε ουσιαστικά δύο ειδών κινδύνους λίγο διαφορετικούς μεταξύ τους το ένα είδος είναι εξ αιτίας του καταχωρητή R1 και το άλλο εξ αιτίας του R4. Παρ όλ αυτά και οι δύο παρακάτω κίνδυνοι επιλύονται με τη μέθοδο της προώθησης χωρίς την εισαγωγή επί πλέον νεκρών κύκλων. Πρώτα παρατηρούμε ότι ο κίνδυνος του R1 επιλύεται όπως και προηγουμένως παρατηρώντας ότι η τιμή του R1 είναι ήδη έτοιμη μετά την εκτέλεση της φάσης EX της ADD δηλαδή μετά τον κύκλο 3. Όσον αφορά τον κίνδυνο του R4, παρατηρούμε ότι η εντολή LW έχει τη νέα τιμή του R4 μετά την εκτέλεση της φάσης MEM (κύκλος 5). Επίσης η εντολή SW θα χρειαστεί την τιμή αυτή στη φάση MEM (κύκλος 6). Έτσι αν ανατροφοδοτήσουμε την τιμή εξόδου της μνήμης πίσω στην είσοδό της τότε η τιμή του R4 θα είναι διαθέσιμη στην SW πρόωρα και θα μπορεί να χρησιμοποιηθεί από αυτή χωρίς εισαγωγή νεκρών κύκλων. Οι νέες σχέσεις χρονισμού φαίνονται στον παρακάτω πίνακα με διακεκομμένες γραμμές. Κύκλοι μηχανής ADD R1,R2,R3 IF ID EX MEM WB LW R4,8(R1) IF ID EX MEM WB SW 12(R1),R4 IF ID EX MEM Ταξινόμηση των κινδύνων δεδομένων Κάθε κίνδυνος δεδομένων ανήκει σε μια από τις παρακάτω τρεις κατηγορίες ανάλογα με τη σειρά των εγγραφών και των αναγνώσεων των δεδομένων. Θεωρήστε δύο εντολές i και j, όπου η i εκτελείται πριν από την j. Έχουμε τους εξής κινδύνους

19 Κεφάλαιο 4: Pipelining 93 Ανάγνωση μετά από εγγραφή (Read-After-Write, RAW). Η εντολή j διαβάζει την τιμή από κάποια πηγή (καταχωρητή ή μνήμη) την οποία εγγράφει η εντολή i. Αυτή είναι και η πιο συνηθισμένη περίπτωση κινδύνου δεδομένων. Αυτό τον τύπο κινδύνου αντιμετωπίσαμε με τη μέθοδο της προώθησης που περιγράψαμε προηγουμένως. Εγγραφή μετά από εγγραφή (Write-After-Write, WAW). Η εντολή j γράφει μια τιμή πάνω στον ίδιο καταχωρητή ή μνήμη όπου γράφει και η εντολή i. Η κατάσταση αυτή αποτελεί κίνδυνο μόνο όταν η εγγραφή που κάνει η εντολή i τελειώνει μετά από την εγγραφή που κάνει η εντολή j διότι τότε ο καταχωρητής ή η μνήμη μένουν ενημερωμένοι με την λανθασμένη τιμή. Ο κίνδυνος αυτός δεν μπορεί να συμβεί στην pipeline του DLX διότι όλες οι εγγραφές διαρκούν ένα κύκλο. Το πρόβλημα μπορεί να προκύψει μόνο σε pipelines όπου η εγγραφή μπορεί να κρατήσει πάνω από ένα κύκλο. Για παράδειγμα, θεωρήστε μια υποθετική pipeline όπου η εγγραφή ή η ανάγνωση από τη μνήμη διαρκεί δύο κύκλους και θεωρήστε την εξής ακολουθία εντολών LW R1,8(R4) ADD R1,R2,R3 Η ακολουθία αυτή δημιουργεί τον κίνδυνο εγγραφής-μετά-από-εγγραφή όπως φαίνεται και στον παρακάτω πίνακα χρονισμού (υποθέτουμε ότι η αριθμητική εντολή δεν έχει καθόλου φάση MEM η οποία άλλωστε δε χρειάζεται) Κύκλοι μηχανής LW R1,8(R4) IF ID EX MEM 1 MEM 2 WB ADD R1,R2,R3 IF ID EX WB Αν δε ληφθούν κάποια μέτρα για την αντιμετώπιση του προβλήματος αυτού τότε η τιμή που θα μείνει στον R1 μετά από την εκτέλεση αυτών των εντολών θα είναι η τιμή που γράφτηκε από την LW και όχι αυτή που γράφτηκε από την ADD. Η λύση εδώ είναι η εισαγωγή νεκρών κύκλων στη δεύτερη εντολή. Εγγραφή μετά από ανάγνωση (Write-After-Read, WAR). Η εντολή j γράφει μια τιμή πάνω στον ίδιο καταχωρητή ή θέση μνήμης την οποία διαβάζει η εντολή i. Αν η ανάγνωση από την i γίνεται πάντα πριν από την εγγραφή από την j τότε δεν υπάρχει πρόβλημα. Για παράδειγμα, δεν προκύπτει ποτέ το πρόβλημα αυτό στην pipeline του DLX αφού η ανάγνωση τιμών γίνεται πάντα στη φάση ID και η εγγραφή γίνεται στη φάση WB. Σε μια άλλη όμως pipeline όπου η εγγραφή ή η ανάγνωση από τη μνήμη διαρκεί π.χ. 3 κύκλους και στον δεύτερο κύκλο της μνήμης (MEM2) γίνεται ανάγνωση της διεύθυνσης τότε έχουμε πρόβλημα όπως φαίνεται με την παρακάτω ακολουθία εντολών

20 Κεφάλαιο 4: Pipelining 94 SW R4,8(R1) ADD R1,R2,R3 και τον αντίστοιχο πίνακα χρονισμού Κύκλοι μηχανής SW R4,8(R1) IF ID EX MEM 1 MEM 2 ΜΕΜ 3 WB ADD R1,R2,R3 IF ID EX WB Πάλι το πρόβλημα αντιμετωπίζεται με την εισαγωγή νεκρών κύκλων στην δεύτερη εντολή. Σημειώνουμε ότι η ανάγνωση μετά από ανάγνωση δεν αποτελεί κίνδυνο. Κίνδυνοι που απαιτούν εισαγωγή νεκρών κύκλων Στην pipeline του DLX είδαμε ότι υπάρχουν ουσιαστικά μόνο οι κίνδυνοι ανάγνωσης μετά από εγγραφή. Είδαμε επίσης πώς κάποιοι από αυτούς τους κινδύνους αντιμετωπίζονται με τη μέθοδο της προώθησης χωρίς εισαγωγή νεκρών κύκλων. Παρ όλ αυτά υπάρχουν ακόμα και στην περίπτωση του DLX κίνδυνοι δεδομένων οι οποίοι απαιτούν εισαγωγή νεκρών κύκλων. Ας θεωρήσουμε για παράδειγμα, την εξής ακολουθία εντολών LW R1,8(R2) SUB R4,R1,R5 AND R6,R1,R7 OR R8,R1,R9 Η περίπτωση αυτή διαφέρει από τη διαδοχή αριθμητικών πράξεων που είδαμε προηγουμένως. Εδώ ο πίνακας χρονισμού (αν δεν γίνει προώθηση) είναι ο εξής Κύκλοι μηχανής LW R1,8(R2) IF ID EX MEM WB SUB R4,R1,R5 IF ID EX MEM WB AND R6,R1,R7 IF ID EX MEM OR R8,R1,R9 IF ID EX

21 Κεφάλαιο 4: Pipelining 95 Η τιμή του R1 εγγράφεται από την εντολή LW στον κύκλο 5 και διαβάζεται από τις εντολές SUB, AND, OR, στους κύκλους 3, 4, και 5, αντίστοιχα. Ακόμα κι αν χρησιμοποιηθεί η μέθοδος της προώθησης, το πρόβλημα μεταξύ των εντολών LW και SUB δεν μπορεί να αντιμετωπιστεί χωρίς εισαγωγή νεκρών κύκλων. Ωστόσο το πρόβλημα μεταξύ των εντολών LW και AND και μεταξύ των LW και OR αντιμετωπίζεται με την προώθηση. Πράγματι, παρατηρούμε ότι η εντολή LW παράγει τη νέα τιμή του R1 στο τέλος του κύκλου MEM (κύκλος 4). Αν ανατροφοδοτήσουμε την τιμή της εξόδου της μνήμης στην είσοδο της ALU μπορούμε να χρησιμοποιήσουμε τη σωστή τιμή του R1 στους κύκλους EX των εντολών AND και OR παρακάμπτοντας τη λάθος τιμή που διαβάστηκε από τις εντολές αυτές στους κύκλους ID (βλ. τον παρακάτω πίνακα χρονισμού). Κύκλοι μηχανής LW R1,8(R2) IF ID EX MEM WB SUB R4,R1,R5 IF ID EX?? MEM WB AND R6,R1,R7 IF ID EX MEM OR R8,R1,R9 IF ID EX Τ ο πρόβλημα μεταξύ της LW και AND λύνεται με προώθηση. Για την LW και ΟR δεν υπάρχει πρόβλημα. Υπάρχουν δύο λύσεις : α) στον κύκλο 5 η φάση WB της εντολής LW να πραγματοποιείται νωρίτερα στο πρώτο μισό του κύκλου και η ανάγνωση του καταχωρητή στον εντολή OR να πραγματοποιείται αργότερα στο δεύτερο μισό του ίδιου κύκλου. Β) το πρόβλημα να λυθεί με προώθηση. Παραμένει λοιπόν το πρόβλημα μεταξύ των εντολών LW και SUB. Η τιμή του R1 γίνεται γνωστή στο τέλος του κύκλου MEM της εντολής LW (κύκλος 4) και χρησιμοποιείται από τον κύκλο ΕΧ της εντολής SUB (κύκλος 4). Ακόμα και με προώθηση το πρόβλημα παραμένει αφού δεν μπορούμε να κάνουμε προώθηση πίσω στο χρόνο! Γενικά το πρόβλημα προκύπτει όταν μια εντολή Load προηγείται μιας αριθμητικής εντολής. Η περίπτωση αυτή καλείται εσωτερικό κλείδωμα (interlocking) και αντιμετωπίζεται με την εισαγωγή νεκρών κύκλων με ή χωρίς τη χρήση της τεχνολογίας των μεταφραστών (compilers). Η απλούστερη λύση είναι η απλή εισαγωγή νεκρών κύκλων όπως φαίνεται στον παρακάτω πίνακα χρονισμού

22 Κεφάλαιο 4: Pipelining 96 Κύκλοι μηχανής LW R1,8(R2) IF ID EX MEM WB SUB R4,R1,R5 IF ID νεκρό EX MEM WB AND R6,R1,R7 IF νεκρό ID EX MEM OR R8,R1,R9 νεκρό IF ID EX Με την εισαγωγή ενός νεκρού κύκλου στις επόμενες εντολές και με τη χρήση της προώθησης λύνεται το πρόβλημα αφού η τιμή του R1 που παράγεται στον κύκλο 4 από την εντολή LW μπορεί να προωθηθεί στις φάσεις ΕΧ των εντολών SUB και ΑΝD. παρατηρείστε ότι μεταξύ των εντολών LW και OR δεν απαιτείται καθόλου προώθηση αφού μετά τη φάση WB της LW η σωστή τιμή του καταχωρητή R1 βρίσκεται γραμμένη στον καταχωρητή R1. Εναλλακτικά μπορούμε να χρησιμοποιήσουμε προώθηση και επαναδιάταξη της σειράς των εντολών προκειμένου να αποφύγουμε την εισαγωγή νεκρών κύκλων. Η ιδέα είναι η εξής: αφού μόνες περιπτώσεις όπου έχουμε εσωτερικό κλείδωμα είναι οι εντολές Load ακολουθούμενες από αριθμητικές εντολές τότε προσπαθούμε στο επίπεδο του λογισμικού να αποφύγουμε αυτές τις περιπτώσεις στο βαθμό που αυτό γίνεται χωρίς να αλλοιώνεται φυσικά η λογική του προγράμματος. Παράδειγμα. Έστω η ακολουθία εντολών υψηλού επιπέδου a = b + c; d = e - f; Μια απλοϊκή υλοποίηση του προγράμματος σε γλώσσα μηχανής DLX θα ήταν η εξής: LW Rb,b LW Rc,c ADD Ra,Rb,Rc SW a,ra LW Re,e LW Rf,f SUB Rd,Re,Rf SW d,rd

23 Κεφάλαιο 4: Pipelining 97 Η υλοποίηση αυτή δημιουργεί εσωτερικό κλείδωμα μεταξύ των εντολών LW Rc,c και ADD Ra,Rb,Rc και μεταξύ των εντολών LW Rf,f και SUB Rd,Re,Rf. Μια επαναδιάταξη της σειράς των εντολών όπως η παρακάτω LW Rb,b LW Rc,c LW Re,e ADD Ra,Rb,Rc LW Rf,f SW a,ra SUB Rd,Re,Rf SW d,rd λύνει το πρόβλημα αφού απομακρύνει τις επίμαχες εντολές μεταξύ τους χωρίς να επηρεάζεται η λογική του προγράμματος. Προφανώς η λύση αυτή είναι προτιμότερη αφού είναι ανώδυνη, και δεν εισάγει νεκρούς κύκλους μεταξύ των φάσεων των εντολών. Φυσικά υπάρχουν περιπτώσεις όπου αυτή η λύση δεν είναι εφικτή, π.χ. όταν η αναδιάταξη των εντολών αλλάζει τη λογική του προγράμματος. Σε αυτήν την περίπτωση η εισαγωγή νεκρών κύκλων είναι αναπόφευκτη Κίνδυνοι ελέγχου (control hazards) Οι κίνδυνοι που έχουν και τη μεγαλύτερη επίπτωση στην επίδοση της pipeline είναι οι κίνδυνοι ελέγχου οι οποίοι προέρχονται από την αλλαγή ροής του προγράμματος εξ αιτίας κάποιου άλματος (με ή χωρίς συνθήκη). Ας δούμε ποια επίπτωση έχει ένα άλμα στον χρονισμό της pipeline. Στον επόμενο πίνακα φαίνεται η εκτέλεση των φάσεων των διαφόρων εντολών μετά από μια εντολή branch. Κύκλοι μηχανής Εντολή branch IF ID EX MEM WB Επόμενη εντολή IF νεκρό νεκρό IF ID EX MEM WB Επόμενη εντολή+1 IF ID EX MEM Επόμενη εντολή+2 IF ID EX Σύμφωνα με τον αρχικό σχεδιασμό της pipeline, κατά την εκτέλεση ενός άλματος υπό συνθήκη γίνεται γνωστή η διεύθυνση της επόμενης εντολής αφού ελεγχθεί πρώτα η συνθήκη, δηλαδή στη φάση MEM. Αν η συνθήκη πετύχει τότε η διεύθυνση της επόμενης εντολής είναι η τιμή του ALUOutput διαφορετικά η διεύθυνση της επόμενης εντολής είναι η τιμή του NPC. Αλλά και στην περίπτωση του άλματος χωρίς συνθήκη η νέα τιμή του PC

24 Κεφάλαιο 4: Pipelining 98 δίνεται στη φάση MEM (βλ. Ενότητα 4.1.3). Και στις δύο περιπτώσεις χάνονται τρεις κύκλοι μηχανής διότι η επόμενη εντολή πρέπει να ξαναρχίσει μετά από την ολοκλήρωση της φάσης MEM της εντολής άλματος. Όπως φαίνεται και στον παραπάνω πίνακα κατά τον κύκλο 2 μπαίνει στην pipeline εσφαλμένα η επόμενη εντολή. Όταν διαπιστωθεί μετά το τέλος του κύκλου 2 ότι η πρώτη εντολή ήταν άλμα σταματάει αμέσως η εκτέλεση της επόμενης εντολής και εισάγονται νεκροί κύκλοι μέχρι να διαπιστωθεί ποια είναι η διεύθυνση της σωστής εντολής που πρέπει να εκτελεστεί. Αυτό γίνεται στον κύκλο 5, μετά δηλαδή και την ολοκλήρωση της φάσης MEM της εντολής άλματος. Στον κύκλο 5 ξεκινάμε πάλι από την αρχή, δηλαδή πάλι από τη φάση IF, αφού πρόκειται για μια καινούργια εντολή. Έτσι έχουν συνολικά χαθεί 3 κύκλοι (οι κύκλοι 2,3,4 της επόμενης εντολής) και άρα το κόστος ενός άλματος είναι 3 επί πλέον κύκλοι, πράγμα που αποτελεί πολύ σημαντικό κόστος εις βάρος της επίδοσης της pipeline. Για παράδειγμα αν τα άλματα αποτελούν το 20% όλων των εντολών τότε ο χρόνος εκτέλεσης γίνεται 1 κύκλος για το 80% των εντολών και 4 κύκλοι για το 20% των εντολών, δηλαδή ο Μέσος Χρόνος Εκτέλεσης (ΜΧΕ) μιας εντολής γίνεται ΜΧΕ = = 1.6 κύκλοι ανά εντολή έχουμε δηλαδή 60% επιβάρυνση της επίδοσης της pipeline ως προς το ιδεώδες που είναι 1 κύκλος ανά εντολή. Η τακτική που θα ακολουθήσουμε για να μειώσουμε αυτό το σημαντικό κόστος είναι 1. να βρίσκουμε αν το άλμα θα γίνει ή όχι νωρίτερα από τη φάση MEM 2. να υπολογίζουμε τη διεύθυνση του στόχου του άλματος νωρίτερα από τη φάση MEM. Και τα δύο χρειάζονται αν θέλουμε να μειώσουμε τον αριθμό των χαμένων κύκλων της pipeline λόγω των αλμάτων. Αυτό επιτυγχάνεται αν παρατηρήσουμε ότι στα άλματα με συνθήκη η σύγκριση γίνεται μεταξύ ενός καταχωρητή γενικού σκοπού και του μηδενός. Οι καταχωρητές διαβάζονται κατά τη φάση ID οπότε η σύγκριση μπορεί να γίνει στη φάση αυτή. Επίσης παρατηρούμε ότι ο υπολογισμός του στόχου του άλματος μπορεί να γίνει κατά τη φάση αποκωδικοποίησης, απλά αν προσθέσουμε στον PC το offset. Θα πρέπει λοιπόν να μεταφέρουμε το κύκλωμα σύγκρισης με το μηδέν στη φάση ID και να προσθέσουμε μια ακόμα αριθμητική μονάδα στη φάση ID για τον υπολογισμό του αθροίσματος PC+Offset. Το Σχήμα 25 δείχνει το σχεδιάγραμμα της βελτιωμένης pipeline.

25 Κεφάλαιο 4: Pipelining 99 Instruction Fetch (IF) Instruction Decode (ID) Execute (EX) Memory Access (MEM) Write Back (WB) M U X Add PC 4 Add Instruction Memory N P C I R R e g i s t e r s Zero? C o n d Α Β M U X ALU Data Memory M U X I m m IF/ID ID/EX EX/MEM MEM/WB Σχήμα 25. Τροποποιημένη pipeline εντολών DLX με στόχο το γρηγορότερο υπολογισμό των διευθύνσεων αλμάτων. Τώρα ο στόχος του άλματος είναι γνωστός στη φάση ID. Με τη μετατροπή της pipeline που φαίνεται στο Σχήμα 25 υπολογίζονται και οι δύο πιθανές διευθύνσεις της επόμενης εντολής μετά από το άλμα μέσα στις φάσεις IF και ID. Αν το άλμα δεν γίνει τότε η επόμενη διεύθυνση είναι η NPC που υπολογίζεται στη φάση IF. Αν το άλμα γίνει τότε η επόμενη διεύθυνση είναι η NPC+Offset που υπολογίζεται στη φάση ID. Επίσης στη φάση ID υπολογίζεται η συνθήκη του άλματος (αν αυτό είναι άλμα με συνθήκη) κάνοντας σύγκριση του καταχωρητή A με το μηδέν. Έτσι μετά το τέλος της φάσης ID όχι μόνο γνωρίζουμε αν το άλμα γίνει ή όχι αλλά γνωρίζουμε και ποια είναι η διεύθυνση της επόμενης εντολής. Έτσι τώρα ο πίνακας χρονισμού γίνεται ο παρακάτω

26 Κεφάλαιο 4: Pipelining 100 Κύκλοι μηχανής Εντολή branch IF ID EX MEM WB Επόμενη εντολή IF IF ID EX MEM WB Επόμενη εντολή+1 IF ID EX MEM WB Επόμενη εντολή+2 IF ID EX MEM WB Μετά από μια εντολή άλματος η επόμενη εντολή κάνει ένα κύκλο παραπάνω. Ο λόγος είναι ότι κατά τον κύκλο 2 εκτελέστηκε η φάση IF μιας λάθος εντολής. Κατά τον κύκλο 3 έχει ήδη ολοκληρωθεί η φάση ID του άλματος και επομένως γνωρίζουμε ποια είναι η σωστή επόμενη εντολή. Στον κύκλο 3 αρχίζει η εκτέλεση αυτής της εντολής. Ακόμα και με αυτή τη βελτίωση υπάρχουν πράγματα που μπορούν να γίνουν για να βελτιωθεί η επίδοση της pipeline ακόμα περισσότερο. Υπάρχουν 4 διαφορετικές μέθοδοι διαχείρισης των αλμάτων με διαφορετικούς βαθμούς πολυπλοκότητας και διαφορετικές επιδόσεις ταχύτητας. Αυτές περιγράφονται παρακάτω. Για απλούστευση της συζήτησης θα υποθέσουμε ότι η εντολή άλματος είναι η εντολή i ενώ ο στόχος του άλματος (η επόμενη εντολή που θα εκτελεστεί αν το άλμα γίνει) είναι η εντολή j. Α. Εισαγωγή πάντα ενός κύκλου καθυστέρησης Κατά τη μέθοδο αυτή αγνοείται πάντα η φάση IF της εντολής i+1 είτε η συνθήκη του άλματος επιτύχει είτε αποτύχει. Αυτή είναι η απλούστερη μέθοδος αλλά φυσικά εισάγει πάντα ένα κύκλο καθυστέρησης ακόμα κι όταν αυτός δεν χρειάζεται. Για παράδειγμα αν το άλμα της εντολής i δεν γίνει τότε η εντολή i+1 ορθώς είχε κληθεί και επομένως δεν υπάρχει λόγος να ξαναδιαβαστεί η φάση IF της εντολής αυτής. Αν φυσικά το άλμα γίνει τότε προφανώς πρέπει να εκτελεστεί η εντολή j και επομένως πάει χαμένος ο κύκλος IF της εντολής i+1. Β. Πρόβλεψη ότι το άλμα δεν θα γίνει (predict not taken) Κατά τη μέθοδο αυτή κάνουμε μια πρόβλεψη ότι το άλμα δεν θα γίνει και συνεχίζουμε, όπως και πριν, την εκτέλεση της φάσης IF της εντολής i+1. Τώρα όμως η συμπεριφορά της pipeline είναι διαφορετική ανάλογα με το αν το άλμα θα γίνει ή όχι. Αν το άλμα δε γίνει τότε συνεχίζουμε κανονικά σα να μη συνέβη τίποτε. Αν το άλμα γίνει τότε ξεκινάμε την εκτέλεση της εντολής j. Με άλλα λόγια, η μόνη διαφορά της μεθόδου αυτής από την προηγούμενη είναι ότι δεν ξαναεκτελούμε τη φάση IF της εντολής i+1 αν το άλμα δεν γίνει. Οι δύο πίνακες χρονισμού που ακολουθούν δείχνουν τη συμπεριφορά της pipeline ανάλογα με το αν το άλμα θα γίνει ή όχι.

27 Κεφάλαιο 4: Pipelining 101 Κύκλοι μηχανής Εντολή i (άλμα) το άλμα δεν εκτελείται IF ID EX MEM WB Εντολή i+1 IF ID EX MEM WB Εντολή i+2 IF ID EX MEM WB Εντολή i+3 IF ID EX MEM WB Κύκλοι μηχανής Εντολή i (άλμα) το άλμα εκτελείται IF ID EX MEM WB Εντολή i+1 IF Εντολή j IF ID EX MEM WB Εντολή j+1 IF ID EX MEM WB Γ. Πρόβλεψη ότι το άλμα θα γίνει (predict taken) Κατά τη μέθοδο αυτή κάνουμε μια πρόβλεψη ότι το άλμα θα γίνει και φέρνουμε από τη μνήμη την εντολή j αντί για την εντολή i+1. Στην pipeline του DLX αυτή η μέθοδος δεν έχει νόημα διότι η διεύθυνση του στόχου j γίνεται γνωστή κατά την ίδια φάση όπου αποφασίζουμε αν το άλμα θα γίνει ή όχι (φάση ID). Η μέθοδος μπορεί να έχει νόημα μόνο σε περιπτώσεις όπου η απόφαση για το αν θα γίνει το άλμα ή όχι είναι πιο πολύπλοκη και επομένως καθυστερεί περισσότερο από τον υπολογισμό της διεύθυνσης του στόχου. Δ. Καθυστερημένο άλμα (delayed branch) Η μέθοδος αυτή είναι και η πιο προχωρημένη από τις τέσσερεις μεθόδους που αναφέρουμε εδώ και χρησιμοποιείται σε διάφορους επεξεργαστές. Κατά τη μέθοδο αυτή η εντολή i+1 εκτελείται πάντα είτε το άλμα της εντολής i γίνει είτε όχι. Οι παρακάτω πίνακες δείχνουν το χρονισμό της pipeline στις δύο αυτές περιπτώσεις.

28 Κεφάλαιο 4: Pipelining 102 Κύκλοι μηχανής Εντολή i (άλμα) το άλμα δεν εκτελείται IF ID EX MEM WB Εντολή i+1 IF ID EX MEM WB Εντολή i+2 IF ID EX MEM WB Εντολή i+3 IF ID EX MEM WB Κύκλοι μηχανής Εντολή i (άλμα) το άλμα εκτελείται IF ID EX MEM WB Εντολή i+1 IF ID EX MEM WB Εντολή j IF ID EX MEM WB Εντολή j+1 IF ID EX MEM WB Το σημαντικό πλεονέκτημα της μεθόδου αυτής είναι το γεγονός ότι δεν χάνεται κανένας κύκλος όπως βλέπουμε και από τους πίνακες χρονισμού εφόσον βέβαια υπάρχει κάποια χρήσιμη εντολή που μπορεί να εκτελεστεί μετά την εντολή άλματος (εντολή i+1). Το πρόβλημα με τη μέθοδο είναι ακριβώς το γεγονός ότι δεν είναι πάντα δυνατόν να εκτελεστεί κάποια χρήσιμη εντολή μετά το άλμα. Η μέθοδος αυτή υλοποιείται σε συνδυασμό με το λογισμικό του μεταφραστή που παράγει τις εντολές μηχανής ξεκινώντας από κάποια γλώσσα υψηλού επιπέδου. Αυτό που συνήθως γίνεται είναι ότι ο μεταφραστής παράγει σε πρώτη φάση κώδικα όπου μετά από κάποια εντολή άλματος τοποθετεί την εντολή no-op (no-operation) η οποία δεν κάνει τίποτα. Σε δεύτερη φάση ο μεταφραστής προσπαθεί να βάλει κάποια χρήσιμη εντολή στη θέση της εντολής no-op. Φυσικά αυτό θα γίνει μόνο εφόσον δεν αλλοιώνεται η λογική του προγράμματος. Παρακάτω δείχνουμε κάποια τέτοια παραδείγματα βελτιστοποίησης του κώδικα που παράγει ο μεταφραστής. Η προτιμότερη περίπτωση είναι να τοποθετηθεί η εντολή ακριβώς πριν από την εντολή άλματος στη θέση του no-op όπως δείχνει το παράδειγμα:

29 Κεφάλαιο 4: Pipelining 103 Κώδικας πριν από τη βελτιστοποίηση... ADD R1,R2,R3 if R2 = 0 then noop Κώδικας μετά τη βελτιστοποίηση... if R2 = 0 then ADD R1,R2,R Ο λόγος που μπορούμε να κάνουμε αυτή την αλλαγή της σειράς των εντολών εδώ είναι ότι η συνθήκη του άλματος (R2=0) δεν εξαρτάται από το αποτέλεσμα της εντολής ADD R1,R2,R3 (το αποτέλεσμα της οποίας πάει στον καταχωρητή R1). Δεν είναι πάντα εφικτό να γίνει μια τέτοια αλλαγή της σειράς των εντολών χωρίς να παραβιάζεται η λογική του προγράμματος. Για παράδειγμα στον ακόλουθο κώδικα Κώδικας πριν από τη βελτιστοποίηση... ADD R1,R2,R3 if R1 = 0 then noop SUB R4,R5,R η συνθήκη του άλματος (R1=0) επηρεάζεται από το αποτέλεσμα της εντολής ADD R1,R2,R3 και επομένως θα ήταν λάθος να εκτελέσουμε πρώτα το άλμα και μετά την εντολή ADD. Αν ωστόσο περιμένουμε ότι το άλμα δε θα γίνει τότε μπορούμε ίσως να χρησιμοποιήσουμε την επόμενη εντολή μετά το no-op. Κώδικας μετά τη βελτιστοποίηση... ADD R1,R2,R3 if R1 = 0 then SUB R4,R5,R6...