Burgent
May 22, 2013, 03:58:30 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Als je dit leest, zit je op het nieuwe forum. Proficiat smiley Als er iets niet werkt, just let it know.
 
   Home   Help Search Calendar Login Register  
Pages: 1 2 [3] 4 5
  Print  
Author Topic: examen vrijdag 3 februari 2006  (Read 6297 times)
deMax
nerd
**
Posts: 64


« Reply #30 on: January 19, 2008, 08:09:46 pm »

Vraag 1
Dit vind ik toch een beetje verwarrend.
Wil iemand eens kijken naar slide 45 van hoofdstuk 8?
Daar staat voor zowel de O-toestand als de M-toestand: in het kolommetje BW "geef data". Geef data aan wie? Niemand heeft da toch nodig als er een BW gebeurt die andere data zal schrijven?

een BW wordt gedaan vanuit een Local Write in toestand I. Dus moet ie eerst de data krijgen vooraleer ie kan schrijven. Dat is het antwoord op "Geef data aan wie"

Waarom heeft die da nodig? Je kan toch gewoon direct schrijven naar de cachelijn en de toestand op 'M' zetten en al de rest invalideren?
Logged
Meerske
n00b
*
Posts: 41


« Reply #31 on: January 19, 2008, 08:19:35 pm »

Vraag 1
Dit vind ik toch een beetje verwarrend.
Wil iemand eens kijken naar slide 45 van hoofdstuk 8?
Daar staat voor zowel de O-toestand als de M-toestand: in het kolommetje BW "geef data". Geef data aan wie? Niemand heeft da toch nodig als er een BW gebeurt die andere data zal schrijven?

een BW wordt gedaan vanuit een Local Write in toestand I. Dus moet ie eerst de data krijgen vooraleer ie kan schrijven. Dat is het antwoord op "Geef data aan wie"

Waarom heeft die da nodig? Je kan toch gewoon direct schrijven naar de cachelijn en de toestand op 'M' zetten en al de rest invalideren?

good point...

