Thema: Speicher > 4GB

[ChristianF]

Hallo Leute,
mir ist da etwas unklar...
Wenn ich eine 32-Bit Maschine mit sagen wir mal 16GB Arbeitsspeicher habe, muss ich ja die Page Address Extension aktivieren, um alles nutzen zu können.
 
Was passiert allerdings, wenn ein Prozess mehr als 4GB Speicher benötigt (unwahrscheinlich aber möglich)? Der Adressraum von 4GB bleibt ja bestehen, muss ich dann einen solchen Prozess terminieren oder kann man hier über Umwege auch mehr als 4GB zur Verfügung stellen?
 
Gruß Christian

[MNemo]

4GB Adressraum sind für 32-Bit das Ende. Wenn ein Prozess dennoch mehr RAM benötigt, dann müsstest du ihm zumindest teilweise, dass Mapping überlassen. Aber das würde glaub ich kosten-/nutzen-Teschnich nicht in Frage kommen.

[erik.vikinger]

Hallo,

... muss ich ja die Page Address Extension aktivieren, um alles nutzen zu können.

Ja, die Paging-Tabellen sind dann auch anders aufgebaut.

Unter Windows ab 2000 (bei XP u.s.w. zumindest in den Professional-Versionen) gibt es dafür einen Mapping-Mechanismus der dem alten EMS-System, aus DOS-Zeiten (Friede seiner segmentierten Seele!), sehr ähnlich ist. Damit kann sich ein Programm Häppchen-Weise Speicher aus einem zusätzlichen Task-eigenem Pool (der selber größer als 4GB sein kann) in seinen linearen Adress-Raum einblenden lassen. Der IIS von M$ ist eines der wenigen Programme die das benutzen. Wo im physischen Adress-Raum diese Speicher-Seiten liegen ist komplett egal. In der c't gabs dazu mal einen Artikel.

Die 4GB-Grenze pro Task lässt sich damit jedenfalls nicht überwinden, so wie EMS damals die 640kBytes auch nicht wirklich vergrößern konnte. Diese spezielle Fähigkeit der x86-Architektur (mir ist nicht bekannt das sowas auch andere Architekturen bieten würden) ist IMHO nur dann interessant wenn man mehrere speicherintensive Programme gleichzeitig laufen lassen möchte und man dafür insgesamt mehr als 4 GB physischen Speicher ausschöpfen will, dazu muss man auch nicht die bestehenden 32Bit-Programme modifizieren.

Wenn man selbst ein OS entwickelt für das es noch keine riesige Menge vorhandener Programme gibt zu denen man weiterhin kompatibel sein muss sollte man besser gleich auf echte 64Bit setzen.


Grüße
Erik

[ChristianF]

Wenn man selbst ein OS entwickelt für das es noch keine riesige Menge vorhandener Programme gibt zu denen man weiterhin kompatibel sein muss sollte man besser gleich auf echte 64Bit setzen.

Nun ja, so gesehen gibt es noch kein einziges richtiges Programm für mein OS. Es fehlen ja auch noch essentielle Dinge im Kernel.
 
Allerdings wäre es eine Idee, die aktuelle Version des Kernels umzubasteln/neuzuschreiben und auf 64Bit zu setzen. Allerdings müsste ich das nochmals überdenken, da ich ja eigentlich mit 32Bit anfangen wollte.
Ich versuche erst einmal, meinen Kernel soweit umzustrukturieren, dass es leichter fällt, diesen später auf ein 64Bit System zu portieren. Da es ja auch auf 64Bit Prozessoren möglich sein sollte, 32Bit-Programme auszuführen...

[bluecode]

Da es ja auch auf 64Bit Prozessoren möglich sein sollte, 32Bit-Programme auszuführen...

Was aber wenig Sinn macht, wenn man es (wie bei einem Hobby/Open-Source-OS) auch gleich für 64bit kompilieren kann. Wenn man wie unter Windows externe Binärblobs unterstützen muss siehts halt anders aus.

[ChristianF]

Da es ja auch auf 64Bit Prozessoren möglich sein sollte, 32Bit-Programme auszuführen...

Was aber wenig Sinn macht, wenn man es (wie bei einem Hobby/Open-Source-OS) auch gleich für 64bit kompilieren kann. Wenn man wie unter Windows externe Binärblobs unterstützen muss siehts halt anders aus.

Es ist etwas Zeit vergangen...
 
Da ich mit meinem OS momentan nicht wirklich voran komme und durch einen Rewrite-Prozess nun schon etwas länger die ISRs und IRQs (PIC/APIC) einbauen muss, habe ich mir Gedanken gemacht, ob es überhaupt noch Zeitgemäß ist, für ein 32Bit System zu entwickeln...
 
Sollte ich besser gleich auf 64Bit setzen, oder gibt es irgendwelche Gründe, warum ich genau das nicht tun sollte?

[kevin]

Naja, seien wir doch mal ehrlich - wir entwickeln für uns selber. Wenn dein Rechner also ein 64-Bit-System ist, spricht nichts dagegen, es dafür zu entwickeln. Ich persönlich lasse Hobby-OS eher nicht auf meinem normalen Rechner laufen, sondern auf einem älteren Testrechner - das ist dann halt ein 586 und entsprechend schaue ich, dass mein Code mit einem 586 läuft.

[bluecode]

Also der Aufwand (was jetzt nur die Prozessorarchitektur betrifft) ist jetzt m.E. nicht wirklich viel mehr. Wenn es einen Grund gäbe nur 64bit zu unterstützen, dann wäre er m.E. eher, dass man einfach davon ausgehen kann (wenn man viel Lust hat testet man das dann sogar noch und gibt ne Fehlermeldung aus), dass zB LAPIC und I/O APIC vorhanden sind (was die Dinge mit den Timern einiges einfacher macht, da man damit schnell Single-Shots machen kann, was mit der PIC afaik nicht [schnell] möglich ist). Oder so Sachen wie ISA weglassen. Oder davon ausgehen, dass ACPI-Tabellen vorhanden sind (und zB SMP-Tabellen garnicht unterstützen). Oder Floppy weglassen, dann kann man sich ISA-DMA auch sparen (oder auch ISA allgemein). Oder einfach davon ausgehen, dass es einen PCI IDE Controller gibt. Oder PS/2 nichtmehr unterstützen und auf USB setzen (was Maus/Tastatur angeht).
Also imho lohnt sich dass dann nur, wenn man auch Geräte einfach nicht unterstützt, weil sie kaputt sind und es einfach nur Aufwand ist.