Manoli de ta diavasa ola ta sxolia sou... emeina stin prwti protasi, giati to eixa rwtisei: mou eipe na min lavoume ipopsin ta history bits sto overhead, afou einai mono 1-15 bits. arkoun na ipologisoume mono ta bits tou table. opote to history mporeis na to kaneis iso me ta bits pou tha valeis telika sto table!
2009/6/1 Manolis Papadakis manopapad2004@yahoo.gr:
- Στην υλοποίηση του gshare predictor υπάρχει ένα left shift του history
register πριν το XOR με το masked PC. Το left shift αυτό χρησιμεύει σε περίπτωση που τα bits του history register είναι λιγότερα από αυτά του table index. Επειδή για να πιάσουμε τα 32Kbits που είναι το επιθυμητό hardware overhead θα χρειαστεί να μειώσουμε τα bits του index, το history πλέον θα είναι μακρύτερο από το index, με αποτέλεσμα το left shift αυτό να έχει πλέον αρνητικό όρισμα (με history length = table index length = 15 όπως είναι αρχικά, το όρισμα προκύπτει μηδέν). Αυτό, όμως, σύμφωνα με το ANSI C πρότυπο (βλ. ελληνικό K&R σ. 282) δίνει UNDEFINED συμπεριφορά* (όπως θα γκρινιάξει και ο g++). Οπότε είτε θα πρέπει να μειωθεί και το history length για να γίνει <= του table index length είτε να αλλάξει ο κώδικας σε αυτό το σημείο και να παίρνει περιπτώσεις αναλόγως του ποιο είναι μακρύτερο. Τι προτείνετε εσείς?
- Η υλοποίηση του BTB που μας δίνεται χρησιμοποιεί πέραν των 2 unsigned
integers (PCs) ανά cell και έναν ακόμα integer, που χρησιμοποιείται για να πετύχουμε αντικατάσταση LRU σε κάθε update. Το overhead των LRU registers αυτών θα το αγνοήσουμε?
*Το οποίο σε αυτή την περίπτωση δεν είναι υπερβολή, καθώς ο παρακάτω κώδικας σε εμένα τυπώνει 0 αντί για το αναμενόμενο 1:
#include <stdio.h> int main () { unsigned int x = 2; printf("%u\n",x << (-1)); return 0; }
Advcomparch mailing list Advcomparch@lists.cslab.ece.ntua.gr http://lists.cslab.ece.ntua.gr/mailman/listinfo/advcomparch
Καλημέρα,
1. Για τον υπολογισμό του overhead στον gshare μπορείτε να αγνοήσετε τα bits του history.
2. Για τον υπολογισμό του overhead στον ΒΤΒ μπορείτε να αγνοήσετε τους registers του LRU.
K.
Manoli de ta diavasa ola ta sxolia sou... emeina stin prwti protasi, giati to eixa rwtisei: mou eipe na min lavoume ipopsin ta history bits sto overhead, afou einai mono 1-15 bits. arkoun na ipologisoume mono ta bits tou table. opote to history mporeis na to kaneis iso me ta bits pou tha valeis telika sto table!
2009/6/1 Manolis Papadakis manopapad2004@yahoo.gr:
- Στην υλοποίηση του gshare predictor υπάρχει ένα left shift του history
register πριν το XOR με το masked PC. Το left shift αυτό χρησιμεύει σε περίπτωση που τα bits του history register είναι λιγότερα από αυτά του table index. Επειδή για να πιάσουμε τα 32Kbits που είναι το επιθυμητό hardware overhead θα χρειαστεί να μειώσουμε τα bits του index, το history πλέον θα είναι μακρύτερο από το index, με αποτέλεσμα το left shift αυτό να έχει πλέον αρνητικό όρισμα (με history length = table index length = 15 όπως είναι αρχικά, το όρισμα προκύπτει μηδέν). Αυτό, όμως, σύμφωνα με το ANSI C πρότυπο (βλ. ελληνικό K&R σ. 282) δίνει UNDEFINED συμπεριφορά* (όπως θα γκρινιάξει και ο g++). Οπότε είτε θα πρέπει να μειωθεί και το history length για να γίνει <= του table index length είτε να αλλάξει ο κώδικας σε αυτό το σημείο και να παίρνει περιπτώσεις αναλόγως του ποιο είναι μακρύτερο. Τι προτείνετε εσείς?
- Η υλοποίηση του BTB που μας δίνεται χρησιμοποιεί πέραν των 2 unsigned
integers (PCs) ανά cell και έναν ακόμα integer, που χρησιμοποιείται για να πετύχουμε αντικατάσταση LRU σε κάθε update. Το overhead των LRU registers αυτών θα το αγνοήσουμε?
*Το οποίο σε αυτή την περίπτωση δεν είναι υπερβολή, καθώς ο παρακάτω κώδικας σε εμένα τυπώνει 0 αντί για το αναμενόμενο 1:
#include <stdio.h> int main () { unsigned int x = 2; printf("%u\n",x << (-1)); return 0; }
Advcomparch mailing list Advcomparch@lists.cslab.ece.ntua.gr http://lists.cslab.ece.ntua.gr/mailman/listinfo/advcomparch
advcomparch@lists.cslab.ece.ntua.gr