Speicheradressierung von 32 Bit CPU's

[Mrjoke]

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]

Original von Mrjoke
Hallo erstmal,
ich habe da eine Frage zur Speicheradressierung. Ein Normaler 32 Bit Prozessor kann maximal ca. 4GB RAM addressieren (2 ^ 32) .

Fast, er kann _GENAU_ 4GB addressieren.

Die Register der CPU sind aber nur 16 Bit gross.

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"

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.

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

Wie kann denn jetzt der Prozessor diese 4GB RAM ansprechen

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

wenn über die Segment : Offset-Darstellung nur (65535 * 16 +65535 = 1114095 Bytes) ca. 1 MByte addresiert werden können ???????

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]

Original von Mrjoke
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???

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*

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

Bahnhof?

Greets, Ziri

 

[Mrjoke]

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

Bahnhof?

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:

Original von 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.

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]

Original von 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.

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.

Du machst dir deine Vorstellung etwas zu einfach

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/pmtutor/text/index.htm