Autor: Radoslaw Sokol (rsokol_at_magsoft.com.pl)
Data: Fri 28 Nov 2003 - 11:09:01 MET
Hi,
MiW wrote:
>
> Nie. Najnizsze 5 bitow wykrywa uklad cache'ujacy (jakbym gdzies znalazl moje
> materialy to bym dokladnie powiedzial jak to sie nazywa ;-) ) i sprawdza,
> czy 'przypadkiem' nie ma takiego czegos u siebie.
Czegoś tu troszkę nie rozumiem... Jeśli linia ma rozmiar
2^n bajtów, to najniższych n bitów pełnego adresu fizycznego
IMHO powinno określać dokładnie przyległe bajty wewnątrz
jednej i tylko jednej linii cache (oczywiście z punktu
widzenia kontrolera cache).
> > Najniższa
> > część to offset wewnątrz linii cache (np. pięć bitów). Środkowa
> > to sztywny adres linii w ramach bloku, zaś najwyższa to adres
> > bloku, przy czym każda linia ma zapisaną przy sobie najwyższą
> > część adresu jako tag i dzięki temu jeden blok cache może
> > odwzorowywać linie pochodzące z bardzo rozległego obszaru pamięci,
> > a nie tylko z przyległego do siebie bloku np. 64 KiB.
>
> [...]
> Bo jest !
Aby uniknąć niejasności: "Bo jest !" odnosi się do fragmentu,
który zacytowałem zaraz powyżej?
Teraz już dla zupełnego wyjaśnienia tej kwestii mały przyk-
ład oparty o Twój wykład. Spróbuj proszę prześledzić go i
sprawdzić, czy dobrze to wszystko rozumiem:
Na potrzeby przykładu załóżmy następujące warunki:
- procesor 8-bitowy z 8-bitową szyną adresową
- zewnętrzny kontroler cache
- linia cache o rozmiarze 8 B (3 bity adresu)
- 16 linii cache (4 bity adresu), łączny rozmiar 128 B (*)
- jedna ścieżka asocjacji (direct mapped)
1. Procesor odwołuje się do komórki pamięci o adresie
0 0001 000
2. Kontroler cache stwierdza, że linia 0001 jest nieważna
i wczytuje jej zawartość z RAM (spod adresów 0 0001 xxx),
zapamiętując z nią tag 0. Zwraca bajt 000 tej linii.
3. Procesor odwołuje się do komórki pamięci o adresie
0 0001 001
4. Kontroler cache stwierdza, że linia 0001 jest ważna,
ma tag 0 jak powyższy adres, i zwraca bajt spod adresu 001.
5. Procesor odwołuje się do komórki pamięci o adresie
1 0001 010
6. Kontroler cache stwierdza, że linia 0001 jest ważna,
ale ma tag 0 a nie 1, więc usuwa jej zawartość i
wczytuje linię z RAM spod adresów 1 0001 xxx zapamię-
tując z nią tag 1. Zwraca bajt 010 tej linii.
Jeśli jest to poprawne, to rozumiem, że rozszerzenie tej
idei na n-ścieżkową asocjację wymaga tylko dołożenia kompa-
ratora sprawdzającego za każdym razem te same linie w n
ścieżkach asocjacji i porównującego tagi, przy czym pojawia
się problem wyboru polityki wyboru ścieżki asocjacji, w
której usuwana (i zamieniana na nową) będzie linia cache
w przypadku, gdy zabranie wolnych miejsc na linie o tym
samym adresie linii, ale innym tagu.
* Fajny cache, połowa przestrzeni adresowej procesora ;)
> Sie troche ryplem. Ale tylko troche... Struktura cache i486 (oryginalnego):
> - odwz. 4-sciezkowe
> - linie 16B
> - adres wyznaczany jako 21bit znaczika (nr bloku linii) + 7bit wzgledny nr
> linii + 4bit nr bajtu w linii
> - wielkosc pojedynczego zestawu (sciezki) 8kB, calego cache'a 32kB
http://www.pcguide.com/ref/cpu/fam/g4I486DX-c.html
http://www.pcguide.com/ref/cpu/fam/g4I486SX-c.html
Wedle tego cały cache miał 8 KiB (po 2 KiB na ścieżkę).
Zresztą wynika to z Twoich danych też: 7 bitów adresu linii
to 128 linii po 16 B, a więc 2 KiB na ścieżkę asocjacji.
Razy cztery ścieżki to 8 KiB. Cache zunifikowany (bez podziału
kod/dane).
> No tak, ale VX-y tego nie mialy ;-) TX tez nie...
Zdecydowanie nie. Nie wiem, czy nie miały po prostu TAGa
wbudowanego w strukturę mostka północnego.
> Z kolei watpie, zeby 'niektore' COASTy mialy wlasny TAG RAM, bo musialoby to
> byc zrobione tak, zeby plyta ten TAG widziala, a jesli miala swoj i zlacze
> sie niczym nie roznilo od takiego bez TAGa, to byloby to chyba
> niewykonalne...
W instrukcji do ASUSa P55T2P4 jest napisane:
: WARNING: If the cache module that you install already have
: an extended tag, do not install another TAG SRAM into the
: TAG SRAM Upgrade Socket.
-- |""""""""""""""""""""""""""""""""""""""""""""""""""""""""""| | Radosław Sokół | mailto:rsokol_at_magsoft.com.pl | | | http://www.grush.one.pl/ | \................... ftp://ftp.grush.one.pl/ ............../
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 11:45:27 MET DST