Autor Thema: Architektur im OS-Design  (Gelesen 12996 mal)

BadBeu

  • Beiträge: 28
    • Profil anzeigen
    • http://www.BadBeu.net
Gespeichert
« am: 29. June 2006, 10:30 »
Hallo,

da ich relativ neu in dieser Materie bin ist es möglich, dass meine Frage vielleicht etwas banal ist.

Ich habe mir den Tanenbaum (Operating Systems) gekauft und fast durchgelesen. Nun bin ich parallel angefangen das IA-32 Manual vol. 3 (System Programming) zu lesen.
Da Tanenbaum versucht alles auf einer sehr abstrakten Art und Weise darzustellen und das Intel Manual natürlich sehr spezifisch ist, stellt sich mir nun eine Frage:

Sollte man die Prozessor-Architektur in ein grundlegendes OS-Design (nicht Implementation - die ist selbstverständlich architektur-spezifisch) mit einbeziehen oder - z.B. auf Grund von Komptibilität - aussen vor lassen.

Es ist ja so, dass die IA-32 einige Features besitzen, die z.B. Task-Wechsel vereinfachen oder Paging unterstüzen. Dies könnte ja auf anderen Platformen vielleicht nicht der Fall sein und man müsste dies per Software emulieren oder komplett weglassen, was sich natürlich auf Performance und Aufbau des OS auswirkt.
Sachen, die man beim Design berücksichtigen sollte.

Ich hoffe, ich habe meine Frage klar formuliert und hoffe auf baldige Antworten.

Mit freundlichen Grüßen

    Michael Beuse

maumo

  • Beiträge: 182
    • Profil anzeigen
    • http://maumo.50webs.com/
Gespeichert
« Antwort #1 am: 29. June 2006, 14:11 »
also es kommt natürlich ganz drauf an, was für ein projekt das werden soll: in einem kleinem hobby os, das nur auf dem heimrechner zum angeben/lernen laufen soll, ist es sinnvoll die cpu auszunutzen, da das projekt dadurch an vielen schwierigkeiten verliert und vl sogar fertig werden kann. in einem system, das es wirklich mit den heutigen aufnehmen soll, sollte sich nicht auf die cpu spezialisieren, denke ich, aber diese frage musst du dir selbst beantworten: was ist dir wichtiger? schnelligkeit? kompatibilität? ist es wirklich wichtig, das das system auch auf der XBox laufen könnte? oder ist das - so denke ich - einfach nur rumgespiele?

maumo

DarkThing

  • Beiträge: 652
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 29. June 2006, 15:00 »
Ich würde an deiner Stelle so gut wie es geht zwischen den abstrakten Sachen wie Scheduling-Algorithmus usw. und den wirklich platformabhängigen Sachen (z.B. dem eigentlichen Task-Wechsel) trennen. Es ist ja möglich dass du irgendwann eine AMD64 CPU hast und dein OS so anpassen willst, dass es die 64bit Features unterstützt. Wenn du dann vorher getrennt hast, ist es relativ einfach die Sachen ruszusuchen, die man ändern muss.

EDIT: Also prinzipiell würde ich die CPU Features benutzen, aber halt z.B. in seperate Dateien packen.

BadBeu

  • Beiträge: 28
    • Profil anzeigen
    • http://www.BadBeu.net
Gespeichert
« Antwort #3 am: 29. June 2006, 15:10 »
Danke für die schnellen Antworten.

Dann muss ich also genau darauf achten, dass ich eine passende Trennung zwischen Hardwareabhängigkeit und Abstraktion finde.

Also mein OS sollte schon auf meheren Rechnern laufen. Zumindest auf meinem Laptop und meinem Desktop - also einmal Intel Core Duo und einmal AMD64.

Ich werd mal dann wieder das Intel Manual weltzen.

scales of justice

  • Beiträge: 228
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 29. June 2006, 15:25 »
genauso mach ich das auch, für jedes System mach ich unterschiedliche Programme, die aber alle die gleichen Includes benutzen,
so lässt sich z.B. meine Grafikengine mit kleinen Änderungen unter Windows, Linux, aber auch mit meinem eigenen OS verwenden

