Autor Thema: Verständnis Frage GDT  (Gelesen 4060 mal)

Hobby Programmiere

  • Beiträge: 42
    • Profil anzeigen
Gespeichert
« am: 14. October 2009, 17:36 »
Hi Leute,
ich weiß, euch nervt das Thema wahrscheinlich. Aber ich habe ein kleines Verständnis Problem. Und zwar:
Ich habe das jetzt so verstanden, dass die GDT dazu ist, den Speicher in Segmente zu unterteilen, und diesen dann verschiedene Berechtigungen bzw. Zwecks zu zuteilen. Was mir aber nicht klar ist, wie er weiß, welche Adressen dass im Speicher konkret sind. Ich meine, in den Tuts wird immer als Basis 0 und als Limit 4GB angegeben. Woher weiß er dann, welche Addres Bereiche konkret gemeint sind.
Ich hoffe, mir hilft einer. Vielen dank schon mal im voraus.

P.S. Bevor ihr fragt, ja ich habe schon die Forensuche benutzt, aber nicht hilfreiches gefunden.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 14. October 2009, 17:57 »
Der Speicherbereich von 0 bis 4 GB eben. ;)

Damit decken die Segmente den kompletten Speicher ab. Eigentlich möchte man die Segmentierung normalerweise nicht benutzen, aber abschalten kann man sie nicht - insofern ist "großes Segment über alles" die beste Annäherung an "keine Segmentierung".
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Hobby Programmiere

  • Beiträge: 42
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 14. October 2009, 18:05 »
Aber ich dachte, dass wird dazu benutzt, dass ein Programm nur in seinem eigenem Speicher schreiben kann...

XanClic

  • Beiträge: 261
    • Profil anzeigen
    • github
Gespeichert
« Antwort #3 am: 14. October 2009, 19:24 »
Dafür kann man die GDT benutzen, ja. Aber normalerweise will man das nicht.  :-D
Und zwar deshalb, weil Paging ein (zumindest meiner Meinung nach) einfacherer aber genau so wirkungsvoller (wenn nicht sogar besserer) Speicherschutz ist (dadurch verbrauchen kleine Programme nicht genau so viel Speicher wie große, ...).
Deshalb verwendet man Segmente, die über den gesamten Speicher gehen, weil man den Speicherschutz später mit Paging erledigt. :-)

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 14. October 2009, 21:01 »
Hallo,


Zitat
Aber ich dachte, dass wird dazu benutzt, dass ein Programm nur in seinem eigenem Speicher schreiben kann...
Dazu gibt man üblicherweise jedem Process seinen eigenen linearen Adressraum, einen eigenen Page-Table-Baum, von 4 GB (auf einem 64Bit-System natürlich 2**64 Bytes) in dem aber nur wenig Speicher, nur so viel wie auch benötigt, tatsächlich vorhanden (P-Bit im entsprechenden Page-Table-Eintrag gesetzt) ist. Zusätzlich muss noch der Kernel-Bereich in jeden Process-Adressraum identisch eingeblendet werden.

Mann kann das Ganze auch mit Segmentierung erledigen, dann braucht man aber pro Process mehrere Segmente weshalb man dafür am besten für jeden Process eine eigene LDT einrichtet und so in der GDT nur einen Eintrag pro Process benötigt, den für die LDT. Das Konzept bietet ein Paar Vorteile hat aber auch einige negativen Seiten, z.B. FAR-Pointer. Siehe dazu http://lowlevel.brainsware.org/forum/index.php?topic=2224.0:-D


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

Hobby Programmiere

  • Beiträge: 42
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 15. October 2009, 09:59 »
Ah, dass heißt also, dass man die GDt eigentlich gar nicht mehr benutzen will, und das alles dann lieber mit Paging benutzt. OK, habe ich jetzt verstanden. Danke!

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 15. October 2009, 12:28 »
Hallo,


Ja, Du hast das richtig verstanden.


Mit den paar GDT-Einträgen hebelt man die Segmentierung aus so als währe sie nicht vorhanden. Die Segmentregister musst Du aber trotzdem an einigen Stellen, insbesondere in Interrupt/Exception-Handlern, mitschleifen. Segmentierung, in der Form wie sie der 386-PM bietet, gibt es sonst bei keiner Plattform so das ein OS das auf mehreren Plattformen laufen will diese nicht benutzen kann. Stattdessen benutzt man die überall (also auf allen Plattformen die mehr als simple Embedded-Mikro-Controller sein wollen) vorhandenen Paging-Mechanismen.

Ich persönlich entwickle an einer komplett neuen Plattform die voll auf Segmentierung setzt (nur das ich einige Probleme der Segmentierung des 386 besser lösen will) aber dafür gibt es nirgends Unterstützung (weil sich einfach niemand damit auskennt) und so ist das ein sehr schwerer Weg. Du kannst sicher versuchen für den 386-PM ein OS mit Segmentierung zu entwickeln aber ich rate davon ab da Dir wirklich niemand dabei helfen kann.


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

DeepDancer

  • Beiträge: 58
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 17. October 2009, 01:03 »
Tagchen auch zusammen....

Ich hab da jetzt auch mal noch ne kleine Frage zu - die sich mir aus all den Tut´s und Forenbeiträgen noch nicht so ganz erschliessen mag.

