Servus Ich möchte für meinen Cache die Adresse für den realen Speicher wiederverwenden für das Tag und den Index im Cache, ggf. auch das Set wenn es ein N-Way-Set ist - siehe Anhang. So, nun stellt sich mir folgende Frage: Wenn ich den realen Speicher voll nutze ist das ja dufte. Aber wenn nicht hab ich ja lücken, dann könnte es ja sein das ein Set oder bei Direct Mapped ein Index NIE genutzt wird ... Ignorieren oder gibts dafür ne Lösung? Grüße
Angehängte Dateien:
-
n_way_set_asso.PNG
511 Bytes
Ano Nym schrieb: > Ich möchte für meinen Cache die Adresse für den realen Speicher > wiederverwenden für das Tag und den Index im Cache, ggf. auch das Set > wenn es ein N-Way-Set ist - siehe Anhang. Bahnhof. Ich gehe im Folgenden mal davon aus, dass du normale Caches meinst, und nicht irgendwas Exotisches. > So, nun stellt sich mir folgende Frage: Wenn ich den realen Speicher > voll nutze ist das ja dufte. Aber wenn nicht hab ich ja lücken Wenn du wie jeder normal denkende Mensch das RAM am Stück in den Adressraum legst, dann gibts ein paar Tags, die nicht vorkommen. Und? Wenn alles RAM im untersten Viertel des Adressraum liegt, dann kannst du beispielsweise die oberen beiden Tag-Bits einsparen und den übrigen Adressraum am Cache vorbei führen - so wurde es früher bei externen Caches häufig gemacht. Lücken gibts nur, wenn die Anzahl Bits für Index/Set+Byte grösser sind als die Adressbits vom RAM. Aber das passiert nur, wenn der Cache grösser ist als das RAM ;-), oder du das RAM sehr bös zerstückelt in den Adressraum legst.
Ich meine normale Caches ja. Funktioniert halt als Direct Mapped (Direkt Adressiert), Fully Associative (Zeuch kann überall stehen) und N-Way-Set Associative (Mischung aus beidem). Was ich meine ist: Ich hab mir aus meinem Speicher Adressen mit einer Formel erzeugt (page+block*64). Der Raum wäre dann von 0 bis 64+2048*64=131.136. Primitiv, vll unsinnig aber tut hier nix zur Sache. Wenn ich jetzt die Adresse zerstückel und über 50 Elemente die Zahl 5 für den Index nicht vorkommt wäre der Index im Cache ja für die Füße ... Einfach nicht dran stören weil "ist so"? Achtung: Ich fang jetzt an laut zu denken :) Ich hab mal das Test-Pattern für die Zugriffe angehängt. Schwer aber es ist zu erkennen das gewisse Adressen einfach nicht vorkommen - 510 zum Beispiel. Das entspräche 0b00000000 00000000 00000001 11111110 (Adresse ist 32bit) ... Das wäre ja recht ungünstig für das Tag ... Blöd Oo
Ano Nym schrieb: > Ich meine normale Caches ja. Funktioniert halt als Direct Mapped (Direkt > Adressiert), Fully Associative (Zeuch kann überall stehen) und N-Way-Set > Associative (Mischung aus beidem). Fein. Caches sind mir recht gut vertraut. > Was ich meine ist: Ich hab mir aus meinem Speicher Adressen mit einer > Formel erzeugt (page+block*64). Der Raum wäre dann von 0 bis > 64+2048*64=131.136. Primitiv, vll unsinnig aber tut hier nix zur Sache. Immer noch Bahnhof. Gedankenlesen kann ich nicht. Vielleicht hilft es, wenn du dich etwas systematischer und vor allem vollständiger ausdrückst. (page+block*64) ist zwar eine Formel, aber niemand ausser dir weiss, wo du page/block herholst und was du mit diesen Begriffen meinst. Wonders als in dieser Formel sind nämlich weder page noch block bisher in deinem Text aufgekreuzt und beide Begriffe sind in der Nomenklatur von Caches nicht universell gebräuchlich. Auch die "64" lässt sich nicht zuordnen. Bleib anfangs mal beim direct mapped cache.
PS: Was hat das eigentlich mit dem GCC (=>Forum) zu tun?
Problem: Ich kann nicht einfach beim Direct Gemappten sein weil der Simulator den ich bau jeden der 3 beinhalten soll - modular natürlich sonst wärs ja langweilig ... Hab ich mir übrigens so nicht ausgesucht :) Nun, der reale Speicher - also da wo das Zeug drin steht das im Cache zwischengelagert werden soll - besteht aus Pages und Blöcken. 2048 Blöcke zu je 64 Pages. Um nun eine Adresse zu bilden die jedes der 64*2048 Elemente Eineindeutig abbildet addier ich die jeweilige Page mit ihrem Block und verpasse Block noch einen Offset (5+3 = 3+5 aber 5+2*3 != 3+5*2). So, nun verwende ich das Feld byte einfach mal nicht, die Info welches gebraucht wird übergeb ich anders. Hab ich also bei 32bit Adresse 32bit nur für den Index/Set und für das Tag. Im Beispiel mit den 512 würde das Bedeuten: 511 = 0b00000000 00000000 00000001 11111111 Index = 8bit (0-256 Elemente reichen...) = 0b11111111 Tag = 0b00000000 00000000 00000000 00000001 512 = 0b00000000 00000000 00000001 11111110 Index = = 0b11111110 Tag=32bit-8bit=24bit--> 32bit genommen =0b00000000 00000000 00000000 00000001 513 = 513 = 0b00000000 00000000 00000010 00000001 Index = 0b00000001 Tag = 0b00000000 00000000 00000000 00000010 Wie man sieht haben 511 und 512 das gleiche Tag, aber einen anderen Index/Set. Passt es also doch so? Ich bin auch etwas verwirrt was das Thema angeht, deshalb auch der etwas dämliche Text hier von mir :( Ich geb mir wirklich mühe das Verständlich rüber zu bringen was ich als Problem hab :D Warum GCC? Wo sonst hin ... dachte in GCC gehts um Programmieren auch wenn das ne PC Software wird
Ano Nym schrieb: > Problem: Ich kann nicht einfach beim Direct Gemappten Ich meinte es für diese Betrachtung hier, um es sprachlich zu vereinfachen. > Nun, der reale Speicher - also da wo das Zeug drin steht das im Cache > zwischengelagert werden soll - besteht aus Pages und Blöcken. 2048 > Blöcke zu je 64 Pages. Ok. Soweit hat das mit dem Aufbau deines Speichers zu tun, aber nicht mit dem Cache. Könntest also auch genausgut die Adressen über 0..128K wandern lassen, statt die Betrachtung mit 2 Variablen zu verkomplizieren. > ihrem Block und verpasse Block noch einen Offset (5+3 = 3+5 aber 5+2*3 > != 3+5*2). Was ist für dich ein Offset? Offsets werden gemeinhin addiert, nicht multipliziert. > So, nun verwende ich das Feld byte einfach mal nicht, die Info welches > gebraucht wird übergeb ich anders. Nun wirds interessant. > Hab ich also bei 32bit Adresse 32bit nur für den Index/Set und für das > Tag. Das funktioniert nur, wenn der Adressraum nicht 4G Bytes sondern 4G Cache-Lines umfasst. > Im Beispiel mit den 512 würde das Bedeuten: > 511 = 0b00000000 00000000 00000001 11111111 > Index = 8bit (0-256 Elemente reichen...) = 0b11111111 > Tag = 0b00000000 00000000 00000000 00000001 Ich schliesse daraus, dass dein bisher in seinen Parametern streng geheim gehaltener Cache als direct mapped verstanden 256 Lines umfasst. > 512 = 0b00000000 00000000 00000001 11111110 Dein hübsch dargestellter Binärwert entsprich 510. Anderer Index, gleiches Tag, ja. Und?
Ano Nym schrieb: > Warum GCC? Wo sonst hin ... dachte in GCC gehts um Programmieren auch > wenn das ne PC Software wird Die "GCC" Ecke ist für Probleme da, die mit dem GCC Compiler selbst zu tun haben, nicht für alle Probleme, die man irgendwie mit Programmierung lösen kann.
Wenn du einen Zähler sequentiell oder zufällig über 0..131071 laufen lässt und daraus die statistische Verteilung der Cache-Indizes ermittelst, was kommt dann raus? Bei mir: Index ist gleichverteilt und ohne Lücken. Wenn du nun statt dessen zwei verschachtelte oder zufällige Zähler verwendest, block=0..2047 und page=0..63, daraus eine Adresse 0..131071 erzeugst, und nun die Indizes nicht mehr gleichverteilt sind, dann stimmt was mit deiner Rechnung nicht.
Egal wie es funktioniert ja. Selbst wenn ich 10x das gleiche Tag habe
habe ich 10 unterschiedliche Indezes oder Sets ;)
Ich lass das Byte Feld weg, dafür übergeb ich im Simulator direkt
welches Byte ich aus dem Speicher haben möchte. Wird auch im Zielsystem
nicht benutzt.
Falls Informationen fehlen tut mir das leid, weiß ja nicht was alles
interessant ist ...
Gehen wir weiter:
Eine Cache Line soll 2kB groß sein. 256Elemente im Cache würden dann
512kB entsprechen. Mehr ist für den Cache nicht angedacht, daher ist
"index" auf 8bit begrenzt, reicht ja.
Wenn ich das Bytefeld weglasse und die Adresse 32bit lang ist bleiben
für das Tag 24bit übrig. So komm ich da drauf ;)
> 512 = 0b00000000 00000000 00000001 11111110
Warum das falsch ist, keine Ahnung. Ich hatte google machen lassen :)
Und zu den Zugriffszahlen:
Page und Block sind jeweils gleichverteilte Zufallszufahlen. Die beiden
Addiert und Block zusätzlich gewichtet (nicht mit einem Offset versehen,
stimmt) ergeben die Adresse von 0 bis 131.136.
Egal wie, qed - es ist ja schon bewiesen/gesagt das es funktioniert.
Denn selbst bei gleichbleibendem Tag ändert sich der Index/das Set.
Danke. Und falls hier alles etwas wirr geschrieben ist tut mir das leid
- liegt einzig und allein an meinen wirren Gedanken :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.