is halt immer die Frage wie weit das geht, ein 32-Bit Programm könnte auf einem 64-Bit Rechner natürlich eigentlich einiges schneller laufen, wenn es denn nun für 64-Bit entwickelt worden wäre

mit C code geht das relativ einfach, sagt man dem er solls für nen 64-Bit Rechner statt 32-bit compilieren, macht er das auch,
aber Assemblercode müsste man wohl zum optimieren größtenteils komplett neu schreiben

für teile die komtapibel sein sollen nehm ich deswegen normalerweise C, mit Assembler, der Assembler Teil ist aber voll mit Preprocessor anweisungen, die alles anpassen

DarkThing

  • Beiträge: 652
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 29. June 2006, 15:31 »
Ein normales Protected Mode OS sollte auf beiden Computern laufen, weil der AMD64 ja abwärtskompatibel ist. Aber AMD64 hat z.B. kein Hardware-Multitasking mehr. Wenn du stattdessen Software-Multitasking verwendest, wird das richtige portieren eigentlich relativ einfach.

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #6 am: 29. June 2006, 15:44 »
Zitat von: DarkThing
Ein normales Protected Mode OS sollte auf beiden Computern laufen, weil der AMD64 ja abwärtskompatibel ist. Aber AMD64 hat z.B. kein Hardware-Multitasking mehr. Wenn du stattdessen Software-Multitasking verwendest, wird das richtige portieren eigentlich relativ einfach.
Wie? Ein AMD64 kann im PM kein Hardwaremultitasking mehr? Also er kann nicht mehr mit einem jmp auf ein TSS springen? Echt? Woher weißt du das?

bitmaster
In the Future everyone will need OS-64!!!

BadBeu

  • Beiträge: 28
    • Profil anzeigen
    • http://www.BadBeu.net
Gespeichert
« Antwort #7 am: 29. June 2006, 16:51 »
Ja. Aber ich möchte natürlich die vollen Kapazitäten des Prozessors ausnutzen.
Also in etwa so, dass ich mit meinem Intel auch dessen Hardware-Multitasking nutzen kann. (Ich denke mal, dass das dann schneller läuft als Software-Multitasking, sonst würden ja viele Ressourcen der CPU ja einfach in nutzlose Features verschwendet)
Wenn ich jetzt auf eine andere Architektur ohne Hardware-Multitasking portieren will muss ich natürlich den ganzen Code gegen anderen austauschen oder eben für diese Architektur anpassen (ob AMD64 Hardware-Multitasking unterstützt oder nicht sei mal dahingestellt - müsste ich auch nachlesen)
Ich möchte ja ein Betriebssystem haben, das das letzte bischen Leistung herauskitzelt und nicht instruction cycles verschwendet auf schon implementierte Features.
Ist natürlich mehr Aufwand, aber ich möchte ja ein spezialisiertes OS.
Aber halt modular, so dass ich manche Sachen austauschen kann, wenn ich es auf einem anderen System laufen lassen möchte.

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #8 am: 29. June 2006, 17:25 »
Ich hab zwar nicht die AMD Manuals gelesen, habe es aber schon immer wieder bei mega-tokyo gehört. Mal abgesehen davon ist hardware-multitasking auch langsamer als software-multitasking ;)

@BadBeu: Das letzte bisschen Leistung wirst weder _du_ noch _ich_ noch irgendwer in diesem Forum herauskitzeln ;)
@topic: Ich würde auch zwischen hardware-spezifischem und den High-level-Konzepten trennen.
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

BadBeu

  • Beiträge: 28
    • Profil anzeigen
    • http://www.BadBeu.net
Gespeichert
« Antwort #9 am: 29. June 2006, 17:39 »
Ja. Es ist mir schon klar, dass das nicht geht.
Aber man kann es ja zumindest versuchen. Es ist ja immer ein gutes Zeichen, seine Ziele höher zu stecken, als das man sie erreichen kann. (So bleibt halt der Ergeiz erhalten)
Nun aber zu Hardware-Multitasking:
Warum Die-Platz auf sowas verschwenden, wenn es nicht genutzt bzw. langsam ist? Ist das ein geerbtes Kompatibilitätsproblem?
Im Intel Manual wird das ja ziemlich ausführlich erklärt. (naja - muss ja auch - es erzählt ja auch ne Menge über Real Mode)

