Virtueller Speicher, Cache und TLBs

Ich habe diese Frage kürzlich bei Stackoverflow gestellt, aber mir wurde von einem Benutzer gesagt, dass es nicht zum Thema gehört, also poste ich sie hier, da es eher eine Hardware-Frage ist.

Ich versuche, für eine Prüfung zu lernen, und ich versuche, die folgende Frage zu beantworten.

Ich bin ehrlich, ich habe diese Frage hier schon einmal gestellt , aber jetzt, da ich sie besser verstehe, hatte ich das Gefühl, ich sollte eine neue Frage stellen, um mein Verständnis zu verfeinern, da meine Frage jetzt etwas anders ist.

Stellen Sie sich ein virtuelles Speichersystem mit den folgenden Eigenschaften vor:

  • Virtuelle 35-Bit-Adresse
  • 16-KB-Seiten
  • Physikalische 32-Bit-Adresse

Angenommen, dieses virtuelle Speichersystem ist mit einem satzassoziativen Acht-Wege-TLB implementiert. Der TLB hat insgesamt 256 TLB-Einträge, wobei jeder TLB-Eintrag eine virtuelle-zu-physische Seitennummer-Übersetzung darstellt.

Ein 64-KB-Datencache ist ein bidirektionaler satzassoziativer Cache. Die Blockgröße des Datencaches beträgt 128 Bytes.

Zeigen Sie die virtuelle zu physische Zuordnung mit einer Figur, die ähnlich wie in der folgenden Abbildung gezeichnet ist (jedoch mit allen erforderlichen Änderungen, die für den TLB und den in dieser Frage angegebenen Datencache erforderlich sind).

Geben Sie die Breite aller Felder und Signale an, die in den TLB und den Datencache für jede Speicheradresse ein- und ausgehen (sowie die Anzahl der von ihm durchgeführten Vergleiche).

Figur

Bisher habe ich mir Folgendes ausgedacht: (Direkter Link hier für größeres Bild)

Ich habe mir das ausgedacht:

Schema

Falls Sie neugierig auf die Schriftart sind, sie heißt Waltograph, eine TTF, die ich aus dem Internet heruntergeladen habe. Sie wurde als Standard in Farbe festgelegt, also beschloss ich, mein Studium mit etwas Disney-Magie zu erhellen.

Wie auch immer, da das Problem besagt, dass wir 16-KB-Seiten haben ( 2 4 ⋅ 2 6 = 2 14 Byte-Seiten), benötigen wir dann einen Offset von 14 Bit, wie in meinem Schema angegeben.

Da ich insgesamt 256 TLB-Einträge und einen 8-Wege-assoziativen TLB habe, brauchen wir dann einen Index von 5 Bit Breite ( 256 / 8 = 32 = 2 5 ). Was dann übrig bleibt, wird wie angegeben für das Etikett verwendet.

Dann habe ich 8 Komparatoren, wie gezeigt, die jedes Tag an einem Index mit dem angegebenen vergleichen. Das Ergebnis wird durch ein Und-Gatter mit dem gültigen Bit geleitet, um festzustellen, ob wir einen Treffer haben oder nicht (ich habe die Ausgänge des Und-Gatters durch ein Oder-Gatter gesteckt, um es zu einem Signal zu verketten).

Sobald wir wissen, dass wir einen Treffer haben, müssen wir die Daten (physische Adresse) aus dem TLB extrahieren. Ich habe einen One-Hot-Mux verwendet, um die physikalische Adresse des gewünschten TLB-Eintrags auszuwählen. Dann wird die Ausgabe der physikalischen Adresse mit dem Offset von der virtuellen Adresse verkettet.

Was mich jetzt verwirrt, ist der Cache-Teil. Ich verstehe, dass der TLB im Wesentlichen ein Cache der zuletzt verwendeten physischen Adressen ist. Ich verstehe jedoch nicht, was in dem Diagramm des Buches vor sich geht. Es teilt plötzlich die physische Adresse auf und verwendet sie, um den Cache zu indizieren, denke ich. Aber warum werden Cache und Daten separat angezeigt? und warum bleibt der Byte-Offset einfach schwebend? Ich bin mir ziemlich sicher, dass der Cache auch Daten speichern soll. Ich glaube nicht, dass sein einziger Zweck darin besteht, festzustellen, ob es einen Treffer oder Fehlschlag gibt oder nicht. Ich entschuldige mich im Voraus für meine Unwissenheit, aber das Buch behandelt kaum TLBs (es ist etwas mehr als eine Seite) und es leistet keine gute Arbeit, um die Beziehung zwischen einem TLB und einem Cache zu erklären.

