[Advcomparch] Name dependencies στον Tomasulo
Nikos Anastopoulos
anastop at cslab.ece.ntua.gr
Thu Jun 18 14:43:13 EEST 2009
Να ξεκαθαρίσουμε κάποια πράγματα αρχικά. Οι εξαρτήσεις των εντολών είναι
χαρακτηριστικό του προγράμματος. Τα hazards είναι χαρακτηριστικό της
εκάστοτε αρχιτεκτονικής. Το ότι υπάρχει π.χ. μια output dependence σε
ένα πρόγραμμα, δεν είναι αναγκαστικό ότι αυτή θα οδηγήσει σε WAW hazard
(πάρτε για παράδειγμα το 5-stage pipeline όπου όλες οι εγγραφές γίνονται
in-order και σε ένα στάδιο, οπότε αποκλείεται να συμβεί WAW hazard).
Στο παράδειγμα που αναφέρεις τώρα... στον κύκλο 6, έχεις οutput
dependence μεταξύ L.D και ADD.D στον F6. Σε αυτή την περίπτωση, υπάρχει
μεταξύ τους η επιπλέον εξάρτηση δεδομένων (η ΑDD.D χρησιμοποιεί τον F6)
που οδηγεί τελικά την ADD.D να γράψει υποχρεωτικά στον F6 μετά την L.D.
Αν δεν είχες register renaming λοιπόν εδώ, όντως, δε θα είχες πρόβλημα.
Αν όμως δεν υπήρχε εξάρτηση δεδομένων μεταξύ τους και η ΑDD.D
χρησιμοποιούσε κάποιον άλλον input καταχωρητή, τότε σαφώς διατρέχεις
κίνδυνο aφού θα μπορούσε η ADD.D να γράψει πρώτη τον F6.
Τώρα, στο δεύτερο παράδειγμα στον κύκλο 6, δεν διατρέχεις κίνδυνο για
τις 2 MUL.D διότι η πρώτη αρχίζει πριν τη δεύτερη και έτσι δεν υπάρχει
περίπτωση η 2η να γράψει πρώτη τον F4. Και σε αυτήν την περίπτωση
δηλαδή, αν δεν είχες renaming θα σουν ΟΚ. Όμως για φαντάσου αν η 1η
MUL.D αργούσε να ξεκινήσει επειδή περίμενε input δεδομένα, ενώ την ίδια
στιγμή η 2η MUL.D τα είχε έτοιμα και άρα μπορούσε να αρχίσει πρώτη. Εκεί
θα είχες πρόβλημα.
Εκεί που θέλω να καταλήξω είναι ότι, αντί να κάθεται και να ψάχνει σε
κάθε κύκλο ο αλγόριθμος όλες τις διαφορετικές υποπεριπτώσεις για το πότε
θα είχες πραγματικό πρόβλημα και πότε όχι και να εφαρμόζει αντίστοιχα
renaming ή όχι (πράγμα με μεγάλο κόστος σε χρόνο, υλικό, κατανάλωση
ενέργειας), κάνει σε κάθε περίπτωση register renaming και "ξεμπερδεύει".
Γενικά, η διάκριση ανάμεσα στα dependences και τα hazards είναι λεπτή,
ειδικά για τις out-of-order αρχιτεκτονικές. Όμως σε κάθε περίπτωση δεν
θα πρέπει να κρίνετε τα hazards εκ του αποτελέσματος, ή με βάση
"παράπλευρες" ενέργειες που τελικά μπορεί να οδηγήσουν στην μη-εμφάνισή
τους. Με αυτό το σκεπτικό επομένως η περσινή άσκηση θεωρεί τα 2
dependences που αναφέρεις σαν hazards, άσχετα αν τελικά δε θα
δημιουργούσαν πρόβλημα.
Ελπίζω να μην μπέρδεψα περισσότερο :)
Ν.
ΑΛΕΞΑΝΔΡΟΣ ΚΟΝΤΑΡΙΝΗΣ wrote:
> Καλησπέρα,
>
> στην σελίδα 71 της αγγλικής 4ης έκδοσης γράφει:
> A hazard is created whenever there is a dependence between
> instructions, and they
> are close enough that the overlap during execution would change the
> order of access to
> the operand involved in the dependence.
>
> Στην άσκηση ζητούνται τα hazards που εμφανίζονται και πώς αυτά
> αντιμετωπίζονται.
> Στην περσινή λύση λοιπόν, μήπως τα 2 WAW hazards που αναγράφονται
> στους κύκλους
> 6 και 13, είναι στην πραγματικότητα απλώς output dependencies?
>
> (Οπότε, και το αντίστοιχο register renaming γίνεται όχι για αυτά, αλλά
> για το
> ενδεχόμενο να έρθει μία τρίτη εντολή, που θα έγραφε τον ίδιο
> καταχωρητή νωρίτερα μιας εκ των δύο - π.χ. η L.D που γίνεται issued
> στον κύκλο 14 - . Επειδή όμως, ο αλγόριθμος δεν
> μπορεί να ξέρει πάντα τι θα έρθει στο μέλλον κάνει rename κάθε
> destination register που
> υπάρχει στο πρόγραμμα.)
>
>
> Χρησιμοποιείτε Yahoo!
> Βαρεθήκατε τα ενοχλητικά μηνύ ματα (spam); Το Yahoo! Mail διαθέτει την
> καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων
> http://login.yahoo.com/config/mail?.intl=gr
> ------------------------------------------------------------------------
>
> _______________________________________________
> Advcomparch mailing list
> Advcomparch at lists.cslab.ece.ntua.gr
> http://lists.cslab.ece.ntua.gr/mailman/listinfo/advcomparch
>
More information about the Advcomparch
mailing list