[Advcomparch] Απορία για την εκτέλεση των SD

Konstantinos Nikas knikas at cslab.ece.ntua.gr
Sun May 26 21:59:29 EEST 2013


Καλησπέρα,

καταρχάς όσον αφορά τη σημερινή άσκηση δεν υπάρχει θέμα και δε χρειάζεται
να την αλλάξεις.

Από εκεί και πέρα όσον αφορά το μοντέλο που προτείνουμε για την άσκηση, θα
μπορούσαμε να πούμε ότι οι εντολές γίνονται κανονικά issue όπως έχω ήδη
περιγράψει και σε περίπτωση εμφάνισης RAW υπάρχει μηχανισμός, ο οποίος
αναλαμβάνει να κάνει flush. Αν δηλαδή ανακαλύψουμε ότι ένα μεταγενέστερο LD
είχε τελικά την ίδια διεύθυνση με κάποιο προηγούμενο SD, τότε ο μηχανισμός
αναλαμβάνει να βεβαιωθεί ότι το LD έχει πάρει τη σωστή τιμή. Καθώς όμως
στον κώδικα δεν υπάρχουν τέτοια RAW, ο μηχανισμός αυτός δε χρησιμοποιείται
πουθενά.

Ξαναλέω ότι όλα αυτά είναι προσεγγίσεις και επομένως όχι υποχρεωτικά
ρεαλιστικές λύσεις :-). Γενικότερα, τα προηγούμενα χρόνια δεν υπήρχαν
ενστάσεις όσον αφορά το μοντέλο που χρησιμοποιούμε. Οι απορίες/παρατηρήσεις
σου είναι πολύ λογικές και θα ξανασκεφτούμε από την αρχή το μοντέλο που
προτείνουμε. Παρόλα αυτά, (για φέτος τουλάχιστον) θα πρότεινα να
ακολουθήσετε το μοντέλο μας τόσο στις υπόλοιπες ασκήσεις όσο και στις
εξετάσεις.

Κ.


2013/5/26 Nick Korasidis <el08047 at mail.ntua.gr>

