...

Ήθελα να ρωτήσω αν υπάρχει forwarding μεταξύ των εντολών που εκτελούνται στην ίδια μονάδα. Για παράδειγμα: DSGTUI R3, R1, #800 BEQZ R3, foo Μπορεί το αποτέλεσμα της DSGTUI να διοχετευτεί στην επόμενη εντολή αμέσως μετά το στάδιο execute ή πρέπει να περιμένει και το στάδιο WB??

Aν υποθέσουμε ότι στον κύκλο k ολοκληρώνεται η εκτέλεση της DSGTUI, τότε η εγγραφή στο CDB της τιμής του R3 θα γίνει στον κύκλο k+1, οπότε η εγγραφή της τιμής αυτής στο αντίστοιχο πεδίο Vj του res. station όπου βρίσκεται η BEQZ (το οποίο είναι στην ουσία κάποιο είδος forwarding) θα γίνει και αυτή στον κύκλο k+1 (το CDB μεταφέρει μια τιμή στους προορισμούς που την χρειάζονται ταυτόχρονα). H εκτέλεση επομένως της BEQZ (η αντίστροφη μέτρηση στην ουσία των κύκλων που διαρκεί) θα αρχίσει από τον κύκλο k+2.

N.

---

Advcomparch mailing list Advcomparch@lists.cslab.ece.ntua.gr http://lists.cslab.ece.ntua.gr/mailman/listinfo/advcomparch

Αν έχουμε εκτέλεση μιας εντολής μονάδας ακεραίων στον κύκλο K τότε γίνεται ή όχι να έχουμε στον ιδιο κύκλο Load/Store ή εντολή στην FPU με διαφορετικά ορίσματα ?

Εννοώ, να έχουμε στην αλλαγή του loop απο το 1ο στο 2ο, ταυτόχρονη χρησιμοποίηση του EX στον ίδιο κύκλο απο τη τελευταία εντολή του 1ου loop και την πρώτη εντολή του 2oυ loop.

Αν αντιλαμβάνομαι σωστά στην περίπτωση μας κάτι τέτοιο δεν γίνεται οπότε θέλουμε stall και τώρα που το σκέφτομαι θα θέλαμε ο επεξεργαστής να υποστηρίζει SMT για κάτι τέτοιο.

Αν έχουμε εκτέλεση μιας εντολής μονάδας ακεραίων στον κύκλο K τότε γίνεται ή όχι να έχουμε στον ιδιο κύκλο Load/Store ή εντολή στην FPU με διαφορετικά ορίσματα ? Εννοώ, να έχουμε στην αλλαγή του loop απο το 1ο στο 2ο, ταυτόχρονη χρησιμοποίηση του EX στον ίδιο κύκλο απο τη τελευταία εντολή του 1ου loop και την πρώτη εντολή του 2oυ loop.

Στις αρχιτεκτονικές που υποστηρίζουν δυναμική εκτέλεση εντολών (π.χ. με Tomasulo) δεν έχεις πρόβλημα αν 2 εντολές βρίσκονται ταυτόχρονα στο ΕΧ, αρκεί φυσικά να μην χρησιμοποιούν την ίδια δομική μονάδα, οπότε θα είχες structural hazard.

Όταν έχουμε stall το εννούμε με την έννοια που το είχαμε δει στο pipeline στην Αρχιτεκτονική Υπολογιστών του 5ου εξαμήνου, δηλ. όταν έχουμε stall, καθυστερεί (stallarei) κάποιο απο τα στάδια του pipeline στις επόμενες εντολές ; Δηλαδή π.χ. αν σε μία εντολή έχω stall στον cycle 5 στο στάδιο IS αυτό σημαίνει οτι στην αμέσως επόμενη εντολή op2 δεν θα μπορώ στον cycle 5 να κάνω IF ή ID ;

Το αν καθυστερούν ή όχι οι επόμενες εντολές εξαρτάται πού γίνεται το stall. Αν γίνει στο "in-order" μέρος του pipeline, όπως γίνεται στο IS στο παράδειγμα που αναφέρεις, τότε οι επόμενες εντολές θα stall-άρουν επειδή το issue των εντολών γίνεται in-order (και διότι επιπλέον έχεις single-issue επεξεργαστή οπότε δεν μπορείς να κάνεις >1 εντολές issue στον ίδιο κύκλο). Αν γίνει στο "out-of-order" μέρος του pipeline, όπου οι εντολές έχουν κατανεμηθεί σε διαφορετικά res. stations, τότε το stall-άρισμα κάποιας εντολής i δε θα επηρεάσει όλη την ακολουθία εντολών που έπονται στη σειρά προγράμματος, αλλά κατά βάση τις εξαρτώμενες από την i εντολές.

Όταν λέτε ότι στο CDB μπορεί να γράφει το αποτέλεσμα της κάθε φορά

μόνο μια

εντολή εννοείτε μόνο για το στάδιο Write Result (WB); Δηλαδή αν στον ίδιο κύκλο μια εντολή Β γίνεται issue και μια εντολή Α

είναι

στο WB και πρέπει και οι δυο να γράψουν στο CDB θα stall-άρει η Β;

Στο CDB γράφουν οι εντολές μόνο κατά το στάδιο WB. Θα έχεις stall λόγω conflict στο CDB, αν για παράδειγμα τύχει οι Α και Β να ολοκληρώσουν την εκτέλεσή τους στον ίδιο κύκλο, οπότε στον επόμενο κύκλο θα πρέπει να γράψουν το αποτέλεσμά τους στο CDB. Εκεί κάνεις τη σύμβαση ότι π.χ. η μεταγενέστερη σε σειρά προγράμματος θα πρέπει να stall-άρει μέχρι να γίνει διαθέσιμο το CDB στον επόμενο κύκλο.

N.