Ich würde mich freuen, wenn jemand überprüfen könnte, was ich bisher getan habe, und mir erklären könnte, was Cache damit zu tun hat. Danke.

Der Cache speichert Adressen, um den Aufwand der Adressberechnung des virtuellen Speichers zu sparen. Das Valid-Bit umgeht veraltete Adressen (genau wie ein normaler Cache-Miss). Die Daten werden nicht mit der Adresse gespeichert und sind daher im Buch vom Cache getrennt. Der Zweck dieses Caches besteht nicht darin, den Treffer oder Fehlschlag zu bestimmen. Es soll die Adresse abrufen. Das Laden der Daten an einer bestimmten Speicheradresse unterscheidet sich vom einfachen Abrufen der Adresse. Es handelt sich um zwei getrennte Operationen.
@Schien: Das gilt alles für den TLB, der in der oberen Hälfte der Illustration von audiFanatic dargestellt ist, aber ich sehe nicht, wie das für die Fragen von audiFanatic zur unteren Hälfte dieser Illustration relevant ist.

Antworten (1)

Ich stimme zu, dass die Illustration verwirrend ist.

Die obere Hälfte der Seite soll den TLB beschreiben. Es hört sich so an, als ob Sie TLB-Sachen ziemlich gut verstehen.

Die gesamte untere Hälfte der Seite soll den Datencache beschreiben. (Das Label "Cache" auf der linken Seite soll auf die gesamte untere Hälfte der Seite angewendet werden. Wie könnte es neu gezeichnet werden, um deutlicher zu machen, dass es nicht nur für die Cache-Metadaten-Gültigkeits- und Tag-Bits gilt, sondern auch für alle Daten bis zum rechten Seitenrand?).

Es teilt plötzlich die physische Adresse auf und verwendet sie, um den Cache zu indizieren, denke ich.

Ja. Die untere Hälfte dieser Seite ist, wie Sie gerade gesagt haben, und wie bei den meisten großen Caches, ein physisch indizierter, physisch gekennzeichneter Datencache .

Aber warum werden Cache und Daten separat angezeigt?

Dieser Teil der Abbildung ist unnötig verwirrend.

Während im Prinzip jedes Speicherwort seine eigenen Valid+Tag-Bits haben könnte, teilen sich die meisten Datencaches die Valid+Tag-Bits für einen viel größeren Datenblock, der aus dem Hauptspeicher kopiert wird – ein Block, der als Cache-Zeile bezeichnet wird. Das Laden von mehr Daten als das Programm, das speziell in einer einzelnen Anweisung angefordert wird, ist oft hilfreich, da praktisch alle Programme eine gewisse räumliche Lokalität haben .

Die resultierende Cache-Eintragsstruktur sieht in etwa so aus

v tag w w w w  w w w w  w w w w  w w w w
v tag w w w w  w w w w  w w w w  w w w w
v tag w w w w  w w w w  w w w w  w w w w
v tag w w w w  w w w w  w w w w  w w w w
v tag w w w w  w w w w  w w w w  w w w w
v tag w w w w  w w w w  w w w w  w w w w
v tag w w w w  w w w w  w w w w  w w w w
v tag w w w w  w w w w  w w w w  w w w w

wobei das 'v' das gültige Bit angibt und jedes 'w' ein Datenwort darstellt.

Unerklärlicherweise zeigt die Illustration des Buches nur einen der vielen Datenblöcke im Cache:

v tag
v tag
v tag
v tag
v tag
v tag w w w w  w w w w  w w w w  w w w w  < -- hit on this cache line.
v tag
v tag

und dann dreht die Illustration des Buches unerklärlicherweise die Wörter in dieser Cache-Zeile, um alle Wörter dieser einen Cache-Zeile übereinander gestapelt zu zeigen.

Wenn der Daten-Cache einen Treffer erkennt – wenn das Cache-Tag mit dem Tag-Teil der gewünschten Adresse übereinstimmt und das gültige Bit gesetzt ist – dann zeigt der "Block-Offset"-Teil der Adresse ein bestimmtes Wort dieser einen bestimmten Cache-Zeile an .

Vielleicht hat der Illustrator keinen Platz mehr, um eine extrem breite Cache-Linie zu zeichnen, und hat sich willkürlich entschieden, diese Linie zu drehen, damit sie auf die Seite passt, ohne darüber nachzudenken, wie verwirrend das wäre?

