mikrocontroller.net

Forum: PC Hard- und Software Threads / Prozesse / Multitasking in Assembler


Autor: Manuel S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey,
mich interessiert, wie ein Betriebssystem eigentlich Multitasking 
realisiert?

Auf unterster Ebene liegt ja das ganze OS in Assembler / 
Maschinensprache vor. Aber wie bildet ein OS zB einen Thread in 
Assembler ab? Wie arbeitet ein Scheduler auf diesem Level, immer hin und 
her jumpen zwischen den Codeblöcken? Kann man das ganz anschaulich 
erklären?

Und wenn es ein Multicore-Prozessor ist: wie funktioniert dann die 
Verteilung auf die Prozessoren? Gibt es da spezielle Befehle?

Wäre auch über einen Tipp froh, wo solche Dinge ausführlich erklärt 
werden.

Mir bringt es auch nichts, C-Code anzuschauen, da ich ja dann trotzdem 
nicht weiß, was der Compiler daraus macht, oder?

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andrew S. Tanenbaum: Operating Systems

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
auch ein BS ist nicht in assembler geschrieben. Es gibt nur ganz wenig 
code der wirklich in ASM geschrieben werdem muss. Schau doch einfach mal 
in die Quellen von Linux rein, eventuell erkennt man dort etwas.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Lernen ist Minix da aber deutlich übersichtlicher,
deshalb mein Tip mit Tanenbaum.

Autor: Manuel S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, aber der Compiler übersetzt es ja in Maschinencode. Und die einzige 
Schnittstelle mit der CPU ist ja der Befehlssatz. Nur frage ich mich, 
wie zB die Zuteilung auf mehrere Kerne funktioniert, da es ja 
anscheinend keine Befehle für sowas gibt. Aber das OS kann das.

Aber das Buch werde ich mir mal zulegen.

Autor: mkeller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Tipp mit Tanenbaum ist doch richtig. Du brauchst erstmal ein 
grundlegends Verständniss, wie ein OS aufgebaut ist.
Denn du stellst die falschen Fragen.

Autor: Mega Nilp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vergiss den MultiKernprozessor zum Beginnen. Der kommt spaeter.

Autor: Nils S. (kruemeltee) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Vergiss den MultiKernprozessor zum Beginnen. Der kommt spaeter.
Hat er danach gefragt?

Ich glaube er sucht das "x86 instruction set".

Grundlegendes Multitasking ist hier mit C-Code in ein paar kB erklärt:
http://www.jamesmolloy.co.uk/tutorial_html/index.html

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manuel S. schrieb:
> Mir bringt es auch nichts, C-Code anzuschauen, da ich ja dann trotzdem
> nicht weiß, was der Compiler daraus macht, oder?

Was hat denn die Funktionsweise eines Schedulers damit zu tun, was der 
Compiler aus dem C-Code macht?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manuel S. schrieb:

> Mir bringt es auch nichts, C-Code anzuschauen, da ich ja dann trotzdem
> nicht weiß, was der Compiler daraus macht, oder?

Es gibt exakt eine Stelle, wo man mit C Code allein meistens nicht 
weiter kommt, und dass ist die Mechanik der 
Task/Thread/Prozess/Wiedimmerduesnennst-Umschaltung. Da sich das 
passenderweise meistens mit Interrupts verbindet findet man dies oft im 
erweiterten Prolog/Epilog-Code von Interrupt-Handlern solcher 
Betriebssysteme.

Alles Übrige lässt sich bequem in C studieren. Wenn du aber trotzdem 
Assembler bevorzugst, dann kannst du die Verfahren anhand des recht 
kleinen RTOS-Kernels AvrX studieren - der ist 100% Assembler.

Ohnehin: Während komplette Betriebssysteme natürlich sehr viel mehr 
machen, was die Prozessverwaltung angeht, kann man die grundlegenden 
Mechanismen wohl einfacher anhand eines RTOS studieren, als an 
vollständigen Betriebssystemen, bei denen man den Wald vor lauter Bäumen 
nicht finden. Multicore-Verwaltung wird man darin nicht finden, aber dem 
sollte man sich erst widmen, wenn man die RTOS-Mechanik verstanden hat, 
Synchronierungsmechanismen inklusive.

Autor: Murkser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bevor Du Dir Assembly oder C Code anschaust, fang besser mal an, die 
grundlegenden Konzepte zu verstehen. Da ist das Buch von Tanenbaum (oder 
auch das von Silberschatz/Galvin) sehr hilfreich. Danach kannst Du Dir 
die Umsetzung der Konzepte in C und die prozessorspezifischen Details in 
Assembly anschauen. Gleich dort unten anzufangen ist so als ob Du 
versucht ein Verständnis der Anatomie des Elefanten mithilfe eines 
Elektronenmikroskops zu erlangen... ;-)

   Murkser

