Simulationsprogramm Zur Visualisierung Der Vorgänge in Einem Computer

Simulationsprogramm zur Visualisierung der Vorgänge in einem Computer

Masterarbeit zur Erlangung des

Master of Advanced Studies ZFH in
Informatik

vorgelegt von

Christian Kaegi

geboren am 05.01.1969 von Bauma, Kanton Zürich

eingereicht

Dipl. Ing. Walter Eich

Stetten, 28.8.2015

ZHAW - Masterarbeit - Christian Kaegi - 28.8.2015 - v2.0.3

Inhaltsverzeichnis

1. Zusammenfassung

9

2. Einleitung

11

11 12 12 12 12
2.1 Ausgangslage 2.2 Motivation 2.3 Fragestellungen 2.4 Abgrenzung 2.5 Zielsetzung

3. Von der abstrakten Theorie zur erleb- und fassbaren Simulation

3.1 Problemanalyse

13

13 13 14 15 15 16 17 18 19 19 20 21 22 22 23 24 25 26 26 27 30 32 36 36
3.1.1 Definition der Zielgruppe 3.1.2 Personas 3.1.3 Beispiele von existierenden Lösungen und Lösungsansätzen
3.1.3.1 Little Man Computer 3.1.3.2 Der Bonsai-Modellrechner 3.1.3.3 Der Murmelrechner 3.1.3.4 Paper Processor 3.1.3.5 WDR-1-Bit-Computer 3.1.3.6 Ein 8-Bit Computer Marke Eigenbau 3.1.3.7 Ein einfacher 4-Bit Computer für den Klassenraum 3.1.3.8 Visuelle Simulation einer 6502 CPU auf Transistorebene 3.1.3.9 Simulationen mit Logisim 3.1.3.10 Weitere Simulationsprogramme
3.1.4 Fazit
3.2 Lösungsansatz 3.3 Die Komponenten
3.3.1 Befehls-, Daten- und Adressbus 3.3.2 Logikgatter 3.3.3 Speicher 3.3.4 Auswahlschaltungen 3.3.5 Arithmetik 3.3.6 Taktgeber
3.4 Simulation in Logisim bauen

3.4.1 Befehlssatz

38

40 41
3.4.1.1 Erläuterung der Befehle 3.4.1.2 Zeichencode
3.5 Anforderungen an das Simulationsprogramm 3.6 Technologie-Evaluation
3.6.1 Zielplattform
43 44 44 44 44 45 46 46 47 48 49
3.6.2 Java 3.6.3 Actionscript 3.6.4 Javascript/HTML 3.6.5 Dart 3.6.6 Haxe 3.6.7 Entscheid
3.7 Design und Implementierung
3.7.1 Wichtige Elemente der Companion-Website

3.7.2 User Interface

51

52 52
3.7.2.1 Grafikelemente 3.7.2.2 Grafiken in Adobe Illustrator erstellen

„Simulationsprogramm zur Visualisierung der Vorgänge in einem Computer“

Seite 2 von 71

3.7.2.3 Zusätzliche Grafikebenen 3.7.2.4 Navigation
54 55

3.7.3 Software Design

55

3.7.3.1 MVC Framework

55

3.7.4 Vorgehensweise bei der Implementierung
3.8 Tests und Validierung
57 57 58 58 58 59 59 59 60 60
3.9 Ergebnisse und Zusammenfassung
3.9.1 Plattformunterschiede
3.9.1.1 Flash 3.9.1.2 Neko 3.9.1.3 Mac OS 3.9.1.4 HTML5 3.9.1.5 iOS 3.9.1.6 Android
3.9.2 Vergleich der Ergebnisse
3.10 Fazit und Ausblick
3.10.1 Zielerreichung
61 62 62 62 64 65
3.10.2 Technische Hürden 3.10.3 Ausblick
3.11 Persönliches Fazit

4. Schlussfolgerungen 5. Quellen
66 67

71

6. Selbständigkeitserklärung

Seite 3 von 71

Abbildungsverzeichnis

Abb. 1: (Quelle: fotolia.de, [3]) Abb. 2: (Quelle: fotolia.de, [4]) Abb. 3: (Quelle: fotolia.de, [5])
14 14 14
Abb. 4: Little Man Computer Simulation (Quelle: https://community.dur.ac.uk/m.j.r.bordewich/

LMC.html, besucht: 10.5.2015)

15

