Konventioneller Speicher

Als Konventioneller Speicher werden die ersten 640 KiB (1 KiB = 1024 Byte) Arbeitsspeicher eines IBM-PC-kompatiblen Rechners bezeichnet.

Die 640-KiB-Grenze

Anfang der 1980er Jahre wurde beim Entwurf der Architektur des IBM-PCs ein Adressraum von 640 KiB für Arbeitsspeicher vorgesehen, da dies als ausreichend für den typischen Benutzer empfunden wurde – es war das Zehnfache des Adressraums der meisten anderen damals am Markt befindlichen Kleincomputer – und das erste PC-Modell, der IBM 5150, wurde anfänglich mit maximal 64 KiB (65536 Byte) tatsächlich installiertem Arbeitsspeicher ausgeliefert. Zudem erlaubte der eingesetzte Prozessor Intel 8088 nur einen maximalen Adressraum von 1024 KiB; die oberen 384 KiB wurden für ROM und Memory Mapped I/O reserviert, so dass 640 KiB Adressraum für den RAM-Arbeitsspeicher übrig blieben. Niemand rechnete damals damit, dass die IBM-PC-Architektur so lange Bestand haben würde, bis diese Grenze ausgeschöpft werden würde; waren doch die meisten anderen damaligen Rechnerarchitekturen nach wenigen Jahren wieder vom Markt verschwunden.

Die PC-Architektur überdauerte jedoch, und im Laufe der Zeit stellte sich diese Grenze immer mehr als Hindernis dar, da sie bestehen blieb, als die PCs mehr RAM besaßen. Mit dem Intel-80286-Prozessor des IBM AT von 1984 konnte im Protected Mode ein Adressraum von 16 MiB (1 MiB = 1024 KiB) angesprochen werden, die PC-Architektur musste jedoch die ursprüngliche Speicheraufteilung aus Kompatibilitätsgründen beibehalten. Somit war der RAM-Speicher an den Adressen A0000_hex bis FFFFF_hex nicht ohne Weiteres nutzbar, lag also bei frühen Chipsätzen für 80286 ungenutzt brach. Einige PC-Chipsätze wie bspw. der NEAT-Chipsatz unterstützten dafür ein so genanntes Remapping, das diesen Speicher an höhere Adressen einblendete. Wie der ganze Speicherbereich oberhalb der 1-MiB-Grenze war ein derart umgelagerter Speicher im Real Mode nicht nutzbar (mit Ausnahme der ersten 65520 Bytes, der so genannten High Memory Area). Ein Wechsel aus dem Real Mode in den Protected Mode veränderte das Verhalten der CPU aber so stark, dass keine Kompatibilität mehr gegeben war; das damals populäre Betriebssystem MS-DOS sowie seine Nachahmer und die darunter ausgeführten Anwendungen mussten deshalb weiterhin im Real Mode laufen. DOS bot jedoch spezielle Funktionen, um diesen Speicher zumindest als Datenspeicher anzusprechen (siehe XMS); dafür wurde der Prozessor vom Betriebssystem zeitweise in den Protected Mode geschaltet und dann ein Datenblock aus dem konventionellen Speicher in den Bereich über 1 MiB kopiert oder umgekehrt, danach folgte eine Rückschaltung in den Real Mode. Real-Mode-Programmcode konnte im XMS-Speicher somit zwischengelagert, jedoch nicht direkt dort ausgeführt werden. Eine andere Variante war, den Speicher in maximal 64 KiB großen Blöcken per Expanded Memory Specification (EMS) wieder in den UMB Bereich einzublenden, so dass Real Mode Programme darauf wieder zugreifen konnten.

Ab dem 386er-Prozessor existierte ein dritter Betriebsmodus, der Virtual 8086 Mode, der es gestattete, über die virtuelle Speicherverwaltung des Protected Mode die von der PC-Architektur vorgegebene Aufteilung des physischen Adressraums zu überwinden und den gesamten 1-MiB-Adressraum, der von DOS aus sichtbar war, auf physisch vorhandenes RAM abzubilden, wobei aber im Gegensatz zum normalen Protected Mode die Kompatibilität zum Real Mode gewahrt blieb. Somit konnten diejenigen Teile des Bereichs zwischen der 640-KiB-Grenze und der 1-MiB-Grenze, die nicht für die Adressierung von Hardware benötigt wurden, für Programm- und Datenspeicher genutzt werden. In MS-DOS gab es hierfür wieder eigene Speicherverwaltungsfunktionen (siehe Upper Memory Block). Da normale DOS-Programme hiervon jedoch nur selten Gebrauch machten, wurde dieser Bereich vorwiegend vom DOS-Kernel selbst und von ladbaren Gerätetreibern genutzt. Diese belegten somit nicht mehr den knappen und somit kostbaren Speicherbereich unterhalb der 640-KiB-Grenze, so dass dort mehr für die Anwendungsprogramme frei blieb.

Speicheroptimierung

Die für Systemzwecke reservierten oberen 384 KiB des Adressraums der 8086er-CPU erwiesen sich, anders als die 640 KiB für Anwenderprogramme, als überdimensioniert; sie wurden kaum jemals komplett ausgenutzt, meist blieben davon zwischen 128 und 256 KiB frei. In dieser Ausgangslage entwickelte sich die Idee, den unbenutzten Teil der 384 KiB zum Beispiel für Gerätetreiber zu verwenden, was ab 1990 mit der Veröffentlichung von MS-DOS 5.0 möglich wurde.

Indem Gerätetreiber oder TSR-Programme in diesen sogenannten Upper Memory Block geladen werden (oder, wenn unnötig, ganz aus dem Speicher entfernt), steht durch diese Treiber/Programme benötigter Speicherplatz wieder als konventioneller Speicher zur Verfügung, d. h. von den 640 KiB bleibt mehr Speicher für Anwendungsprogramme übrig. Zur Vereinfachung können Batchdateien oder Bootdisketten erstellt werden, die die benötigten Treiber und Einstellungen beinhalten. Die benötigten Angaben dazu befanden sich in den (Spiele-)Dokumentationen. In späten Versionen von MS-DOS wurde ein Tool namens MemMaker (RamBoost in PC DOS) mitgeliefert, das diese Optimierung teilweise automatisieren konnte.

DOS Protected Mode Interface

Mit Hilfe von so genannten DOS-Extendern kann die 640-KiB-Speichergrenze umgangen werden. Eines der ersten Computerspiele, das diese Technik verwendet hat, war Doom von id Software.

Situation bei 32/64-Bit-Betriebssystemen

Windows 9x bootet nur, wenn genügend konventioneller Speicher frei ist, danach spielt der konventionelle Speicher (außer wenn DOS-Anwendungen gestartet werden) keine Rolle mehr. Bei modernen 32/64-Bit-Betriebssystemen, wie beispielsweise Microsoft Windows NT basierenden Betriebssystemen, hat die 640-KiB-Speichergrenze für Anwendungen keine Bedeutung mehr, da der Speicherzugriff grundsätzlich im Protected Mode erfolgt. Zwar findet sich auf der untersten Ebene der physischen Adressen bis heute ein „Loch“ im Speicherbereich zwischen 640 KiB und 1024 KiB, diese Tatsache muss aber nur noch Bootloader- und Betriebssystem-Programmierern bewusst sein, da sie für Anwendungsprogramme unsichtbar ist. Allerdings können diese 384 KiB Arbeitsspeicher nicht genutzt werden, was aber bei modernen Rechnern vernachlässigbar ist.

Siehe auch