Also:
Ich hab in der GDT ja den Eintrag für den User-Mode mit der Länge 4GB.
Aber wie funzt nun das mit den Programmen die da dann laufen sollen?
Wie bekommen die denn ALLE jeweils 4 GB an rein theoretischem Speicher?

Das ist noch etwas was ich bisher einfach ned ins Hirn bekommen habe ;)

Weil wenn ich ja nun die 4GB aufgebraucht habe die ich da in der GDT angelegt habe, wo nehm ich denn "frischen" Speicher für z.B. noch nen Programm her??

Kann mir das einer iwie erklären?

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 17. October 2009, 01:39 »
Du benutzt nicht die Segmentierung, um die Programme zu trennen. Ich schreibe gerade an einer Fortführung des Tutorials, wo genau diese ganzen Speicherverwaltungs-Geschichten vorkommen sollen, aber du kannst dir vorerst mal den Artikel über Paging durchlesen. Der Trick ist, dass jeder Prozess sein eigenes Page Directory bekommt.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 17. October 2009, 12:13 »
Hallo,


Zitat
Der Trick ist, dass jeder Prozess sein eigenes Page Directory bekommt.
Aber in diesem Page Directory ist natürlich nicht jede Page zugewiesen. Ein kleines Programm benötigt vielleicht nur ein paar MB und nur so viel wird tatsächlich als physischer Speicher alloziert und über das Page Directory des entsprechenden Prozesses in dessen linearen/virtuellen Adressraum "eingemountet". Der Rest bleibt "leer", ein Zugriff auf leere Bereiche löst eine "Page not Present"-Exception aus, was dann das OS als "Prozess benötigt mehr RAM" interpretieren kann oder den Prozess beendet.

Zusätzlich muss noch der Kernel in jeden Adressraum mit eingeblendet werden, damit nicht bei jeden Aufruf einer Kernel-Funktion das Page Directory gewechselt werden muss, so das von den 4 GB eh nur 2 bis 3 GB übrig bleiben. Der Kernel, und damit z.B. auch die IRQ-Handler, hat also keinen eigenen Kontext sondern ist in allen Kontexten vorhanden (immer an der selben virtuellen Adresse).


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

DeepDancer

  • Beiträge: 58
    • Profil anzeigen
Gespeichert
« Antwort #10 am: 17. October 2009, 18:56 »
Aaaaaalso:

Wenn ich das nu richtig verstanden habe dann stellt jede PageDirectory 4GB an Speicher dar?

Dann könnte ich ja, rein theoretisch, unendlichen Speicher benutzen? Mal davon abgesehen dass dann halt entsprechend RAM oder HD verbaut sein muss ;)

So ganz leuchtet mir gerade das alles noch nicht ein, und das ist auch vorerst das letzte was ich mal noch kapieren muss an der ganzen Sache *gg*

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 17. October 2009, 19:50 »
Hallo,


also jeder Prozess bekommt einen eigenen virtuellen 4GB Adressraum. Dieser Adressraum ist aber erstmal nur eine Art leere Spielwiese für den Prozess, der muss dann pageweise mit echten physischen Speicher gefüllt werden. In diesen 4GB Adressraum ist immer auch der Kernel eingeblendet wofür üblicherweise 1 bis 2 GB vorgesehen sind manchmal aber auch weniger. Die restlichen 2 bis 3 GB Adressraum gehören dem Prozess selber dort ist aber erst mal noch fast alles leer also noch kein physischer Speicher zugeordnet, nur der Programmcode und die Daten direkt aus dem Executable-File sind vom Executable-Loader des OS bereits vorbereitet. Bei einem kleinen Programm kann es durchaus sein das nur wenige Pages bereits mit physischen Speicher gemappt sind also nicht "leer" sind. Der Prozess kann dann zur Laufzeit weiteren Speicher vom OS pageweise anfordern und dabei auch festlegen an welche virtuelle Adressen die Pages gemappt werden sollen. Das kann man mit einem Buch mit sehr vielen Seiten bei dem die meisten Seiten "nicht benutzbar" sind vergleichen, nur die Seiten die "benutzbar" sind kosten tatsächlich Papier und wenn Du auf die nicht benutzbaren Seiten lesen/schreiben möchtest bekommst Du eins auf die Finger. Die Speicherverwaltung des OS kümmert sich darum das jeder Prozess physische Pages für seinen virtuellen Adressraum bekommt, das klappt natürlich nur so lange noch physischer Speicher verfügbar ist (swappen auf die Festplatte ist eine Stufe komplexer aber das Grundkonzept bleibt). Das funktioniert auch mit mehr als 4 GB physischen Speicher aber dann muss das Paging größere physische Adressen aufnehmen können. Intel hat sowas tatsächlich mit dem Pentium-Pro eingeführt so das ein OS das diesen Trick beherrscht tatsächlich mehrere Programme die zwar jedes weniger als 3 GB Speicher für sich aber in der Summe mehr als 4 GB Speicher brauchen gleichzeitig ausführen kann. Beim swappen werden einfach Pages, auf die momentan keiner zugreift, auf die Platte ausgelagert so das wieder mehr physischer Speicher verfügbar ist.

Ich hoffe ich konnte etwas zur Erleuchtung beitragen.


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

 

Einloggen