Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Invertierte SKT
Thema invertierte Seitenkacheltabelle:
Wie finde ich denn bei bekannter PID und bekannter Seitennummer (Teil der log. Adresse) die zugehörige Kachel?
Lässt sich die phys. Adresse aus der Eintragsnummer in der Tabelle berechnen?
ich versuchs mal wieder… 
also ich denke ja. Durch die PID kommt ja nur eine begrenzte Anzahl von Kacheln in Frage. Diese werden in der KST nach der bekannten Seitennummer durchsucht. Enthält eine Kachel in der KST die bekannte Seitennummer so spuckt die Tabelle die physikalische Adresse dieser Kachel aus.
hmm, soweit ich das sehe, hat diese invertierte skt nur 2 spalten fuer die pid und die seitennummer - keine 3. spalte fuer die kacheladresse.
da aber auf der rechten seite so eine schoene geschweifte klammer ist, sieht das so aus, als waere der offset von der skt-basis die gesuchte physikalische adresse. dann waere die invertierte skt also im prinzip nur ein kleines abbild des hauptspeichers, entsprechend einfach liesse sich eine gesuchte seite lokalisieren.
googeln hat wenig bis nichts ergeben, kann mir jemand zustimmen / meine theorie bestaetigen?
schöne Theorie! Klingt sehr plausibel… die geschweifte Klammer is mir gar nicht aufgefallen. Ich bin dafür! 
ok, soll ich eine umfrage starten :]?
Also ich seh das genau so wie Steppenwolf…
Jede Spalte steht für eine Kachel
Zeile? Dann bin ich dabei.
Aber muss man nicht leere Kacheln bis zur größten verwendeten repräsentieren?
Bin froh, dass das nicht dran kommt.
jo.
öh, ups, wieder leichte koordinationsprobleme heut, sorry
was hast du nochmal gemeint, wie freie kacheln repräsentiert werden? da wird dann wohl auch ein bit zur verfügung stehen, dass einem sagt, ob die kachel belegt ist, oder?
wie waere es, wenn eine kachel dann frei ist, wenn kein prozess eingetragen ist?
Wenn die KST ein Speicherabbild ist, dann kann man - wie Steppenwolf das geschrieben hat - mit der SeitenNr in der KST nachschauen und die Kacheln mitzählen. Dann rechnet man mit der Kachelanzahl und der Kachelgröße die Kachel für die Seite aus. Es werden aber im Betrieb ja wohl wahllos Kachel wieder freigegeben und genutzt. D.h. man hat irgendwann Lücken im realen Hauptspeicher. Wenn die KST ein Abbild ist, dann muss man wohl auch diese Lücken repräsentieren, oder? Sonst kann man nicht mehr offset rechnen.
Wenn das stimmt und man clever ist, nimmt man bei einer neuen Anfrage immer die niedrigste freie Kachel. Deshalb meinte ich, dass man evtl nur bis zur höchsten benutzten Kachel die KST verwalten muss.
Keine Ahnung ob das stimmt. Rumraten ist wohl hier nicht sinnvoll. Entweder es weiß jemand oder nicht. Ich weiß es nicht.
jo.
jo, du schwafelst wirr. warum sollte man denn lücken repräsentieren? entweder in der KST steht in einer zeile irgendwas drin, dann haste da auch die adresse, oder es steht nix drin, dann is halt die kachel unbelegt…du verwirrst, der du unter dem storch wohnst.
War ausserdem nicht gerade ein Vorteil der KST, dass sie recht klein ist, da es nur für belegte Kacheln einen Eintrag gibt?
lo_pez rechtgeb
ja, ja, ja.
da habt ihr alle „ja“ geschrien. was steht denn da? abbild ist doch wohl alles oder nicht? zustimmen, dagegen, zustimmen, dagegen …
in der kst stehen ja seiten drin. wenn ich offset rechnen will, brauch ich aber die nummer der kacheln bis zu kachel für die seite. wenn also vorher eine kachel leer ist, dann muss die auch drin sein. les doch mal genau was ich schreib.
meine annahme: jede zeile in der kst repräsentiert eine kachel und zwar sortiert.
meinst jetzt keine zeile oder leere zeile?
tja, ich versteh es ja auch nicht 
entweder erklärt das jemand jetzt gescheid oder ich lern ab sofort was relevantes für morgen 
da jo, der unter dem storch wohnt
das glaube ich einfach nicht. aber jetzt ist es zu spät eine grundsatzdiskussion vom zaun zu brechen. frag mich morgen nochmal im auto.