Wäre nett, wenn mich da wer aufklären könnte, warum das so ist.
Normalerweise ist hardware-seitige Unterstützung ja besser bzw. schneller als Software (bzw. Emulation)

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #10 am: 29. June 2006, 17:50 »
Zitat von: BadBeu
Warum Die-Platz auf sowas verschwenden, wenn es nicht genutzt bzw. langsam ist? Ist das ein geerbtes Kompatibilitätsproblem?

Jo es ist einfach wegen der Abwärtskompatibilität vorhanden, wird aber afaik von keinem Betriebssystemkernel mehr verwendet, da dabei viele unnötige Register gespeichert werden (zB Alle Segmentregister [in den meisten Kerneln werden nur noch ein Code/Datensegment für Kernel- und eins für Usermode erstellt]). Man kann hier mehr lesen, wobei der Test in dem Artikel von OSNews aussagt, dass der Gewinn bei sw-multitasking minimal ist.
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

Osbios

  • Beiträge: 247
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 29. June 2006, 19:43 »
Zitat von: bitmaster
Wie? Ein AMD64 kann im PM kein Hardwaremultitasking mehr? Also er kann nicht mehr mit einem jmp auf ein TSS springen? Echt? Woher weißt du das?


Im PM kann auch ein 64 Bittiger HT benutzen, allerdings nicht im nativen 64 Bit Modus (Long Modus bzw. LM).
db 0x55AA

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #12 am: 29. June 2006, 20:14 »
Zitat
Im PM kann auch ein 64 Bittiger HT benutzen
Was meinst du? Bitte in deutsch? ^^ Kapier ich irgendwie net.

danke!!!
In the Future everyone will need OS-64!!!

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #13 am: 29. June 2006, 20:23 »
Im Protected Mode beherrscht ein Advanced Micro Devices Vierundsechzig Hardwaremultitasking.
Dieser Text wird unter jedem Beitrag angezeigt.

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #14 am: 29. June 2006, 20:30 »
Zitat von: PorkChicken
Im Protected Mode beherrscht ein Advanced Micro Devices Vierundsechzig Hardwaremultitasking.
Aso, steige aber trozdem besser auf Softwaremultitsaing um. Dann habe ich den Umstiegt von 32 Bit zu 64 Bit später einfacher.

bitmaster
In the Future everyone will need OS-64!!!

Osbios

  • Beiträge: 247
    • Profil anzeigen
Gespeichert
« Antwort #15 am: 29. June 2006, 21:58 »
-__________-



Also: Ein 64 Bit x86 Prozessor verhält sich im Protectemode genauso wie ein 32Bit Prozessor im Protectemode.
64 Bit Prozessoren haben jedoch einen weiteren Betriebsmodus, den Longmode. Im Longmode wurden jedoch nicht alle _Features_ des Protectemode übernommen, z.B. Hardware Tasking.
db 0x55AA

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #16 am: 29. June 2006, 22:00 »
@osbios: ach ne, wer hat was anderes behauptet? :roll:
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #17 am: 30. June 2006, 00:05 »
Zitat von: bluecode
@osbios: ach ne, wer hat was anderes behauptet? :roll:


Also klar war es nun wirklich nicht, deshalb war es vollkommen richtig es explizit nochmal zu sagen.

Also, schalte in den Long Mode, nutze damit die speziellen 64 Bit Fähigkeiten des AMD64, aber verzichte dann auf hardware task switching, weil es dann weg ist ...
*post*

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #18 am: 30. June 2006, 00:33 »
nun gut, vllt war auch nur mir klar, dass wenn ich schon von AMD64 spreche, dass ich dann auch implizit longmode meine :)
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #19 am: 30. June 2006, 01:03 »
Zitat von: bluecode
nun gut, vllt war auch nur mir klar, dass wenn ich schon von AMD64 spreche, dass ich dann auch implizit longmode meine :)
Ja, und damit hast du mich verwirrt. Aber ich steige wie gesagt trozdem auf Softwaremultitasking um. Dann ist das portieren auf 64 Bit nacher einfacher. ^^

bitmaster
In the Future everyone will need OS-64!!!

 

Einloggen