Forum » Strojna oprema » Poravnava operandov v pomnilniku
Poravnava operandov v pomnilniku
marjan_h ::
Sprašujem čisto splošno, zakaj se morajo operandi poravnati v pomnilniku, kakšen smisel je vmes puščati prazne lokacije. In kako veš potem kam se shrani neki operand (na kateri naslov), če se ne sledi zapovrstjo.
milc ::
Razlogov je več, praktičnost, zmogljivost,...
Poglej si na kakem iskalniku, išči 'Data Alignment'.
Dostopanje do neporavnanih elementov strukture je bilo svoje čase lahko zelo potratno. Spomnem, se najbolj eksotičnega primera s katerim smo si belili glavo, kjer je bilo razmerje dostopanja do poravnanega elementa glede na neporavnan element 1:10000 (Digital Alpha), ki je generirala prekinitev, za vsak tak poskus...
Poglej si na kakem iskalniku, išči 'Data Alignment'.
Dostopanje do neporavnanih elementov strukture je bilo svoje čase lahko zelo potratno. Spomnem, se najbolj eksotičnega primera s katerim smo si belili glavo, kjer je bilo razmerje dostopanja do poravnanega elementa glede na neporavnan element 1:10000 (Digital Alpha), ki je generirala prekinitev, za vsak tak poskus...
Brane2 ::
Operandi so poravnani iz različnih, večinoma sorodnih vzrokov.
Eden je ta, da pobereš cel operand v "šusu". Memory controller dela z 64 bitnimi oziroma 128-bitnimi besedami. Če je operand razdeljen med dvema besedama, sta potrebna dva dostopa, kar se pozna predvsem pri pisanju.
Poravnava je lahko pomembna tudi pri strukturah, katerim lahko dostopa več CPUjev hkrati. Če sta dela preblizu skupaj, lahko končata hkrati v cachejih več CPUjev. Če nato en spremeni kaj v tem delu, je potrebna sinhronizacija cacheov več CPUjev.
Pa verjetno bi se našel še kak razlog...
Eden je ta, da pobereš cel operand v "šusu". Memory controller dela z 64 bitnimi oziroma 128-bitnimi besedami. Če je operand razdeljen med dvema besedama, sta potrebna dva dostopa, kar se pozna predvsem pri pisanju.
Poravnava je lahko pomembna tudi pri strukturah, katerim lahko dostopa več CPUjev hkrati. Če sta dela preblizu skupaj, lahko končata hkrati v cachejih več CPUjev. Če nato en spremeni kaj v tem delu, je potrebna sinhronizacija cacheov več CPUjev.
Pa verjetno bi se našel še kak razlog...
On the journey of life, I chose the psycho path.
Senitel ::
+če operandi niso poravnani, se ti lahko zgodi, da ga je en del v L1 cache-u, drugi del pa na disku v swap file-u. (hipotetično raztegnen primer pač 
)
) marjan_h ::
hmm, ok. Samo še nekaj, glede poravnanosti operandov; kakor razumem so 32 bitni (4 bajti) poravnani na naslov, ki je deljiv z 4, 16 bitni na naslov, ki je deljiv z 2, 8 bitni pa ne rabijo, ker 1 deli vsa števila.
In glede ukazov, če so 32 bitni so verjetno potem tud oni poravnani na naslove deljive s 4.
Hvala za odgovore.
In glede ukazov, če so 32 bitni so verjetno potem tud oni poravnani na naslove deljive s 4.
Hvala za odgovore.
SasoS ::
Ne, ukazi ponavadi niso poravnani, saj se izvršujejo zaporedno in poravnanost nima nekega posebnega vpliva na hitrost.
Brane2 ::
Poleg tega, da niso 32-bitni. Je*iga, dediščina "genijalnega" 8086 šitload 8-bitnih prefiksov in tako se ukaz lahko začne na kateremkoli byteu...
On the journey of life, I chose the psycho path.
marjan_h ::
@SasoS
si prepričan, da ukazi niso poravnani? Jaz sem prebral na netu, da morajo biti. Mogoče je pa samo napačen vir informacij. Je mogoče tudi odvisno od arhitekture procesorja?
si prepričan, da ukazi niso poravnani? Jaz sem prebral na netu, da morajo biti. Mogoče je pa samo napačen vir informacij. Je mogoče tudi odvisno od arhitekture procesorja?
Brane2 ::
Saj v splošnem niti ne morejo biti, ker niso vedno "okrogle" dolžine. Se pravi, ti lahko poravnaš prvega, ampak tisti za njim niso več nujno poravnani, kar pomeni, da nimaš praktično nobene koristi od tega...
On the journey of life, I chose the psycho path.
SasoS ::
Razen če bi imel vmes luknje, kar pa spet samo škodi.
Ja, je to precej odvisno od arhitekture. Imaš arhitekture, kjer so vsi ukazi 32-bitni (ampak res čisto vsi) in so potem jasno avtomatično tudi poravnani...
Ja, je to precej odvisno od arhitekture. Imaš arhitekture, kjer so vsi ukazi 32-bitni (ampak res čisto vsi) in so potem jasno avtomatično tudi poravnani...
Brane2 ::
Kako misliš "luknje"- v obliki NOP ukazov ali "mrtvih" prefixov ?
On the journey of life, I chose the psycho path.
SasoS ::
Choose your pick 
Itanium mislim da v VLIW pakete (ki morajo biti fiksne dolžine) vstavlja NOPe.
Itanium mislim da v VLIW pakete (ki morajo biti fiksne dolžine) vstavlja NOPe.
Brane2 ::
V obeh primerih pušiš.
Ne primerjaj VLIW z x86. Slednja lahko dekodira do 3 ukaze po taktu ( Phenom ), pa še tam so omejitve.
Če ti naštepaš tja NOPe, bo treba več taktov za dekodiranje zajetih instrukcij, ravno tako je s prefixi...
Na drugi strani pa ne dobiš praktično nič. Program se itak zajema večinoma sekvenčno, če pa skačeš v zanki, pa v 99,999% primerih skačeš na program, ki je v cacheu...
Ne primerjaj VLIW z x86. Slednja lahko dekodira do 3 ukaze po taktu ( Phenom ), pa še tam so omejitve.
Če ti naštepaš tja NOPe, bo treba več taktov za dekodiranje zajetih instrukcij, ravno tako je s prefixi...
Na drugi strani pa ne dobiš praktično nič. Program se itak zajema večinoma sekvenčno, če pa skačeš v zanki, pa v 99,999% primerih skačeš na program, ki je v cacheu...
On the journey of life, I chose the psycho path.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | 30 let x86 arhitekture (strani: 1 2 3 4 5 )Oddelek: Novice / Kiberpipa | 21745 (10202) | BigWhale |
| » | Nekaj splošnih vprašanj s področja HWOddelek: Strojna oprema | 1713 (1474) | P1P1 |
| » | Nekaj vprašanj s področja rač. arhitektureOddelek: Strojna oprema | 2324 (2137) | BaRtMaN |
| » | Zmeda z 64 bitnimi procesorjiOddelek: Strojna oprema | 2330 (1794) | Zheegec |
| » | Intel dosegel končno hitrost (strani: 1 2 )Oddelek: Novice / Procesorji | 5571 (5480) | slemo |