Autor: Manuel S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, ich weiß überhaupt nicht wo ich anfangen soll. Ich bin ja "nur" 
Mathe-Student mit NF Info, aber ich möchte dennoch mehr von Computern 
verstehen als nur Algorithmen, Rechenmodelle und Komplexitätsanalyse 
(mehr machen wir leider nicht im Studium). Und mit Wikipedia kommt man 
auch nicht wirklich weiter, um es richtig zu verstehen.

Vielleicht sollte ich erstmal mit einem Buch über Rechnerarchitektur 
anfangen, oder? Hat jemand eine Empfehlung?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du also bei Null anfängst, dann solltest du allen realen Code 
komplett ignorieren und dich an die gängigen Lehrbücher halten. Dazu 
sind die da. Der Tanenbaum wurde ja bereits genannt.

Bei Rechnerarchitektur wäre das beispielsweise: Hennessy/Patterson, 
Computer Architecture: A Quantitative Approach.

Und da es für einen Überblick nicht darauf ankommt, den allerneuesten 
Stand zu kennen, kannst du dich dabei ggf. auch geldsparend auf dem 
Gebrauchtmarkt der vorherigen Ausgabe umsehen, denn in der jeweils 
aktuellen Ausgabe reissen die ein ziemliches Loch in die Kasse.

Alternativ sollte sich sowas wohl auch in der Bibliothek finden.