16 17
Abb. 5: Bonsai Simulationsprogramm (Quelle: http://www.inf-schule.de/infschule/softwarewerkzeuge/ bonsai, besucht 10.5.2015)

Abb. 6: Bonsai-Lerncomputer (Quelle: http://www.inf-schule.de/rechner/bonsai/einfuehrung/ausblick, besucht 10.5.2015)

Abb. 7: Akteure für das Rollenspiel (Quelle: http://www.inf-schule.de/rechner/bonsai/murmelrechner/

einfachermurmelrechner/akteure, besucht: 10.5.2015)

17

18

Abb. 8: Paper Processor (Quelle: https://sites.google.com/site/kotukotuzimiti/, besucht 10.9.2015)

Abb. 9: Instructionset für den Paper Processor (Quelle: https://sites.google.com/site/kotukotuzimiti/,

besucht 10.5.2015)

19

Abb. 10: WDR-1-Bit-Computer (Quelle: http://wdr-1-bit-computer.talentraspel.de, besucht 18.5.2015)

Abb. 11: 8-Bit Computer Marke Eigenbau (Quelle: http://www.instructables.com/id/

How-to-Build-an-8-Bit-Computer/, besucht 18.5.2015)

20

20 21
Abb. 12: CHUMP lab kit (Quelle: http://repository.cmu.edu/cgi/viewcontent.cgi?article=1595&context=- compsci, besucht 16.5.2015)

Abb. 13: Visual Transistor-level Simulation of the 6502 CPU (Quelle: http://www.visual6502.org, besucht 18.5.2015)

Abb. 14: Tetris-Simulation in Logisim (Quelle: https://www.youtube.com/watch?v=YCBa1NH4ORE,

besucht 9.5.2015)

22

23 25
Abb. 15: Struktur eines Computers mit 6 Ebenen (Quelle: [31], S.22) Abb. 16: Architektur des geplanten Simulationsprogramms Abb. 17: Typen von Logikgattern und Symbolik (Quelle: https://de.wikipedia.org/wiki/Logikgatter,

besucht 04.07.2015)

26

26 27 28 28
Abb. 18: NAND-Gatter (erstellt in Logisim) Abb. 19: Gatter und die entsprechenden Umsetzungen mit NAND-Gattern (erstellt in Logisim) Abb. 20: 1-Bit Speicher (erstellt in Logisim, ([37], S.24)) Abb. 21: 4-Bit Speicher (erstellt in Logisim, ([37], S.40))

Seite 4 von 71

Abb. 22: 4-Bit Register (erstellt in Logisim, ([37], S. 40)) Abb. 23: 4-Bit RAM (erstellt in Logisim, ([37], S. 52)) Abb. 24: 4-Bit Enabler (erstellt in Logisim, ([37], S. 40)) Abb. 25: 4x2 Multiplexer (erstellt in Logisim)
29 29 30 31 31 32 32 33 34 34 35 35
Abb. 26: 4x2 Multiplexer, 4 Datenbits (erstellt in Logisim) Abb. 27: 2x4 Dekoder (erstellt in Logisim, ([37], S. 48)) Abb. 28: Komparator (erstellt in Logisim, [38]) Abb. 29: 4-Bit Zähler (erstellt in Logisim, [38]) Abb. 30: Halbaddierer (erstellt in Logisim, ([37], S. 79)) Abb. 31: Volladdierer (erstellt in Logisim, ([37], S. 79)) Abb. 32: 4-Bit Addierer (erstellt in Logisim, ([37], S. 79)) Abb. 33: ALU „Arithmetic Logic Unit“ (erstellt in Logisim, [34]) Abb. 34: Taktsignal (Quelle: http://de.f-alpha.net/elektronik/digitale-elektronik/flip-flop/los-gehts/

experiment-8-master-slave/, besucht 19.6.2015)

36

37 38 40
Abb. 35: Fehler auf den Leitungen (erstellt in Logisim) Abb. 36: Fertige Vorlage für das Simulationsprogram (erstellt in Logisim) Abb. 37: Programm in hexadezimaler Form für Logisim (erstellt in Textmate) Abb. 38: ASCII-Tabelle (Quelle: http://worldpowersystems.com/J/codes/X3.4-1963/page5.JPG,

besucht 21.6.2015)

42

Abb. 39: Ebenen rsp. Detailstufen nach dem Babuschka-Prinzip, hier am Beispiel von Akkumulator

und ALU

48

49 50
Abb. 40: Navigation: Top-Down und Bottom-Up Abb. 41: Punkte malen Abb. 42: Palette mit Kopierpapier (Quelle: http://www.papierexpert.de/shop-c13-Kleinmengen-unter-

Palette, besucht 19.6.2015)

50

51 52 53 53 54
Abb. 43: Wireframe für iPad Abb. 44: Eine frühe Version, erstellt in Adobe Illustrator Abb. 45: Links mit Anti-Aliasing, rechts mit Kantenglättung Abb. 46: Pixelgenaue Grafik - kristallklar und scharf: das Anti-Aliasing ist weg Abb. 47: Anzeige des Datenflusses und Ausblenden gerade nicht beteiligter Komponenten

Seite 5 von 71

Abb. 48: Die fertige Hauptnavigation

55

56

Abb. 49: PureMVC - Konzeptionelles Diagramm (Quelle: [83])

Abb. 50: Kompiler-Anweisung: Skalierungsfaktor für iOS auf 2 setzen, für alle restlichen Zielplattformen

auf 1 lassen

58

59

Abb. 51: Mac OS: Text wird nicht innerhalb des Textrahmens umgebrochen

Abb. 52: Zum Vergleich: In Flash stimmt der Text-

umbruch, die « und » Zeichen sind ebenfalls vorhanden

59

Abb. 53: iPad: Änderung der Hintergrundfarbe und Textfarbe im Textfeld lässt den Text verschwinden 60

Abb. 54: Bei den anderen Plattformen funktioniert die Änderung der Textfeldfarben

60

Abb. 55: Lösung des Textfeld-Hintergrundfarbe-Problems: Vermeidung rsp. Nutzung einer zusätzlichen

Bitmapgrafik

60

63 64
Abb. 56: Nach dem Konvertieren von Haxe zu iOS ist der Programmcode nicht mehr wirklich lesbar Abb. 57: Code-Ausschnitt der automatisch erstellten Javascript-Datei

Seite 6 von 71

Tabellenverzeichnis

Tab. 1: Beispiel eines Rechenverfahrens für den Murmelrechner Tab. 2: Zuweisung der untersuchten Lösungen zu den 6 Ebenen des Computers Tab. 3: Logikgatter im Vergleich
18 23 27 39 39 40 41 42 42 47 58 61
Tab. 4: Beispiel von Programmzeilen Tab. 5: Beispiel von Programmzeilen, zusätzlich mit Assemblerbefehlen Tab. 6: Bedeutungen des Opcodes Tab. 7: Bedeutung des Daten- und Adressteils in Zusammenhang mit dem Opcode Tab. 8: Eigener Zeichencode Tab. 9: WELCOME! mit eigens erstelltem Zeichencode Tab. 10: Vergleich der Technologien nach der Evaluation Tab. 11: Übersicht: auf welchen Plattformen läuft der kompilierte Haxe-Code? Tab. 12: Vergleich der Ergebnisse der Applikation auf den verschiedenen Zielplattformen

Seite 7 von 71

Abkürzungen

Abkürzung

API GUI

Erklärung

Application Programming Interface Graphical User Interface Integrated Development Environment Model-View-Controller Native Development Kit Portable Network Graphics Random Access Memory Read Only Memory
IDE MVC NDK PNG RAM ROM SDK SVG SWF UI
Software Development Kit Scalable Vector Graphics Small Web Format User Interface

VM

Virtual Machine

Seite 8 von 71

Zusammenfassung

1. Zusammenfassung

Unser Alltag ist geprägt von Informations- und Kommunikationstechnologie: Nebst Computer und Smartphone sind es aber auch weniger offensichtliche Geräte, die wir täglich nutzen: die Kaffeemaschine, der RFID- Chip im Autoschlüssel, die Informationsanzeige am Bahnhof etc. Mit den sogenannten „Wearables“, die immer mehr an Bedeutung gewinnen, hält noch mehr Technologie im Alltag Einzug. Daher wird es in Zukunft immer wichtiger zu verstehen, wie die Grundprinzipien eines Computers funktionieren. Die vorliegende Arbeit nimmt sich diesem Thema an. Die Basis bildet ein Simulationsprogramm, welches die Vorgänge in einem Computer visuell darstellt. Dabei geht es in erster Linie darum zu vermitteln, was genau „ein Computer versteht nur 0 oder 1“ in der Praxis bedeutet. Auf spielerische Art und Weise wird erleb- und fassbar gemacht, wie Bus, Logikgatter, Register, Taktgeber etc. zusammenhängen.

Dazu werden Gespräche mit Informatikpädagogen geführt, die bestätigen, wie wichtig dieses Verständnis ist. Diverse bestehende Lösungen werden genauer beleuchtet: von spielerischen Varianten mit Murmeln oder Papier bis zu selbstgebauter Hardware und Simulationsprogrammen. Im Laufe der Evaluation wird klar, dass zwar viele verschiedene Lösungen mit ganz unterschiedlichen Schwerpunkten existieren, aber keine, welche die Vorgänge in ihrer Gesamtheit, von der einzelnen Instruktion bis zur aktivierten Leitung in einem Logikgatter, visuell darstellt. In Logisim, einer Software zur Erstellung digitaler Schaltungen und Simulationen für Lernzwecke, wird eine 4-Bit CPU erstellt, die als Basis dient, um anschliessend das eigentliche Simulationsprogramm zu bauen. Eine wichtige Anforderung ist die Verwendbarkeit auf möglichst vielen Plattformen. Dazu werden fünf Programmiersprachen unter die Lupe genommen, die in Frage kommen: Java, Actionscript, Javacript/HTML, Dart und Haxe. Jede Sprache wird genau betrachtet, die Vor- und Nachteile werden abgewogen, bis schliesslich Haxe als Favorit feststeht. Als nächstes werden anhand von Wireframes die Informationsarchitektur und das Layout festgelegt. Dabei wird bereits berücksichtigt, dass die Applikation auf Tablets mit Touchscreen bedienbar sein soll und die Navigationselemente entsprechend gestaltet werden müssen. In Adobe Illustrator werden die Grafiken erstellt und anschliessend in Adobe Photoshop als Bitmapgrafiken weiterverarbeitet. Bei der Implementierung wird zuerst ein geeignetes MVC Framework gesucht. Mit PureMVC wird eine viel versprechende Lösung gefunden, die nicht nur für Haxe verfügbar ist, sondern auch für eine Reihe anderer Sprachen. Somit soll die spätere Portierung, falls nötig, einfacher sein, weil grosse Teile der Architektur übernommen werden können. Im Laufe der Umsetzung wird klar, dass Haxe sein vollmundiges Versprechen – „With Haxe, you can easily build cross-platform tools targeting all the mainstream platforms natively“ [72] – in der Praxis leider nicht ganz halten kann. Auf jeder der verwendeten Zielplattformen (Flash, Neko, Mac OS, HTML 5, iOS und Android) tauchen Probleme auf. In einer Vergleichstabelle wird abgewogen, wie gravierend diese Mängel sind und ob dadurch der Einsatz von Haxe weiterhin in Frage kommt oder nicht. Am Schluss bleibt nur HTML als Zielplattform übrig, die mit Einschränkung empfohlen werden kann. Und dies auch nur auf dem Desktop Computer – auf den Tablets hält die Performanz dem Vergleich mit den nativen Versionen nicht stand. Das Simulationsprogramm verlangt der jeweiligen Plattform mit seinen schnellen Grafikwechseln einiges ab, sodass man vor einer weiteren Entwicklung des Programms zuerst das weitere Vorgehen überdenken muss.

Seite 9 von 71

Zusammenfassung

Als Schlussfolgerung muss das erstellte Simulationsprogramm als Prototyp angesehen werden. Aufgrund der Ergebnisse mit Haxe und den Anforderungen an die Leistung der jeweiligen Plattform, speziell bei Tablet Computern, muss die Lösung als ganzes neu überdacht werden. Mit Haxe ist man in einer Sackgasse angelangt, und so kommt Java als mögliche Alternative wieder in Betracht, jetzt aber nicht mehr als eine ganzheitliche Lösung für Desktop und Tablets, sondern als ausgewachsene Applikation für den Desktop einerseits und als abgespeckte und vereinfachte Variante für iOS und Android andererseits . Diese vereinfachten Varianten könnten dafür wieder mit Haxe umgesetzt werden. Mit PureMVC hat man zum Glück ein Framework, dass für alle in Frage kommenden Sprachen eingesetzt werden kann.

Seite 10 von 71

Ausgangslage

2. Einleitung

Die Informatik ist heutzutage allgegenwärtig. Die Informations- und Kommunikationstechnologien dringen immer tiefer in unseren Alltag ein: neben Computer, Smartphone, Navigationsgerät tauchen neue Begriffe auf wie „M2M“ (Machine-to-Machine) und „Wearables“. Die Geräte werden dabei immer kleiner und unsichtbarer, Unmengen von Daten werden laufend gespeichert und ausgewertet. Wir verlassen uns immer mehr darauf, dass „es einfach funktioniert“. Oft geht es dabei um überlebenswichtige Aufgaben, wie beispielsweise bei Bordcomputern von Fahrzeugen (vom Motorrad bis zum Flugzeug), medizinischen Überwachungsgeräten, Verkehrsleitsystemen und so weiter.

Neben den offensichtlichen Computern mit Bildschirm und Tastatur sind wir umgeben von digitaler Technik, ohne uns dessen wirklich bewusst zu sein: Mikrocomputer oder sogenannte digitale Signalprozessoren (DSPs) sind weitverbreitet in unserem täglichen Leben. Man findet sie im Wecker auf dem Nachttisch, in der Kaffeemaschine, in der Temperaturüberwachung im Heizsystem, im RFID-Chip im Autoschlüssel, dem Mikrowellenherd, in der Informationsanzeige am Bahnhof etc. Da diese Systeme eine bestimmte Aufgabe erfüllen und Bestandteil eines Produktes oder Systems sind, nennt man sie „Embedded Systems“. Die Mikrocomputer dieser eingebetteten Systeme haben viel gemeinsam mit einem herkömmlichen PC, allerdings sind hier die Programme meist permanent gespeichert und stellen nur die für das Produkt erforderlichen Funktionen bereit. ([1], S.7) Mit den Wearables, also zum Beispiel in Kleider integrierten Computerchips, wird die ganze Situation noch einmal drastisch gesteigert, Google Glass oder die Smartwatch sind nur der Anfang. Alles wird mit allem vernetzt sein und laufend werden Informationen ausgetauscht.

In naher Zukunft wird es daher immer wichtiger zu verstehen, wie die Grundprinzipien eines Computers funktionieren. Denn die haben sich in den letzten 50 Jahren kaum verändert.

2.1 Ausgangslage

Auf der Suche nach Beispielen, welche die Funktionsweise eines Computers zeigen, stösst man immer wieder auf folgende zwei „Muster“:
• einfach und abstrakt: Anhand von einfachen Vergleichen wie „Glühlampe ein/aus“, „alles ist 0 oder 1“,
„der Computer ist dumm, aber schnell“ wird auf abstrakte Art und Weise vermittelt, wie ein Computer im Prinzip funktioniert.
• technisch und komplex: Anhand von zum Teil aufwändigen Beispielen werden CPUs simuliert. Zwar technisch einwandfrei, aber für den Einstieg in die Materie zu anspruchsvoll und somit abschreckend.

Im Lehrplan21 (Modul Medien und Informatik) heisst es unter Zielsetzungen „Informatik“;

• „Schülerinnen und Schüler verstehen Grundkonzepte der automatisierten Informationsverarbeitung, nutzen sie zur Entwicklung von Lösungsstrategien in allen Lebensbereichen und zum Verständnis der Informationsgesellschaft ([2], S.2)“.

... und unter Didaktische Hinweise „Informatik“:

• „Be-greifbare“ Informatik: „Informatik gilt als abstraktes Thema. Für eine erfolgreiche Vermittlung in der Volksschule gilt es deshalb, Informatik anschaulich und begreifbar zu vermitteln. Neben dem Lebensweltbezug bei der Wahl der Beispiele ist deshalb darauf zu achten, Informatikkonzepte wenn immer möglich be-greifbar und anschaulich zu vermitteln ([2], S.4)“.

Seite 11 von 71

Motivation

2.2 Motivation

„Wenn immer möglich be-greifbar und anschaulich zu vermitteln“: Dieser Satz hat den Autor dieses Berichtes in seiner Vermutung bestärkt, dass hier eine grosse Nachfrage nach zusätzlicher, interaktiver Unterstützung im Unterricht besteht. Im Gespräch mit René Moser (Leiter Bildung und ICT) und Roland Boot (Lehrmittel, Unterrichtsfragen) vom Volksschulamt Zürich hat sich diese Vermutung verfestigt und in ein echtes Bedürfnis verwandelt. Dies ging sogar soweit, dass in der Diskussion die Idee entstand, zukünftig eine modulartige Plattform zu schaffen, die auch weitere Aspekte abdecken könnte.