[HaBo]

Mrjoke

Anzeige

Hallo erstmal,
ich habe da eine Frage zur Speicheradressierung. Ein Normaler 32 Bit Prozessor kann maximal ca. 4GB RAM addressieren (2 ^ 32) . Die Register der CPU sind aber nur 16 Bit gross. Damit man eben mehr Adressieren kann, verwendet man die Segment : Offset Darstellung. Diese wird errechnet indem man die 16 Bit der Segmentaddresse mit 16 Multipliziert und dann mit der Offsetaddress addiert.
Nun zu meiner Frage:

Wie kann denn jetzt der Prozessor diese 4GB RAM ansprechen wenn über die Segment : Offset-Darstellung nur (65535 * 16 +65535 = 1114095 Bytes) ca. 1 MByte addresiert werden können ???????

Das sind doch eindeutig zu wenig !!!

Wäre nett, wenn mir das mal jemand genau erklären könnte.

Zirias

Fast, er kann _GENAU_ 4GB addressieren.

Phalsch. Wenn es eine 32bit-CPU ist, dann sind auch die Register 32bit breit. IA32 hat allerdings aus Kompatibilitätsgründen zu 8088 noch 16bittige Überbleibsel und einen "real mode"

Ja, so haben es die alten 16bitter von intel (8086, 8088, 80286) gemacht.

Indem man ihn in den protected mode schaltet und dann das virtuelle Speichermanagement mit vollen 32bit zur Verfügung hat

Tja auch hier wieder: _GENAU_ 1MB. Da siehst du mal, wieso sich der Speicher auf alten DOSen aus 640kb base memory (ganz früher 512) und 384kb upper memory zusammensetzte, insgesamt genau 1MB

Greets, Ziri

olli

hi !
Also... im 32 Bit Protected Modus teilt man den Arbeitsspeicher in Segmente .. das macht man mit Deskriptoren (Lat:describere:beschreiben).
Das Auswählen eines Segments macht man mit einem 16 Bit Selektor. Dann wird ein 32 Bit Offset gebraucht um im selektierten Segment weiter zu addresieren.

Ich glaub an dieser Stelle hat sich dein Problem gelöst

Zirias

Du redest jetzt aber von der MMU. Das Segmentregister kann nur das OS selbst bedienen, jeder Task hat seinen virtuellen Adressraum, der eben 4GB groß ist (32bit Adressregister).
Die physikalische Adressierung des Speicher ist dann _nochmal_ anders So ist das heute eben, Speicher ist komplett virtualisiert.

Greets, Ziri

Mrjoke

Wow, erstmal danke für die schnellen Antworten


1. Also haben die 32 Bit CPu's auch wirklich 32 Bit (hat mich schon gewundert warum die sonst 32 Bit CPu's heisen ) und werden im Protected Mode voll beansbrucht. Aber im REal Mode wir nur mit 16 Bit gearbeitet.

soll das heißen das man mit den .Com nur 1MB RAM zur verfügung hat wenn man sie für reine Dos umgebungen schreiben will???

2. Irgendwie kann man doch mit hilfe eines Commanshell befehls den Real Mode aktivieren oder ???

Zirias

Nein, man hat sogar nur 640kb abzüglich dessen, was MS-DOS und diverse TSRs belegen zur Verfügung. Das sind eben die Einschränkungen von MS-DOS. Man kann natürlich mehr Speicher über XMS oder EMS ansprechen, kompliziert auf jeden Fall, hab mal ne EMS-Implementierung in TurboPASCAL gesehen ... irgendwie will man das nicht machen *g*

Bahnhof?

Greets, Ziri

Mrjoke

Gut dann hab ich mich halt geirrt und es gibt soetwas nicht )
nochmal danke das ihr mir das erklärt habt.

Aber zu guter letzt noch eine Frage:

Heißt das, wenn ich 4GB Physikalischen speicher hab, ich trotzdem mehrer Anwendungen die 4GB benötigen starten kann, solange genügend Virtuellerspeicher freigegeben ist????

Mnemonix

Hat man bezüglich der .COM Dateien nicht nur 64 KByte Speicher zur Verfügung? Man darf ja in .COM Dateien immer nur ein Segment verwenden, was eben diese 64 Kbyte wären.

Zirias

Du machst dir deine Vorstellung etwas zu einfach Jeder Task bekommt seinen virtuellen Adressraum, die MMU "mappt" die virtuellen Adressen auf physikalische. Sollte die virtuelle Adresse auf Daten zeigen, die sich zur Zeit gar nicht im Hauptspeicher befinden, gibt es eine "page fault" exception, die der Pager des Betriebssystems abfängt und dann entsprechend versucht, die Speicherseite mit den Daten einzulagern (aus dem swap, dazu muss dann wohl eine andere Seite ausgelagert werden).

Jetzt denke nicht, dass jeder Task 4GB belegen kann, nur weil sein Adressraum so groß ist. Wenn man Speicher belegen will, muss man den beim Betriebssystem anfordern, und man bekommt nur welchen zugeteilt, solange das Betriebssystem das für sinnvoll hält (freies RAM oder genug Seiten, die ausgelagert werden können, um freies RAM zu schaffen). Unter Windows NT sind schon mal die oberen 2GB des virtuellen Adressraums für das Betriebssystem reserviert, die bekommt kein Task jemals zugewiesen. Wahrscheinlich denkt sich MS "2GB should be enough for everyone" *fg*

Greets, Ziri

edit: Mnemonix, das kann sein, ich hab ehrlichgesagt nie .COM-binaries erstellt mein TurboPASCAL Compiler hat mir immer .EXE-binaries gemacht, da war die Einschränkung nur, dass der Code selbst in ein 64kb-Segment passen musste. Aber ich weiß nicht, in wie weit das wirklich Architektur-bedingt ist, ich glaube eher das sind Einschränkungen von MS-DOS.

Mrjoke

Stimmt, hab nachgelesen ( des hätte ich besser vorher tun sollen bevor ich hier blöd rumfrage ) ) Modell Tiny für .Com Dateien:

Das kleinste Modell, bei dem sich Code, Daten und Stack ein einziges Segment, das Codesegment, teilen.
Die Größe des Programmes ist damit auf 64 KByte beschränkt. Alle im Programm verwendeten Adressen sind near?Adressen.

Ja stimmt das hatte ich mir zu beginn etwas einfacher vorgestellt aber dank deiner erklärungen check ich jetzt schon ein bischen mehr.

Mnemonix

Hier findest du eine ziemlich gute Beschreibung des Protected Modes mit Addressierung etc.:
http://www.fh-zwickau.de/doc/prmo/pm...text/index.htm