Autor: Jürgen W. (lovos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe ein paar Monate mit FreeRTOS auf einem AVR32 gearbeitet. Da 
habe ich einen Einblick in die Task-Verwaltung bekommen.
Vermutlich ist das anders als bei einem PC, aber ich bekam zumindestens 
ein Grundverständnis.
Es war in C, aber Assembler bringt keine Vorteile. Wenn auf dem Stack 
Rücksprungadressen verändert werden, dann ist es egal ob in C oder Asm.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dabei fällt mir ein, daß es in der c't mal vor etlichen
Jahren eine Reihe mit mehreren Folgen gab über RTOS+Pearl
auf 68000.

Das war auch recht gut mit Grundlagen erklärt und Beispielen.
Leider halt nicht mehr ganz aktuelle HW.

Bei Bedarf könnte ich die Artikel rauskramen.

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo wenn man Hennesy + Tanenbaum durchgearbeitet und verstanden hat 
reicht das erstmal um jede Computerdiskussion zu gewinnen und als 
Klugscheißer im Freundeskreis zu gelten :D Ne im Ernst das sind wohl die 
Standardwerke wenn man Verständnis für den Bereich 
Rechnerarchitektur/Betriebssysteme erlangen will.

Autor: Nils S. (kruemeltee) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hmm, ich weiß überhaupt nicht wo ich anfangen soll. Ich bin ja "nur"
>Mathe-Student mit NF Info, aber ich möchte dennoch mehr von Computern
>verstehen als nur Algorithmen, Rechenmodelle und Komplexitätsanalyse
>(mehr machen wir leider nicht im Studium). Und mit Wikipedia kommt man
>auch nicht wirklich weiter, um es richtig zu verstehen.

>Vielleicht sollte ich erstmal mit einem Buch über Rechnerarchitektur
>anfangen, oder? Hat jemand eine Empfehlung?

Wenn du meinen Link nicht liest, kann dir keiner helfen, dort ist alles 
wichtige zum grundlegendensten Multitasking erklärt.

Ich beschäftige mich seit über 5 Jahren mit direkter x86 ASM und C 
Programmierung und auf der Seite hab ich in drei Tagen mehr gelernt, als 
das halbe Jahr davor.

Autor: Nils S. (kruemeltee) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch was vergessen....

>Es gibt exakt eine Stelle, wo man mit C Code allein meistens nicht
>weiter kommt, und dass ist die Mechanik der
>Task/Thread/Prozess/Wiedimmerduesnennst-Umschaltung.

Nicht unbedingt.

Das ist vor von der einen Architektur zur Anderen verschieden. Auf x86 
brauchst du z.B. auch assembler und die Descriptor Tables zu laden (idt, 
gdt).
Im Code für paging findet man sehr oft Assemblercode, allerdings braucht 
man das nicht unbedingt, jenachdem was man machen will (siehe zum 
Beispiel http://www.jamesmolloy.co.uk/tutorial_html/6.-Paging.html ).


Das umschalten zwischen den Tasks ist tricky. Das größte Problem ist, 
dass dafür sehr schnell (wäre von Vorteil) zwischen verschiedenen 
Speicherbereichen hin und her gehüpft werden muss.

Das schlimmste daran ist, meiner Meinung nach, die Stack-Kacke.... Pro 
Task einen, jedesmal save/restore, manipulieren dass abglegte Adressen 
gefunden werden, ..., ...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nils S. schrieb:

> Das ist vor von der einen Architektur zur Anderen verschieden. Auf x86
> brauchst du z.B. auch assembler und die Descriptor Tables zu laden (idt,
> gdt).

x86 sind ein eigene Liga. Was diese Architektur alles an historischem 
Ballast mit sich rumschleppt, dass will man nicht garnicht wirklich 
wissen, jedenfalls nicht am Anfang.

> Das umschalten zwischen den Tasks ist tricky.

Bei simplen Architekturen wie ARMs nicht. Bei x86 schon eher, aber bei 
diesen barocken Kolossen ist mittlerweile nichts mehr einfach.

> Das größte Problem ist,
> dass dafür sehr schnell (wäre von Vorteil) zwischen verschiedenen
> Speicherbereichen hin und her gehüpft werden muss.

Es ist eher die Umschaltung der Speicherverwaltung (MMU), die ziemlich 
auf die Performance geht. Weshalb die Hersteller der Oberklasse sich 
Mühe geben, mit dieser Umschaltung nicht wie sonst üblich alles 
wegzuwerfen. Aber davon sieht man im Idealfall wenig bis nichts.

> Das schlimmste daran ist, meiner Meinung nach, die Stack-Kacke....

???

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> x86 sind ein eigene Liga. Was diese Architektur alles an historischem
> Ballast mit sich rumschleppt, dass will man nicht garnicht wirklich
> wissen, jedenfalls nicht am Anfang.

Wobei einige Dinge durchaus ihre Eleganz haben, auch wenn sie sich 
teilweise in der Praxis nicht bewährt haben. Ein Beispiel sind die Task 
State Segments (TSS), die eigentlich die Möglichkeit bieten, dass der 
Prozessor selbst weiss, welcher Kontext wie zu sichern ist, und den 
Taskswitch weitgehend eigenständig erledigt. In der Praxis werden TSS 
von gängigen x86-Betriebssystemen aber nur rudimentär benutzt (war 
früher (Linux vor 1.3, Windows 3.1) mal anders, es stellte sich aber 
wohl heraus, dass Software-Kontextswitching letztlich schneller und 
flexibler ist), und in der Folge werden sie bei x86-64 im 64bit-Modus 
auch nicht mehr voll unterstützt.

> Es ist eher die Umschaltung der Speicherverwaltung (MMU), die ziemlich
> auf die Performance geht.

Was übrigens auch mit einer der Gründe ist (neben der Vereinfachung der 
Datenübertragung zwischen Kernel- und Userspace), warum Betriebssysteme 
den Kerneladressraum mit in den Userspace-Adressraum einblenden (z.B. 
Linux auf x86 oberhalb von 3GB).

Ohne die Einblendung müsste der MMU-Kontext nicht nur bei 
Prozesswechseln, sondern auch bei jedem Systemcall oder Interrupt 
mehrfach gewechselt werden, mit den damit verbundenen Kosten aufgrund 
des TLB-Flushes.

> Weshalb die Hersteller der Oberklasse sich
> Mühe geben, mit dieser Umschaltung nicht wie sonst üblich alles
> wegzuwerfen. Aber davon sieht man im Idealfall wenig bis nichts.

Und auch moderne Betriebssysteme bemühen sich, TLB-Einträge für die 
immer gleichen Teile des Adressraumes (Kernelspace) nicht jedesmal mit 
zu invalidieren.

Nils S. schrieb:
> Das schlimmste daran ist, meiner Meinung nach, die Stack-Kacke....

Das ist doch das eleganteste überhaupt am Kontextwechsel. Durch Umsetzen 
nur eines einzelnen Pointers wird der komplette dynamische State 
(Call-History, lokale Variablen etc.) zwischen zwei Ausführungssträngen 
umgeschaltet (wenn wir mal von einem gemeinsamen Adressraum ausgehen).

Andreas

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Ferber schrieb:

> früher (Linux vor 1.3, Windows 3.1) mal anders, es stellte sich aber
> wohl heraus, dass Software-Kontextswitching letztlich schneller und
> flexibler ist), und in der Folge werden sie bei x86-64 im 64bit-Modus
> auch nicht mehr voll unterstützt.

Yep. Das ist sowas wie die Eleganz des eigentlich vorgesehenen Befehls 
für den Prozeduraufruf bei der VAX, den auch nur jene verwendet haben, 
die keine Zyklen zählen konnten. ;-)

> Was übrigens auch mit einer der Gründe ist (neben der Vereinfachung der
> Datenübertragung zwischen Kernel- und Userspace), warum Betriebssysteme
> den Kerneladressraum mit in den Userspace-Adressraum einblenden (z.B.
> Linux auf x86 oberhalb von 3GB).

Und was wohl auch einer der Gründe ist, weshalb IBMs Power Architektur 
dem 32-Bit Adressraum eine Segmentierung verpasste, die sogar den 
Transit zur 64-Bit Architektur überlebt hat. Weil im so entstehenden 
Gesamtadressraum alle Prozesse sowie Kernel Platz finden, ohne dass dies 
auf Prozessebene sichtbar ist.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.