Die Blockgröße des Datencaches beträgt 128 Bytes.

Für jede physische Byteadresse zeigen die unteren 7 Bits also ein bestimmtes Byte innerhalb einer Cache-Zeile an, und alle oberen Bits dieser Adresse werden verwendet, um eine bestimmte Cache-Zeile auszuwählen.

Warum bleibt der Byte-Offset einfach schwebend?

Der Byte-Offset wird in dieser Darstellung schwebend belassen, da der Byte-Offset nicht vom TLB oder vom Daten-Cache verwendet wird. Ein typischer TLB und der Daten-Cache, wie der dargestellte, befassen sich nur mit ausgerichteten 32-Bit-Wörtern. Die 2 Bits der Adresse, die eines der 4 Bytes innerhalb eines 32-Bit-Wortes auswählen, werden an anderer Stelle behandelt.

Einige einfache CPUs haben nur Hardware für ausgerichteten Ganzwortzugriff. (Ich nenne sie "Weder Endian" in "DAV's Endian FAQ"). Compiler-Schreiber für solche CPUs müssen Padding hinzufügen, um sicherzustellen, dass jede Anweisung ausgerichtet ist und jeder Datenwert ausgerichtet ist. (Der Zwei-Bit-Byte-Offset sollte auf diesen Maschinen immer Nullen sein).

Viele CPUs haben einen LOAD-Befehl, der nicht ausgerichtete 32-Bit-Werte in ein 32-Bit-Register laden kann. Solche CPUs haben an anderer Stelle spezielle Hardware (nicht Teil des Cache), die für jeden LOAD-Befehl (manchmal) 2 Lesevorgänge aus dem Datencache durchführt - der nicht ausgerichtete 32-Bit-Wert kann 2 verschiedene Cache-Zeilen überlappen; einer oder beide Lesevorgänge können einen Cache-Miss verursachen. Die 2 Bits der Adresse, die eines der 4 Bytes innerhalb eines (ausgerichteten) 32-Bit-Wortes auswählen, werden intern von der CPU verwendet, um die relevanten Bytes auszuwählen, die der Cache für diese Lesevorgänge zurückgibt, und diese Bytes wieder in die (nicht ausgerichtete ) 32-Bit-Wert, den der Programmierer erwartet. Obwohl solche Anweisungen die richtigen Ergebnisse liefern, egal wie die Dinge im Speicher ausgerichtet oder falsch ausgerichtet sind, Assembler-Programmierer und Compiler-Autoren und andere Programmierer, die von der Optimierung besessen sind, fügen manchmal ohnehin Padding hinzu, um (einige) Anweisungen oder (einige) Daten oder beides auszurichten. ("Wie und wann wird die Cache-Zeilengröße ausgerichtet?" ; "An Cache-Zeile ausrichten und die Größe der Cache-Zeile kennen" ; usw.) Sie versuchen, dieses Padding zu rechtfertigen, indem sie behaupten, es "optimiere" das Programm, um "schneller zu laufen". Neuere Tests scheinen darauf hinzudeuten, dass die Datenausrichtung für Geschwindigkeit ein Mythos ist .

die Beziehung zwischen einem TLB und Cache

Konzeptionell ist die einzige Verbindung zwischen dem TLB und einem (physisch indizierten, physikalisch gekennzeichneten) Datencache das Bündel von Drähten, die den Ausgang der physikalischen Adresse des TLB zum Eingang der physikalischen Adresse des Datencaches tragen.

Eine Person kann einen Datencache für eine einfache CPU ohne virtuellen Speicher entwerfen, der physische Adressen zwischenspeichert. Eine andere Person kann einen TLB für eine einfache CPU entwerfen, die keinen Datencache hat (Eine CPU mit einem TLB, aber ohne Datencache war früher eine übliche Anordnung für Mainframe-Computer).

Im Prinzip kann eine dritte Person diesen TLB und diesen Datencache zusammenfügen, indem sie den Ausgang der physikalischen Adresse des TLB mit dem Eingang der physikalischen Adresse des Datencaches verbindet. Der TLB weiß weder noch kümmert es ihn, dass er nun mit dem Daten-Cache statt mit dem Adressbus des Hauptspeichers verbunden ist. Der Datencache weiß weder noch kümmert es ihn, dass er nun mit dem TLB verbunden ist, anstatt direkt mit dem/den CPU-Adressregister(n).

Virtueller Speicher, Cache und TLBs
AntwortenHierDatenschutz-Bestimmungen1y, 0v