nog ns @ Meerske: ik denk toch dat die load de pijplijn terug moet uitlopen van wakeup tot ex. mn redenering, waar ik troues absoluut ni zeker van ben.feedback is welkom!
slide 78 hoofdstuk 3. echt onduidelijke slide man man. heeft er iemand toevallig notities bij genomen of weet hoe het echt zit.
ik veronderstel dat het de load is die in het RS blijft zitten, waarvan de busybit op 1 blijft staan. nu,na 4 cycli komt de data beschikbaar in de L1 cache(latentie tijd is van L1 tov L2 veronderstel ik). wat gebeurt er die 5e cyclus. meest logische: diene load leest de data van de L1 cache. maar die load kan er ni zomaar verschijnen denk ik???
"wel instructie later opstarten":
1e optie) hier doelt hij ook op die load instructie? bedoelt hij dat die load alle stappen van de pijplijn vanaf wake-up en selectie terug moet doorlopen?? ik denk het eigenlijk wel. CPU moet dat exact berekenen ahv latentie, wanneer die load operatie moet heropgestart(lees: gewake-upd) worden.
2e optie)
2e optie is dat de data aan de L1-cache sowieso verschijnt, zonder een load operatie en dat de CPU dus de eerste afhankelijke operatie zo moet schedulen dat die er tegen dan net geraakt. da lijkt me minder wss dat er info uit de cache kan komen zonder een load te moeten doen..
feedback is meeeer als welkom, das echt massas belangrijk denk ik
in het hoofdstuk van prestatie-analyse doet de prof dat ook, namelijk wachten tot de data van de cache beschikbaar is en dan onmiddellijk forwarden naar de EX-trap van een afhankelijke instructie. Dit mag alleen bij niet-blokkerende caches want dan heb je een extra buffer (naam vergeten) die loads - die een cachemiss veroorzaken - aan de kant zet... (ze verdwijnen dus NIET zomaar...)
bij blokkerende caches moet de instructie helemaal herstart worden...
Als er iets niet werkt, just let it know.