>  Καλησπέρα,
>
> Ευχαριστώ για την απάντηση. Καταλαβαίνω την ανάγκη για απλοποιήσεις, όμως
> μου φαίνεται όμως ότι υπάρχουν μερικές ασυνέπειες στο μοντέλο που
> προτείνετε: Προκειμένου το LD να ξέρει ότι δε βρίσκεται σε RAW dependency
> με ένα προηγηθέν SD, πρέπει να έχει υπολογιστεί τόσο η δική του διεύθυνση
> όσο και αυτή του SD. Επειδή οι διευθύνσεις υπολογίζονται στο ΕΧ, για να
> γίνει ο έλεγχος αυτός πρέπει *και οι δύο* εντολές να έχουν ξεκινήσει το
> στάδιο EX. Όμως ο έλεγχος *προηγείται* του σταδίου EX του LD στον αλγόριθμο
> Tomasulo (εκτός αν διαβάζω τις διαφάνειες λανθασμένα). Ο μόνος τρόπος να
> λυθεί ο φαύλος κύκλος είναι το LD να περιμένει να ολοκληρωθεί το EX του SD.
> Προσωπικά, αυτή την παραδοχή έχω κάνει και δεν προλαβαίνω να την αλλάξω. Θα
> με ενδιέφερε πάντως να μάθω αν υπάρχει καλύτερη λύση στο πρόβλημα αυτό
> χωρίς το LD να αναγκάζεται να "μαντεύει" με οποιονδήποτε τρόπο ότι στη 2η
> άσκηση της advcomparch δεν εμφανίζονται RAW dependencies.
>
> Και πάλι ευχαριστώ για τις διευκρινήσεις.
>
> Νικόλας Κορασίδης
>
> On 26/05/2013 08:52 μμ, Konstantinos Nikas wrote:
>
> Καλησπέρα,
>
>  έχεις δίκιο για την παρατήρηση που κάνεις. Όπως είπα όμως και την
> προηγούμενη φορά, στις ασκήσεις κάνουμε κάποιες παραδοχές όσον αφορά τα
> Stores καθαρά για λόγους απλότητας και ευκολίας. Αποτελούν μια προσέγγιση
> και όχι την ακριβή πραγματικότητα για το πως γίνονται τα SD.
>
>  Στις ασκήσεις μας λοιπόν τα Stores μπαίνουν στη φάση του EX όταν όλα τα
> ορίσματα τους είναι διαθέσιμα. Επίσης φροντίζουμε να μην υπάρχουν RAW
> κίνδυνοι μεταξύ των stores και των επόμενων loads (οπότε και δεν
> καθυστερούμε τα LDs).
>
>  Όσον αφορά την τελευταία παρατήρηση, προφανώς η απαίτηση το block να μην
> έχει γίνει evict προκύπτει από τις παραδοχές που κάνουμε (και δεν είναι
> πραγματική). Παρ'όλα αυτά, δεδομένου του μεγέθους και του associativity της
> cache, του μικρού αριθμού προσβάσεων στη μνήμη που μπορεί να μεσολαβήσουν
> μεταξύ του EX και του CMT (λόγω του μικρού μεγέθους των Load/Store queues)
> καθώς και των ιδιοτήτων της πολιτικής LRU, μπορούμε με πολύ μεγάλη
> πιθανότητα να πούμε ότι το block θα είναι ακόμα εκεί. Παρ'ολα αυτά δεν μας
> ενδιαφέρει ιδιαίτερα, καθώς όπως εξήγησα όλα αυτά είναι μια παραδοχή που
> κάνουμε για τις ασκήσεις.
>
>  Κ.
>
>
>  Έχω τρεις απορίες σχετικές με την εκτέλεση των load/store εντολών:
>>
>> 1) Επιτρέπεται σε εντολή SD να μπει στο στάδιο EX ακόμα κι αν δεν έχει
>> διαθέσιμη την τιμή που θα γράψει;
>>
>> 2) Αν το παραπάνω δεν επιτρέπεται, προκύπτει το εξής πρόβλημα: Σύμφωνα με
>> τη διαφάνεια 26 του σετ "Lec6-speculation-13.pdf", τα LD γίνονται stall
>> μέχρι τα SD που προηγούνται να υπολογίσουν τη διεύθυνσή τους. Σύμφωνα με
>> την εκφώνηση της άσκησης, ο υπολογισμός της διεύθυνσης μιας εντολής LD/SD
>> γίνεται στο στάδιο EX. Επομένως, στην άσκηση τα LD πρέπει να γίνονται stall
>> μέχρι τα προηγούμενα SD να έχουν διαθέσιμα όλα τα ορίσματά, τόσο της
>> διεύθυνσης όσο και της εγγραφόμενης τιμής. Λόγω της μεγάλης καθυστέρησης
>> της DIVD, αυτή η παραδοχή δημιουργεί μεγάλη απόκλιση στον αλγόριθμο. Είναι
>> σωστή;
>>
>> 3) Θεωρούμε ότι η cache είναι write-allocate. Από όσα προηγήθηκαν στη
>> λίστα καταλαβαίνω ότι μια εντολή SD που θέλει να γράψει στη μνήμη φέρνει
>> στην cache τα απαραίτητα block στο στάδιο EX και γράφει σε αυτή στο στάδιο
>> CMT. Πώς ξέρουμε ότι στο διάστημα που μεσολαβεί από το EX έως το CMT το
>> block που θέλουμε είναι ακόμη στην cache και δεν έχει γίνει evict?
>>
>> Ευχαριστώ.
>>
>> Νικόλας Κορασίδης
>> _______________________________________________
>> Advcomparch mailing list
>> Advcomparch at lists.cslab.ece.ntua.gr
>> http://lists.cslab.ece.ntua.gr/mailman/listinfo/advcomparch
>>
>
>
>
>  --
> Dr. Konstantinos Nikas
> Computing Systems Laboratory
> School of Electrical and Computer Engineering
> National Technical University of Athens
>
> Tel: +30-210-7724159
> e-mail: knikas at cslab.ece.ntua.gr
> http://www.cslab.ece.ntua.gr/~knikas
>
>
>
> _______________________________________________
> Advcomparch mailing list
> Advcomparch at lists.cslab.ece.ntua.gr
> http://lists.cslab.ece.ntua.gr/mailman/listinfo/advcomparch
>
>


-- 
Dr. Konstantinos Nikas
Computing Systems Laboratory
School of Electrical and Computer Engineering
National Technical University of Athens

Tel: +30-210-7724159
e-mail: knikas at cslab.ece.ntua.gr
http://www.cslab.ece.ntua.gr/~knikas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cslab.ece.ntua.gr/pipermail/advcomparch/attachments/20130526/2da73ab5/attachment-0001.htm>


More information about the Advcomparch mailing list