Autor Thema: Kompatibilität zwischen 32Bit-OS und 64Bit-OS  (Gelesen 6352 mal)

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« am: 16. November 2010, 20:39 »
Hallo,


falls ihr ein OS entwickelt das unter 64Bit genau so laufen soll wie unter 32Bit (also mit fast identischer Code-Basis und äquivalenter Syscall-API), soll dann das 64Bit-OS auch die 32Bit-Programme ausführen können (wäre bei x86 ja eigentlich möglich) oder verlangt ihr das auch die Programme für 64Bit neu kompiliert werden müssen?

Für ein reines Open-Source-OS ist wohl die zweite Variante die bessere, weil ja wirklich alle Programme als Source-Code vorliegen, aber hat sich schon mal jemand Gedanken darüber gemacht was es bedeuten würde wenn ein unverändertes 32Bit-Programm unter dem 64Bit-OS laufen soll? Also was das OS alles tun muss damit ein 32Bit-Programm so läuft wie unter dem 32Bit-OS (ich meine damit jetzt nicht nur die CPU-spezifischen Sachen).


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

FlashBurn

  • Beiträge: 844
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 16. November 2010, 21:12 »
Zitat von: erik
aber hat sich schon mal jemand Gedanken darüber gemacht was es bedeuten würde wenn ein unverändertes 32Bit-Programm unter dem 64Bit-OS laufen soll? Also was das OS alles tun muss damit ein 32Bit-Programm so läuft wie unter dem 32Bit-OS (ich meine damit jetzt nicht nur die CPU-spezifischen Sachen).
Ein Problem würde ich bei den Syscalls sehen. Ich weiß jetzt zwar auch nicht wie man überhaupt aus nem 32bit Programm nen Syscall in nen 64bit Kernel macht, aber du müsstest halt zusehen, das die Größe der Parameter stimmt (einfach immer die oberen 32bit abschneiden geht nicht, weil es ja auch Syscalls mit 64bit Argumenten geben könnte).

Reden wir dann von einem MikroKernel hast du auch noch das Problem beim IPC (so fern du fixed-size hast, ansonsten bin ich mir nicht sicher) und vorallem bei den Services.
Geht es nur um die Services die das OS anbietet und die unter deiner (als Programmierer des OS) Kontrolle liegen könntest du es bestimmt hinbekommen das irgendwie zu regeln, aber wie willst du die Sache mit Services lösen die nicht du geschrieben hast?

Hauptproblem überall dürfte wohl sein das du unter nem 32bit OS als Standardwertebereich meistens 32bit nehmen wirst und bei nem 64bit OS halt 64bit und das hieße das du die Nachrichten von 32bit Programmen irgendwie übersetzen müsstest.

Im Endeffekt würde ich aus meiner Sicht sagen, lohnt sich alles nicht für ein HobbyOS. Dann lieber komplett 64bit ohne irgendwelchen Balast aus 32bit Welten.

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 17. November 2010, 10:11 »
Hallo,

die Syscalls müsstest du an sich doppelt in der API bereitstellen, einmal in 32- und einmal in 64-Bit-Fassung. Wenn du die Schnittstelle allerdings hinreichend neutral hältst, dürfte das nicht mehr Aufwand sein als ein neuer Funktionskopf. Für die 32-Bit-Anwendungen würdest du dann einen 32-Bit-Task erzeugen (keine Ahnung, ob/wie das im Long Mode geht).

Einmal setzt du damit natürlich voraus, dass das OS in beiden Varianten existiert (was für ein Hobby-OS den Aufwand enorm in die Höhe treibt), andererseits sehe ich ein Problem mit den Libraries: Die müssen in beiden Fassungen vorliegen.

Grundsätzlich könnte es sinnvoll sein (sehr vorsichtig), auf einem 64-Bit-OS native 32-Bit-Anwendungen anzubieten. Die meisten Anwendungen haben keine Vorteile von 64 Bit, wohl aber Nachteile (geringere Cache-Effizienz durch größere Zeiger usw.) - je nach Anwendung kann das enorm sein. Legt man das Gesamtsystem allerdings von vornherein so aus, dürfte der Aufwand sich in Grenzen halten.

Wobei ich sowas eher nicht machen würde.

Gruß,
Svenska

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 17. November 2010, 10:25 »
Wenn wir konkret über i386 und x86_64 reden, dann sind die zusätzlichen Allzweckregister aber sicher ein echter Vorteil, den Anwendungen haben.
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 #4 am: 17. November 2010, 13:27 »
Hallo,


Das mit den Syscalls ist natürlich ein Problem, z.B. IDs als Rückgabewert/Parameter müssten auf einen 32Bit-Wertebereich begrenzt werden (abschneiden geht ja nicht so einfach). Man könnte z.B. einen Layer für die 32Bit-Prozesse dazwischen ziehen der eine Umsetzung von den echten 64Bit-IDs des OS-Kernels auf einen eigenen/zusätzlichen 32Bit-Wertebereich vornimmt aber das erscheint mir ziemlich umständlich. Das 64Bit-OS auf 32Bit-IDs zu begrenzen ist IMHO auch ziemlich kaputt.
Ich hab zwar keine Ahnung wie Windows und Linux das machen aber ich glaube kaum dass das mit nur wenig Aufwand verbunden ist.

Ein Punkt bleibt aber, nämlich der das nur wenige Programme einen echten Nutzen aus den 64Bit ziehen. Natürlich bringt bei x86 bzw. x86-64 das mehr an Registern einen erheblichen Vorteil, der sicher einige Prozent mehr Performance bedeutet, aber diesen Vorteil gibt es bei meiner CPU nicht (es sind immer 64 Register) so das nur der größere Speicherbedarf übrig bleibt und ich eben doch mit gewissen Performanceverlusten (wegen Cache-Effizienz usw.) rechnen muss.
Grundsätzlich wäre ich also schon daran interessiert das mein 64Bit-OS auch 32Bit-Programme ausführen kann. Meine CPU-Architektur gibt das auch absolut problemlos her aber der Aufwand für das OS scheint doch recht hoch zu sein.

Die IPC-basierenden Services dürfte das nur marginal treffen da die eigentlichen Anfragen und Antworten ja im Speicher übergeben werden und dort kann ich das Layout nach eigenen Wünschen gestalten. Ich könnte z.B. bei read/write immer einen 64Bit-Wert für die Anzahl der Bytes deklarieren und damit ist die Sache erledigt.

Auf x86 geht man wohl manchmal den Mittelweg dass das Programm zwar ein echtes 64Bit-Programm (also auch entsprechende Rechenoperationen beherrscht) ist aber die Pointer nur 32Bit haben, aber auch hier sehe ich für meine Architektur das Problem das ja auch manche Syscalls Pointer in den Prozess bringen und da der OS-Kernel dann extra Rücksicht nehmen müsste.

Das man die Librarys mehrfach bräuchte sehe ich nicht so sehr als Problem (das kostet doch nur ein paar Bytes auf der HDD).


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

 

Einloggen