Wir haben einen Webbrowser gemacht. Folien habt ihr gesehen, die sind im Internet.
Da könnte man sie natürlich auch gleich von anzeigen. Ich werde auch ein paar Demos machen,
wie dann die einzelnen virtuellen Maschinen laufen. Insofern, da braucht man ein bisschen mehr.
Ich habe sie mal reingestellt, habe ich letztes Mal vergessen zu sagen. Das sind die vom letzten Jahr.
Im Wesentlichen ändert sich, glaube ich, hier unten. Ich habe auch schon zwei, drei Fehler gefixt.
Das war aber, glaube ich, von Folien, die später irgendwann kommen.
Ein kleines Kapitel wollte ich noch dazu fügen. Da kommt noch ein bisschen was.
Aber ihr könnt jetzt erst mal zum Nachlesen oder so auf jeden Fall die nehmen. Ich update die irgendwann noch.
Dann sind, glaube ich, auch alle wieder da. Moin moin, alleseits. Wo waren wir letztes Mal?
Letztes Mal hatten wir uns angeguckt, wie so eine, naja, das war so die erste wichtige Folie, sodass man praktisch alles in Schritten macht.
Ihr erinnert euch. Die CDU haben uns mal angeguckt, wenn die dann so einzeln ihre Instruktionen durchgeht.
Sie holt sie halt, sie führt sie aus. Und da waren so Geschichten dabei, wie hier, wir rufen eine,
naja, letztendlich ist eine Busfunktion, ein Buszyklus, der da durchgeführt wird.
Er holt sich was von außerhalb. Dann haben wir uns angeguckt, wie sieht so eine Load Funktion aus?
Der Load, die guckt nach, welche Adresse wird dann hier übergeben. Und je nach Adresse ruft er jetzt hier Romload, Ramload und so weiter auf.
Wie könnte man die simulieren? Also beispielsweise ein Romload, naja, simpelste Variante.
Ich definiere mir hier irgendwie ein R mit so und so viel Byte. Konstant, beiden Rom.
Na ja, wenn ich daraus lese, dann gebe ich einfach das Byte an der Stelle zurück.
Jo, gut, die Bausteine sind in echt normalerweise so gemacht, dass sie nur eine Anzahl von Pins haben, Adress Pins.
Sprich, die Adressen wiederholen sich. So ein typisches IBM PC.
IBM PC BIOS, früher mit seinen 64 Kilo Byte. Da war der Robben Baustein halt 64 Kilo Byte.
64 Kilo Byte heißt 16 Pins. Und wenn der 17. Pin eins ist, dann interessiert das den Robben Baustein nicht.
Also deshalb in diesem Sinne hier unten nochmal Modulo Größe des Bausteins. Dann kommt halt die Adresse eventuell mehrfach vor.
Ist auch in echt so. Jo, Rom schreiben, sinnigerweise passiert nichts, wenn es ein echtes Rom ist.
Man kann natürlich sich überlegen, ob man irgendein flashbares Rom nachmachen will von einem modernen Wasserbord.
Na gut, kann natürlich entsprechend auch in dieses Rom Ding, dieses RE was reinschreiben, dass ihr halt das Konst davor weg.
So ähnlich beim Ram. Na ja, das kennen wir jetzt gerade vom Rom Baustein. Ram Baustein kann man dann schreiben, entsprechend umgekehrt.
Jo, das ist jetzt noch relativ trivial. Worauf natürlich immer habe ich gesagt, achten müssen, sind so Geschichten.
Geht das allgemeingültig und vor allen Dingen ist das flott. Ist das flott? Geht das flotter?
Na ja, sich im Beid irgendwo aus dem Speicher zu holen. Weniger als ein RE Zugriff geht wohl nicht.
Die Modulo Geschichte müsste man nicht notwendigerweise machen, wobei man dazusagen muss, Ram size ist normalerweise eine Zweierpotenz.
Dann kann der Compiler das umbauen auf eine UND-Verknüpfung. Dann ist das auch geschenkt.
Das einzige, was man noch machen könnte, ist, dass es als Markov definiert wird.
Oder als Inlining, dass er das da gleich mit reinklebt. Das wäre eine Möglichkeit. Dann sparen wir nicht da einen Unterprogrammaufruf.
Der Unterprogrammaufruf ist wahrscheinlich mehr als das, was im Unterprogramm passiert.
Insofern wäre das vielleicht noch eine Idee.
Ja, gut, also ROM, RAM ist damit abgehandelt. Das geht blitzschnell.
Und wenn man das rein nach oben reinklebt, dann geschenkt.
Wir werden nachher noch sehen, im Prinzip kleben wir das da oben rein. Allerdings ein bisschen anders.
Ja, ein bisschen anders sieht das jetzt aus mit den I.O. Geschichten.
Weil da wird natürlich jetzt nichts gespeichert und wieder gelesen. Das ist trivial. Sondern es müssen ja irgendwelche Aktionen angestoßen werden.
Jetzt hier in unserem Beispiel, wiederum auch nicht so schwierig.
Also sagen wir mal, unsere serielle Schittstelle kann nur eins, nämlich bytes ausgeben.
Und wir schreiben so einfach auf die Konsole mit irgendeiner Programmiersprache, Print oder Printf oder wie auch immer das Ding dann heißt.
Das byte, was ausgegeben wird, schwupp, landet auf der Konsole. Fertig.
Eingabe ist da natürlich ein bisschen komplizierter.
Also wenn ich dann lese von einem seriellen Baustein, ja, dann kann es da möglicherweise zwei Ports geben oder zwei I.O. Register.
Nämlich irgendwie ein Ding, so eine Art, wie soll man sagen, wo ich den Puffer leer auslesen kann.
Wenn jemand eine Taste getippt hat auf dem Terminal, dann ist die Taste erstmal intern im Terminal drin.
Und wenn ich jetzt von Port 0 was auslese, dann ist der Key ab dann weg. Und ich kriege ihn.
Presenters
Zugänglich über
Offener Zugang
Dauer
01:36:47 Min
Aufnahmedatum
2012-10-25
Hochgeladen am
2019-05-05 21:19:03
Sprache
de-DE
Vorgestellt werden verschiedene Virtualisierungs-Ansätze:
-
Emulation
-
Just-In-Time-Compiler
-
Para-Virtualisierung
-
Bibliotheks-basierte Virtualisierung
-
OS-Virtualisierung
Lernziele und Kompetenzen:
Studierende, die das Modul erfolgreich abgeschlossen haben:
-
erläutern verschiedene Motivationen für den Einsatz von VMs
-
unterscheiden verschiedene VMs
-
klassifizieren verschiedene Ziele unterschiedlicher VMs (z.B. Performance, Konfigurierbarkeit, Genauigkeit, ...)
-
hinterfragen verschiedene Simulationansätze für MMUs
-
erstellen virtuelle Komponenten und Busse
-
strukturieren Callbacks und entsprechendes Forwarding und Caching
-
unterscheiden zwischen Architektur, Chip und Komponente
-
klassifizieren unterschiedliche Just-In-Time-Compiler-Ansätze
-
erzeugen JIT Code aus vorgefertigten Code-Teilen
-
bewerten unterschiedliche JIT-Code-Optimierungen
-
erläutern Probleme bei der JIT-Code-Invalidierung
-
nennen JIT Probleme mit Exceptions/Interrupts sowie berechnete Sprüngen und Return-Instruktionen
-
unterscheiden verschiedene JIT Cache-Verwaltungen
-
beschreiben Möglichkeiten der Fehlerinjektion durch VMs
-
entwickeln ein an JIT angepasstes virtuelles "Hardware"-Design
-
erläutern die Java-VM Instruktionssatz-Architektur
-
nutzen Hardware-basierte Virtualisierung
-
entwickeln Verfahren zum Ausfiltern bestimmter Befehle
-
erläutern Probleme der Speicherverwaltung bei HW-basierter Virtualisierung
-
nutzen User-Mode-Emulation zur Paravirtualisierung
-
diskutieren Möglichkeiten von Debuggern für die Umleitung von System-Calls und die Ausfilterung von Befehlen
-
nutzen einen Hypervisor zur Paravirtualisierung
-
unterscheiden verschiedene Ansätze zur Geräteverwaltung in paravirtualisierten Systemen
-
erläutern Betriebssystem-basierte Virtualisierung
-
entwickeln unterschiedliche Bibliotheks-basierte Virtualisierungen
-
erläutern Probleme beim Speicher-Layout bei Bibliotheks-basierte Virtualisierung
-
konzipieren Personalities für Bibliotheks-basierte Virtualisierungen
-
beurteilen Probleme bei der korrekten Zeit-Simulation
-
nennen Ideen für die dynamische Anpassung der Zeit-Simulation
-
klassifizieren bekannte VMs (z.B. VICE, FAUmachine, QEMU, Bochs, JVM, KVM, User-Mode-Linux, Xen, VServer, Wine)
-
diskutieren in der Gruppe Vor- und Nachteile von bestimmten VM-Ansätzen
-
untersuchen CPU-Emulationen
-
untersuchen Geräte-Emulationen