btw mijn vraag over slide 44 en oefening pagina 42 is al opgelost doordat de cachelijn niet vervangen wordt ('tis ne store en gene load in de oefening...)
Logged
Brahiiim
n00b
*
Posts: 42


« Reply #32 on: January 19, 2008, 08:20:31 pm »

hmm.. tis al even terug.(aleez ja een dag of twee)..als een cpu wil schrijven naar een cacheblok die hij niet heeft dan moet hij die toch gaan halen van het geheugen normaal, da laat hij zien door een BW signaal op de bus te zetten.. als een andere CPU da blok heeft sturen ze door naar diene eerste cpu. anders geeft het geheugen het cacheblok door..

dus een CPU kan ni zomaar naar een cacheblok beginnen schrijvenh die zich in zijn cache bevindt: het moet allemaal consistent blijven. als een andere CPU diene cacheblok vraagt moet ge da kunnen doorgeven..dus moet ge altijd een up to date cacheblok hebben waar ge naar moet schrijven..
goh ik denk dat t zo is, maar beter kan ik t ni uitleggen, ben daar ni goed in uitleggen..mechatronica fucked me up...wink
Logged
Meerske
n00b
*
Posts: 41


« Reply #33 on: January 19, 2008, 08:34:16 pm »

hmm.. tis al even terug.(aleez ja een dag of twee)..als een cpu wil schrijven naar een cacheblok die hij niet heeft dan moet hij die toch gaan halen van het geheugen normaal, da laat hij zien door een BW signaal op de bus te zetten.. als een andere CPU da blok heeft sturen ze door naar diene eerste cpu. anders geeft het geheugen het cacheblok door..

dus een CPU kan ni zomaar naar een cacheblok beginnen schrijvenh die zich in zijn cache bevindt: het moet allemaal consistent blijven. als een andere CPU diene cacheblok vraagt moet ge da kunnen doorgeven..dus moet ge altijd een up to date cacheblok hebben waar ge naar moet schrijven..
goh ik denk dat t zo is, maar beter kan ik t ni uitleggen, ben daar ni goed in uitleggen..mechatronica fucked me up...wink

neem het voorbeeld van CPU1 in toestand I en CPU2 in toestand E of S. Als CPU1 nu wilt gaan schrijven doet ie een BW en zet zijn toestand op M. Maar CPU2 ontvangt de BW en zet zijn toestand gewoon op I (levert dus geen data). Dit voorbeeld weerlegt uw uitleg...
Logged
Brahiiim
n00b
*
Posts: 42


« Reply #34 on: January 19, 2008, 10:26:31 pm »

jep, daar heb je een punt...
Het lijkt me logisch dat een CPU die het cacheblok bezit, dit doorgeeft aan diene andere CPU? ipv dat die dat van het geheugen moet gaan halen. het cachecoherentieprotocol geeft toch aan dat ze consistent zijn. "geef data" in het toestandsmodel slaat dan op het feit dat je meegeeft welke zaken veranderd zijn geweest... in principe zou dit al in het cacheblok moeten zitten, aangezien ik er van uit ga dat die dirty bits worden meegestuurd, ma goed, das ni echt helemaal zuiver op de graat vind ik zelf ook, maar tis de beste verklaring die ik uit mijn mouw kan schudden...
Logged
deMax
nerd
**
Posts: 64


« Reply #35 on: January 20, 2008, 01:44:14 pm »

Ik snap het!
Quote from: Stijn Eyerman
Dag Maximilien,
> We vroegen ons af waarom cache-lijnen in 'O'/'M' toestand hun data moeten geven als er een BW gebeurt. Niemand heeft daar toch iets aan gezien een BW toch andere data zal schrijven...
> (De discussie is terug te vinden op http://burgent.be/index.php?topic=164.30, blad2 en (vooral) blad3).
>
Dat komt omdat een cachelijn uit meerdere bytes bestaat (bv. 16), en dat er voor een schrijfoperatie typisch maar een deel van de cachelijn beschreven wordt (bv. 4 bytes). Als de nieuwe schrijver nu een ander deel van de cachelijn wil schrijven, dan dat de processor die de cachelijn in M/O toestand gebracht veranderd heeft, dan moet eerst de volledige cachelijn, met de gewijzigde data, doorgegeven worden, vooraleer er nieuwe data kan geschreven worden.
Logged
Meerske
n00b
*
Posts: 41


« Reply #36 on: January 20, 2008, 01:57:43 pm »

Ik snap het!
Quote from: Stijn Eyerman
Dag Maximilien,
> We vroegen ons af waarom cache-lijnen in 'O'/'M' toestand hun data moeten geven als er een BW gebeurt. Niemand heeft daar toch iets aan gezien een BW toch andere data zal schrijven...
> (De discussie is terug te vinden op http://burgent.be/index.php?topic=164.30, blad2 en (vooral) blad3).
>
Dat komt omdat een cachelijn uit meerdere bytes bestaat (bv. 16), en dat er voor een schrijfoperatie typisch maar een deel van de cachelijn beschreven wordt (bv. 4 bytes). Als de nieuwe schrijver nu een ander deel van de cachelijn wil schrijven, dan dat de processor die de cachelijn in M/O toestand gebracht veranderd heeft, dan moet eerst de volledige cachelijn, met de gewijzigde data, doorgegeven worden, vooraleer er nieuwe data kan geschreven worden.


jezus, zo simpel en wij konden er niet opkomen...
Logged
Meerske
n00b
*
Posts: 41


« Reply #37 on: January 20, 2008, 03:03:11 pm »

Yow,
Ja die load, daar was iedereen vorig jaar ook over bezig. In de opgave staat "...opdat instructies die afhankelijk zijn van elkaar via echte data-afhankelijkheden in opeenvolgende cycli uitgevoerd kunnen worden (ook indien de producent van een registerwaarde een leesoperatie is die een cache miss blijkt te zijn)".
Dus vanaf de data beschikbaar is kan de afhankelijke instructie de FU betreden. Hoe ik mijn oefening heb uitgewerkt blijkt dat de mul en de L2-load tegelijk uitgevoerd worden zodat alle operandi beschikbaar zijn voor dienen add.
De load moet zeker niet in de executie-trap blijven wachten (het is een niet-blokerende L1-$ !), hij moet alleszins in mshr komen.
Heb een beetje vragen over dit examen Smiley

Vraag 5: wat moet er juist gebeuren met de L1 cache miss?   Moet de instructie dan in de executietrap blijven wachten of terug naar het reservatiestation gaan (cfr cursus 3-78), en zoja, wanneer mag die dan juist naar de wakeup?  Anyway, ik kom enkekle cycli te kort vo rond te gerake met die instructies.

cheers


als ik het goed heb, wordt de load-instructie terug in de wake-up geplaatst in cylcus 6. De mul bevindt zich dan in de eerste EX-trap... De andere 2 adds zitten dan nog in het reservatiestation...

in cyclus 9 heb je dan de load "ld R3(A),F1" in de MEM2-trap n de "add F4,F1,F5" in de EX-trap n "mul F3,F2,F4" in de EX4-trap. Wat me wel een beetje moeilijk lijkt, maar door die opmerking in de opgave (en ook door deMax aangehaald) denk ik dat dat de enigste mogelijkheid is...

iemand iets anders?
Logged
bulbanos
nerd
**
Posts: 87


« Reply #38 on: January 20, 2008, 04:40:04 pm »

kan er me iemand zeggen of mijn register hernoeming in orde is bij vraag 5? (zelfs daar val ik soms over)

ld r3(A),f1
add r2,r3,f2
sub f2,r3,f3
mul f3,f2,f4
add f4,f1,f5
add f5,f2,f6

waardoor dus elke instructie RAW afhankelijk is van de vorige (vanaf instr 2)

Edit: hoe komt het dat je zegt dat de ADD die afhankelijk is van de MUL via F4 op hetzelfde moment in zijn EX zit als die MUL? In de oefeningen werd die altijd een stapje later gestart.
« Last Edit: January 20, 2008, 05:01:25 pm by bulbanos » Logged
Brahiiim
n00b
*
Posts: 42


« Reply #39 on: January 20, 2008, 04:52:20 pm »

Ik snap het!
Quote from: Stijn Eyerman
Dag Maximilien,
> We vroegen ons af waarom cache-lijnen in 'O'/'M' toestand hun data moeten geven als er een BW gebeurt. Niemand heeft daar toch iets aan gezien een BW toch andere data zal schrijven...
> (De discussie is terug te vinden op http://burgent.be/index.php?topic=164.30, blad2 en (vooral) blad3).
>
Dat komt omdat een cachelijn uit meerdere bytes bestaat (bv. 16), en dat er voor een schrijfoperatie typisch maar een deel van de cachelijn beschreven wordt (bv. 4 bytes). Als de nieuwe schrijver nu een ander deel van de cachelijn wil schrijven, dan dat de processor die de cachelijn in M/O toestand gebracht veranderd heeft, dan moet eerst de volledige cachelijn, met de gewijzigde data, doorgegeven worden, vooraleer er nieuwe data kan geschreven worden.

ik snap het precies niet. wat is het verschil met wat ik zei?? impliceert het antwoord van stijn nu dat bij S en E er werkelijk niets wordt doorgestuurd?? en vooral: wat als de nieuwe cpu dezelfde data wil schrijven??
Logged
Ward
nerd
**
Posts: 52


« Reply #40 on: January 20, 2008, 05:17:27 pm »

Het is eigenlijk eenvoudig ze:

Wanneer een CPUx een waarde wil lezen die hij nog niet heeft, krijgt hij dat hele cacheblok waarin die waarde zit doorgestuurd. (hetzij uit het geheugen, hetzij van een andere processor CPUy in de E, S of M toestand)

Wanneer een CPUx een waarde wil aanpassen die hij nog niet heeft, moet hij ook eerst het hele cacheblok waarin de oude waarde zit, doorgestuurd krijgen (hetzij uit het geheugen, hetzij van een andere processor CPUy in de E, S of M toestand)
Pas dan kan hij de gewenste waarde aanpassen.
De reden waarom eerst dat cacheblok moet worden doorgestuurd, is dus dat dat blok (in het algemene geval) ook waarden bevat die CPUx niet aanpast (maar wel moet kennen)
Logged
Brahiiim
n00b
*
Posts: 42


« Reply #41 on: January 20, 2008, 05:28:58 pm »

ok. das dan al duidelijk. ik ga nog enkele ja of nee vragen stellen gewoon ter bevestiging. das gewoon superbelangrijk voor t examen, vandaar da ik zo anaal doe

1)bij de toestandsmodel van MOESI staat er bij een BW bij S en E gewoon s'=I. maar daar wordt ook een cacheblok doorgegeven. het enige verschil met de toestanden M en O is dat er nog niet naar geschreven is.

2)het maakt niet uit of een CPUx wil schrijven naar een deel van de cachelijn die al beschreven is geweest door een andere CPUy in M of O toestand.wat ik precies bedoel: CPUx doet BW en krijgt volledig cacheblok(met veranderingen aangebracht door CPUy). als die besluit om daar een deel van over te schrijven is dat geen probleem: geen enkel andere CPU heeft proberen te lezen van dat cacheblok van CPUy, want anders zou CPUy niet in de toestand M of O gezeten hebben.

ciaociao
Logged
bulbanos
nerd
**
Posts: 87


« Reply #42 on: January 20, 2008, 06:06:16 pm »

Kan er me iemand vertellen wat er in vraag 6 bedoeld wordt met issue? Wat moet van waar naar waar in die cyclus?
Ik heb al zitten kijken in het waslijstje topic naar die pdf en ik kan maar niet begrijpen wat zij daar doen. Thx!
Logged
rob
n00b
*
Posts: 46


« Reply #43 on: January 20, 2008, 06:21:04 pm »

ok. das dan al duidelijk. ik ga nog enkele ja of nee vragen stellen gewoon ter bevestiging. das gewoon superbelangrijk voor t examen, vandaar da ik zo anaal doe

1)bij de toestandsmodel van MOESI staat er bij een BW bij S en E gewoon s'=I. maar daar wordt ook een cacheblok doorgegeven. het enige verschil met de toestanden M en O is dat er nog niet naar geschreven is.

2)het maakt niet uit of een CPUx wil schrijven naar een deel van de cachelijn die al beschreven is geweest door een andere CPUy in M of O toestand.wat ik precies bedoel: CPUx doet BW en krijgt volledig cacheblok(met veranderingen aangebracht door CPUy). als die besluit om daar een deel van over te schrijven is dat geen probleem: geen enkel andere CPU heeft proberen te lezen van dat cacheblok van CPUy, want anders zou CPUy niet in de toestand M of O gezeten hebben.
1) Enige verschil tussen M-E is inderdaad dat er al naar M geschreven is, en naar E nog niet. Ja dus.
Bij O-S veronderstel ik ook ja, maar toch wat  meer uitleg. Als er alleen maar S'en van een bepaalde cachelijn zijn, is er nog nooit naar geschreven. Als er echter verschillende cachelijnen (bijv. A) in S-toestand zijn, en op een processor is A ook in O-toestand, dan zijn alle waarden dirty. Alle cachelijnen zijn dus consistent met elkaar, maar niet met het geheugen. Dus inderdaad heeft een processor met een S-toestand van A nog niet naar A geschreven, maar hij heeft wel de door O beschreven waarde van A, en niet de originele (uit het geheugen)! Hoop dat dit wat duidelijker is
2) Begrijp niet helemaal wat je bedoelt. De zin " geen enkel andere CPU heeft proberen te lezen van dat cacheblok van CPUy, want anders zou CPUy niet in de toestand M of O gezeten hebben. " klopt in ieder geval niet. Het is net als een CPU leest van een CPUy in toestand M, dat CPUy toestand O krijgt.
Logged
CL
n00b
*
Posts: 8


« Reply #44 on: January 20, 2008, 06:29:13 pm »

Kan er me iemand vertellen wat er in vraag 6 bedoeld wordt met issue? Wat moet van waar naar waar in die cyclus?
Ik heb al zitten kijken in het waslijstje topic naar die pdf en ik kan maar niet begrijpen wat zij daar doen. Thx!

dan moet de instructie van het RS naar de EA
Logged
Pages: 1 2 [3] 4 5
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.12 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!