Simulationsprogramm zur Visualisierung der Vorgänge in ... · Abb. 46: Pixelgenaue Grafik -...

Simulationsprogramm zur Visualisierung der Vorgänge in einem Computer

Masterarbeit zur Erlangung des

Master of Advanced Studies ZFH inInformatik

vorgelegt von

Christian Kaegigeboren am 05.01.1969

von Bauma, Kanton Zürich

eingereicht Dipl. Ing. Walter Eich

Stetten, 28.8.2015

„Simulationsprogramm zur Visualisierung der Vorgänge in einem Computer“ Seite 2 von 71

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

Inhaltsverzeichnis

1. Zusammenfassung 9

2. Einleitung 112.1 Ausgangslage 112.2 Motivation 122.3 Fragestellungen 122.4 Abgrenzung 122.5 Zielsetzung 12

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

3.1.1 Definition der Zielgruppe 133.1.2 Personas 143.1.3 Beispiele von existierenden Lösungen und Lösungsansätzen 15

3.1.3.1 Little Man Computer 153.1.3.2 Der Bonsai-Modellrechner 163.1.3.3 Der Murmelrechner 173.1.3.4 Paper Processor 183.1.3.5 WDR-1-Bit-Computer 193.1.3.6 Ein 8-Bit Computer Marke Eigenbau 193.1.3.7 Ein einfacher 4-Bit Computer für den Klassenraum 203.1.3.8 Visuelle Simulation einer 6502 CPU auf Transistorebene 213.1.3.9 Simulationen mit Logisim 223.1.3.10 Weitere Simulationsprogramme 22

3.1.4 Fazit 233.2 Lösungsansatz 243.3 Die Komponenten 25

3.3.1 Befehls-, Daten- und Adressbus 263.3.2 Logikgatter 263.3.3 Speicher 273.3.4 Auswahlschaltungen 303.3.5 Arithmetik 323.3.6 Taktgeber 36

3.4 Simulation in Logisim bauen 363.4.1 Befehlssatz 38

3.4.1.1 Erläuterung der Befehle 403.4.1.2 Zeichencode 41

3.5 Anforderungen an das Simulationsprogramm 433.6 Technologie-Evaluation 44

3.6.1 Zielplattform 443.6.2 Java 443.6.3 Actionscript 443.6.4 Javascript/HTML 453.6.5 Dart 463.6.6 Haxe 463.6.7 Entscheid 47

3.7 Design und Implementierung 483.7.1 Wichtige Elemente der Companion-Website 493.7.2 User Interface 51

3.7.2.1 Grafikelemente 523.7.2.2 Grafiken in Adobe Illustrator erstellen 52



3.7.2.3 Zusätzliche Grafikebenen 543.7.2.4 Navigation 55

3.7.3 Software Design 553.7.3.1 MVC Framework 55

3.7.4 Vorgehensweise bei der Implementierung 573.8 Tests und Validierung 573.9 Ergebnisse und Zusammenfassung 58

3.9.1 Plattformunterschiede 583.9.1.1 Flash 583.9.1.2 Neko 593.9.1.3 Mac OS 593.9.1.4 HTML5 593.9.1.5 iOS 603.9.1.6 Android 60

3.9.2 Vergleich der Ergebnisse 613.10 Fazit und Ausblick 62

3.10.1 Zielerreichung 623.10.2 Technische Hürden 623.10.3 Ausblick 64

3.11 Persönliches Fazit 65

4. Schlussfolgerungen 66

5. Quellen 67

6. Selbständigkeitserklärung 71



Abbildungsverzeichnis

Abb. 1: (Quelle: fotolia.de, [3]) 14



Abb. 4: Little Man Computer Simulation (Quelle: https://community.dur.ac.uk/m.j.r.bordewich/ LMC.html, besucht: 10.5.2015) 15

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

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

Abb. 7: Akteure für das Rollenspiel (Quelle: http://www.inf-schule.de/rechner/bonsai/murmelrechner/ einfachermurmelrechner/akteure, besucht: 10.5.2015) 17

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

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) 19

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

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

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

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

Abb. 15: Struktur eines Computers mit 6 Ebenen (Quelle: [31], S.22) 23

Abb. 16: Architektur des geplanten Simulationsprogramms 25

Abb. 17: Typen von Logikgattern und Symbolik (Quelle: https://de.wikipedia.org/wiki/Logikgatter, besucht 04.07.2015) 26

Abb. 18: NAND-Gatter (erstellt in Logisim) 26

Abb. 19: Gatter und die entsprechenden Umsetzungen mit NAND-Gattern (erstellt in Logisim) 27

Abb. 20: 1-Bit Speicher (erstellt in Logisim, ([37], S.24)) 28

Abb. 21: 4-Bit Speicher (erstellt in Logisim, ([37], S.40)) 28



Abb. 22: 4-Bit Register (erstellt in Logisim, ([37], S. 40)) 29

Abb. 23: 4-Bit RAM (erstellt in Logisim, ([37], S. 52)) 29

Abb. 24: 4-Bit Enabler (erstellt in Logisim, ([37], S. 40)) 30

Abb. 25: 4x2 Multiplexer (erstellt in Logisim) 31

Abb. 26: 4x2 Multiplexer, 4 Datenbits (erstellt in Logisim) 31

Abb. 27: 2x4 Dekoder (erstellt in Logisim, ([37], S. 48)) 32

Abb. 28: Komparator (erstellt in Logisim, [38]) 32

Abb. 29: 4-Bit Zähler (erstellt in Logisim, [38]) 33

Abb. 30: Halbaddierer (erstellt in Logisim, ([37], S. 79)) 34

Abb. 31: Volladdierer (erstellt in Logisim, ([37], S. 79)) 34

Abb. 32: 4-Bit Addierer (erstellt in Logisim, ([37], S. 79)) 35

Abb. 33: ALU „Arithmetic Logic Unit“ (erstellt in Logisim, [34]) 35

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

Abb. 35: Fehler auf den Leitungen (erstellt in Logisim) 37

Abb. 36: Fertige Vorlage für das Simulationsprogram (erstellt in Logisim) 38

Abb. 37: Programm in hexadezimaler Form für Logisim (erstellt in Textmate) 40

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

Abb. 40: Navigation: Top-Down und Bottom-Up 49

Abb. 41: Punkte malen 50

Abb. 42: Palette mit Kopierpapier (Quelle: http://www.papierexpert.de/shop-c13-Kleinmengen-unter- Palette, besucht 19.6.2015) 50

Abb. 43: Wireframe für iPad 51

Abb. 44: Eine frühe Version, erstellt in Adobe Illustrator 52

Abb. 45: Links mit Anti-Aliasing, rechts mit Kantenglättung 53

Abb. 46: Pixelgenaue Grafik - kristallklar und scharf: das Anti-Aliasing ist weg 53

Abb. 47: Anzeige des Datenflusses und Ausblenden gerade nicht beteiligter Komponenten 54



Abb. 48: Die fertige Hauptnavigation 55

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

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

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

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

Abb. 56: Nach dem Konvertieren von Haxe zu iOS ist der Programmcode nicht mehr wirklich lesbar 63

Abb. 57: Code-Ausschnitt der automatisch erstellten Javascript-Datei 64



Tabellenverzeichnis

Tab. 1: Beispiel eines Rechenverfahrens für den Murmelrechner 18

Tab. 2: Zuweisung der untersuchten Lösungen zu den 6 Ebenen des Computers 23

Tab. 3: Logikgatter im Vergleich 27

Tab. 4: Beispiel von Programmzeilen 39

Tab. 5: Beispiel von Programmzeilen, zusätzlich mit Assemblerbefehlen 39

Tab. 6: Bedeutungen des Opcodes 40

Tab. 7: Bedeutung des Daten- und Adressteils in Zusammenhang mit dem Opcode 41

Tab. 8: Eigener Zeichencode 42

Tab. 9: WELCOME! mit eigens erstelltem Zeichencode 42

Tab. 10: Vergleich der Technologien nach der Evaluation 47

Tab. 11: Übersicht: auf welchen Plattformen läuft der kompilierte Haxe-Code? 58

Tab. 12: Vergleich der Ergebnisse der Applikation auf den verschiedenen Zielplattformen 61



Abkürzungen

Abkürzung ErklärungAPI Application Programming InterfaceGUI Graphical User InterfaceIDE Integrated Development EnvironmentMVC Model-View-ControllerNDK Native Development KitPNG Portable Network GraphicsRAM Random Access MemoryROM Read Only MemorySDK Software Development KitSVG Scalable Vector GraphicsSWF Small Web FormatUI User InterfaceVM Virtual Machine


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

1. ZusammenfassungUnser Alltag ist geprägt von Informations- und Kommunikationstechnologie: Nebst Computer und Smart-phone 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 im-mer 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 Logik-gatter, 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 Pro-grammiersprachen 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 bedien-bar 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 über-nommen 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 And-roid) 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, so-dass man vor einer weiteren Entwicklung des Programms zuerst das weitere Vorgehen überdenken muss.


ZHAW - Masterarbeit - Christian Kaegi - 28.8.2015 - v2.0.3 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 ange-

langt, und so kommt Java als mögliche Alternative wieder in Betracht, jetzt aber nicht mehr als eine ganzheit-

liche 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.


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

2. EinleitungDie 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 Bordcom-putern von Fahrzeugen (vom Motorrad bis zum Flugzeug), medizinischen Überwachungsgeräten, Verkehrsleit- systemen und so weiter.

Neben den offensichtlichen Computern mit Bildschirm und Tastatur sind wir umgeben von digita-ler Technik, ohne uns dessen wirklich bewusst zu sein: Mikrocomputer oder sogenannte digitale Signal- prozessoren (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 er-forderlichen 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 ver-netzt 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 AusgangslageAuf 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)“.


ZHAW - Masterarbeit - Christian Kaegi - 28.8.2015 - v2.0.3 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ürf-nis 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.

2.3 Fragestellungen

Was sind die Kernelemente, die in der Applikation behandelt werden sollen?„Der Computer ist dumm, aber unglaublich schnell“: Genau dieser Satz soll durch die Applikation fassbar gemacht werden. Wie kann man die Funktionsweise von Bus, Logikgatter, ALU, Register, RAM, Taktgeber etc. zeigen, ohne einerseits oberflächlich zu sein, aber andererseits auch nicht zu tief ins Detail zu gehen? Wie muss die Simulation aufgebaut werden, um schrittweise bei Bedarf in die Tiefe gehen zu können? Wie kann ich eine technische Simulation so aufbereiten, dass auch der nicht-technikaffine Benutzer Spass daran hat? Wie kann man den Faktor unglaublich schnell „be-greifbar“ machen? Was bedeutet genau „der Comuputer versteht nur 0 und 1“ in der Praxis?

2.4 Abgrenzung Die Applikation beschränkt sich auf einen Vorgang nach dem EVA-Prinzip. Dabei soll sich das Simulations- programm auf einen konkreten Ablauf innerhalb eines Computers konzentrieren. Es wird kein Anspruch auf Perfektion bis ins letzte Detail erhoben; das zu vermittelnde Wissen und der Spass daran stehen im Vor-dergrund. Bestimmte Elemente und Bezeichnungen müssen bewusst weggelassen werden; zugunsten eines schnelleren Verständnisses und um den Benutzer nicht abzuschrecken. Als Zielgruppe hat sich die Volksschule herauskristallisiert, also Schüler der Sekundarstufe I und II. Die Applikation beschränkt sich hauptsächlich auf die Visualisierung von Hardware. Andere Themen wie Soft-ware, Programmiersprachen oder Betriebssysteme werden nur soweit wie nötig erklärt.

2.5 Zielsetzung

Quantitative Ziele• Anhand eines Programmablaufs wird gezeigt, wie die Informationen über die Leitungen und Logik-

gatter „wandern“.• Der Benutzer kann interaktiv den Vorgang bis zur Zeitlupe abbremsen.• Die Addition wird anhand zweier Eingaben gezeigt. • Man kann in die einzelnen Bauteile „einzoomen“, um z.B. das NAND-Gatter genauer zu betrachten.• Zu jedem Element kann der Benutzer mit einem Klick Links zu weiterführender Literatur, Videos etc.

anzeigen. Das Simulationsprogramm dient somit auch als eine Art „Index“. • Schnittstellen zum weiteren Ausbau des Simulationsprogramms werden angedeutet (z.B. Kommuni-

kation zu einem anderen Computer).


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

Qualitative Ziele• Um eine möglichst grosse Erreichbarkeit zu gewährleisten, soll die Applikation sowohl im Webbrowser

als auch auf Tablet Computern mit Touchscreen lauffähig sein. Dabei soll kein Plugin oder sonst eine proprietäre Technologie zum Einsatz kommen. Es soll zumindest auf dem Desktop-Computer nichts installiert werden müssen, auf Mobilgeräten kann es nach der Evaluation der geeigneten Technologie sein, dass eine (kostenlose) App installiert werden muss.

• Die Applikation hat einen hohen Qualitätsanspruch: sie muss einfach und intuitiv bedienbar sein, ohne oberflächlich zu wirken. Der Benutzer soll ein „AHA“-Erlebnis bekommen und interaktiv in den Ablauf eingreifen können.

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

3.1 ProblemanalyseWelche Lösungsansätze gibt es bereits, die einen Vorgang im Computer zeigen? Auf der Suche nach geeignetem Material stösst man auf mehrere Ansätze, die hier nachfolgend im Detail beschrieben werden. Einleitend kann man sagen, dass auch nach ausgiebiger Recherche im Internet keine einzige Lösung gefunden wurde, die der Zielsetzung dieser Arbeit entspricht. Ein Auszug der verwendeten Suchbegriffe ist hier aufgelistet:

• Computer Simulation• Funktionsweise eines Computers• 4 bit Rechner• How do Computers work• Computer einfach erklärt• Tutorial Computer Basics

• Rechnersimulation• Vorgang im Computer visualisieren• Teaching Computer Basics• Learning Computer Basics• etc.

Zu den vielen Software-Simulationen existieren auch diverse Hardware-Implementierungen, welche die Vor-gänge zwar nachvollziehbar machen, aber nicht auf der „0 und 1“-Ebene (Logikgatter).

3.1.1 Definition der ZielgruppeNach einem ersten Gespräch mit René Moser und Roland Boot vom Volksschulamt Zürich wurde als mög-liche Zielgruppe die Sekundarstufe II angesehen. Basierend auf dieser Annahme wurde über das Pfingstwo-chenende eine Gruppe von sechs Jugendlichen im Alter von 14 bis 17 Jahren nach ihrem Wissensstand in der Informatik befragt. Zu diesem Zeitpunkt war die Simulation in Logisim bereits in einem präsentierbaren Zustand und wurde auch gezeigt. Die Skepsis war sehr gross, das Wissen aber leider sehr gering. Die Schüler hatten wohl die Thematik teilweise durchgenommen, doch blieb nur sehr wenig hängen. Ausprobiert wurden vor allem Anwendungsprogramme, die Jugendlichen lernten, wie man E-Mails verschickt und Dateien spei-chert, doch danach war schnell einmal Schluss.Kurze Zeit später fand ein zweites Gespräch mit R. Moser und R. Boot statt. Bei dieser Gelegenheit konnte die Logisim Simulation gezeigt werden. Nach einer „im positiven Sinne erschlagenden Präsentation“ wurde allerdings klar, dass die Sekundarstufe II womöglich (noch) zu wenig tief in das Thema Informatik eintaucht, um die Simulation zu verstehen. Das nächste Gespräch fand in Brugg bei der Fachhochschule Nordwestschweiz statt. Dr. Ronny Standtke, Do-zent für Medienpädagogik, unterrichtet objektorientierte Programmierung im ersten und zweiten Semester.



Er war sehr interessiert, ein solches Simulationsprogramm für die Studenten zur Verfügung zu haben. Bei ihm liegt der Fokus mehr auf der Programmierung: Er konnte sich auch eine Erweiterung vorstellen, um das Simulationsprogramm mit Programmiersprachen zu verbinden und so die Möglichkeiten noch zu erweitern. Ein weiteres Gespräch fand beim Mittelschul- und Berufsbildungsamt in Zürich statt. Dr. Vincent Tscherter ist hier Bereichsleiter Pädagogische Informatik. Auch er fand die Idee gut, durch eine Simulation Vorgänge fassbar zu machen. Er setzt bereits ein kleines HTML-basiertes Tool ein, um Vorgänge auf der Festplatte zu erklären und visuell darzustellen. Er sieht das Problem vor allem darin, dass der Stellenwert der Informatik im Unterricht immer noch zu gering ist. Es steht auch zuwenig Zeit zur Verfügung, um alle Aspekte abdecken zu können. Von daher lässt sich nicht klar sagen, welches die richtige Zielgruppe ist. Ob Oberstufe, Berufsschule oder Hochschule, hängt von zu vielen Faktoren ab: dem Wissensstand (und -durst!) der Schüler und Studen-ten, den Unterrichtsmöglichkeiten, der zur Verfügung stehenden Zeit und der Wahl des Unterrichtsstoffes.

3.1.2 PersonasDa die Gespräche gezeigt haben, dass sich keine generelle Zielgruppe eruieren lässt, werden nun drei entspre-chende Personas definiert.

KarinAbb. 1: (Quelle: fotolia.de, [3])

• besucht das Gymnasium• 17 Jahre alt• geht gerne zur Schule• ist neugierig und fleissig• ist nicht technikaffin• Hobbys: Freunde,

chatten, Sport

„Wenn ich etwas lernen muss, was mich eigentlich nicht so sehr interessiert, bin ich froh, wenn es in einer praxisbezogenen Form präsentiert wird, in der ich es gut nachvollziehen kann. Umso mehr bei einem so abstrakten Thema wie der booleschen Algebra.“

DanielAbb. 2: (Quelle: fotolia.de, [4])

• studiert Informatik im ersten Semester

• 24 Jahre alt• ist technisch versiert• ist eher gelassen• Hobbys: Freunde, program-

mieren, Games, Motorrad

„Ich programmiere schon, seit ich 15 bin, und es macht mir grossen Spass. Im Studium komme ich nun auch mit den ganzen Themen der Digitaltechnik in Kontakt. Ich schätze es, wenn ich die Zusam-menhänge erleben kann, während ich mich ausführlich mit der Theorie beschäftigen muss.“

PhilippAbb. 3: (Quelle: fotolia.de, [5])

• Selbständiger Unternehmens-berater

• 51 Jahre alt• ist wissbegierig und hinter-

fragt gerne• hat als Anwender täglich mit

IT zu tun• Hobbys: Familie und Freun-

de, reisen, philosophieren, segeln

„Mich interessieren stets die Hin-tergründe: Wieso sind die Dinge so, wie sie sind? Wie funktioniert ein Benzinmotor? Wie fliegt die Fledermaus im Dunkeln? Wie funktioniert ein Computer?“



3.1.3 Beispiele von existierenden Lösungen und LösungsansätzenIm Folgenden werden einige Lösungen genauer betrachtet, welche speziell für pädogogische Zwecke eingesetzt werden oder sich sehr gut dafür eignen.

3.1.3.1 Little Man Computer

Die Suche nach „Little Man Computer“ auf Google liefert gut 193 Millionen Suchergebnisse (Stand 9.5.2015): kein Wunder, denn Stuart Madnik [6], ein amerikanischer Computerwissenschaftler und Professor am MIT, hat bereits 1965 ein Modell eines Computers speziell für Lernzwecke erstellt: den LMC (Little Man Computer) [7]. Der LMC wird hauptsächlich eingesetzt, um Studenten die Funktionsweise eines auf der Von Neumann- Architektur basierten Computers näherzubringen. Er kann mit einer Art Maschinencode (dezimal, nicht binär) oder Assemblersprache programmiert werden.

Abb. 4: Little Man Computer Simulation (Quelle: https://community.dur.ac.uk/m.j.r.bordewich/LMC.html, besucht: 10.5.2015)

FunktionsweiseDie Systemarchitektur wird mittels eines „kleinen Mannes“ dargestellt, der in einem Raum eingeschlossen ist. Auf der einen Seite des Raumes befinden sich 100 Postfächer (RAM), nummeriert von 0 bis 99. Jedes die-ser Postfächer kann eine dreistellige Instruktion oder Daten enthalten (000-999). Auf der anderen Seite des Raumes befinden sich 2 weitere Postfächer, angeschrieben mit „Eingang“ und „Ausgang“. Diese werden für das Empfangen und Versenden von Daten benötigt. In der Mitte des Raumes steht ein Rechner mit zwei ein-fachen Funktionen, der Addition und Subtraktion, genannt der Akkumulator. Daneben steht ein Zähler, der zurückgesetzt werden kann: der Programmzähler. Dieser Programmzähler hält die Instruktion bereit, welche der kleine Mann als nächstes ausführen muss. Sobald dieser den Befehl entgegen genommen hat, wird der Programmzähler eins hochgezählt. Sprungbefehle erlauben Schleifen (Loops) und zustandsabhängige Pro-grammierung im LMC. So kann beispielsweise der Programmzähler auf ein bestimmtes Postfach zeigen um dem kleinen Mann zu sagen, wo er etwas abzulegen oder abzuholen hat.



Um den LMC zu starten muss der Benutzer zuerst die Postfächer (RAM) füllen und danach den kleinen Mann anweisen, die erste Instruktion aus dem Postfach 0 abzuholen und dann sequentiell einen Befehl nach dem anderen abzuarbeiten, bis keine Instruktionen mehr vorhanden sind.Es gibt dutzende Simulationsprogramme des LMC, programmiert in verschiedenen Sprachen wie beispielsweise in ActionScript (Flash) [8], Java [9], Javascript [10] aber auch Excel [11]. Der LMC zeigt sehr schön den sequenziellen Ablauf eines Programms und erklärt damit den Computer auf abstrakter Ebene.

3.1.3.2 Der Bonsai-Modellrechner

Die Website „Informatik in der Schule“ [12] bezeichnet sich selbst als elektronisches Schulbuch und existiert seit 2008. Die Autoren sind zum grössten Teil Lehrerinnen und Lehrer, die selber Informatik unterrichten. Aber auch Studierende und sogar Schüler sind aktiv beteiligt und herzlich willkommen, Inhalte zu generieren. Auf gut 2000 Inhaltsseiten findet man viele sehr gute Erklärungen zum Thema Computer. Die verschiedenen Bereiche sind zum Beispiel „Information und ihre Darstellung“, „Einstiege in die Programmierung“, „Algo-rithmen und Datenstrukturen“, „Software und ihre Entwicklung“, „Kommunikation in Rechnernetzen“ und „Funktionsweise eines Rechners“. Unter letzterem Punkt stösst man auf den „Bonsai-Modellrechner“, der als Simulationsprogramm die Vorgänge in einem Computer zeigt. Unter dem Titel „Worum geht es?“ schreibt die Website einleitend: „Es ist fast unmöglich, einen Einblick in Aufbau und Funktionsweise eines Computers anhand realer Maschinen zu bekommen. Der Aufbau heutiger Prozessoren ist sehr komplex. Sie sind so mi-niaturisiert, dass ihre Struktur mit normalen Mitteln nicht mehr analysiert werden kann. Ihr Befehlssatz ist unübersichtlich groß und zudem vom jeweiligen Prozessor abhängig. Abhilfe schafft ein Modellrechner, der Bonsai-Lenrcomputer, mit extrem vereinfachtem Aufbau und minimaler Assemblersprache [13]“.

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

Auf mehreren Seiten wird die Architektur erläutert. Unter dem Titel „Das Operationswerk“ werden die Komponenten wie Register, Busse, Speicher und Befehlsausführung ausführlich und mit Beispielen aus der realen Welt erklärt, bevor es dann beim „Steuerwerk“ um Befehlszyklus, Steuersignale und Mikroprogram-mierung geht. Schrittweise wird dabei der Bonsai-Modellrechner aufgebaut und jedes einzelne Bauteil genauer beleuchtet.



Im Simulationsprogramm kann anschliessend das Gelernte selber interaktiv ausprobiert werden. Der Bonsai- Modellrechner ist aber nicht nur auf ein Simulationsprogramm beschränkt, es gibt auch eine Hardware- Variante davon.

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

3.1.3.3 Der Murmelrechner

Ebenfalls auf der vorher genannten Website „Informatik in der Schule“ [12] findet man den Murmelrechner [14], welcher eine Erwähnung wert ist. Bei diesem geht es darum, in einem Rollenspiel die verschiedenen Kom-ponenten eines Computers zu erleben. Dazu werden Becher als Speicher benötigt, in welche Murmeln (die Daten) abgelegt werden. Die Becher werden durchnummeriert (=Adressen), sodass man am Ende anhand der Adresse den Speicherinhalt (die Murmeln) „auslesen“ kann. Die Grundoperationen des Murmelrechners sind: Inkrementieren (eine Murmel hinzufügen), Dekrementieren (eine Murmel entfernen) sowie Prüfen (befindet sich eine Murmel im Gefäss oder nicht).

Abb. 7: Akteure für das Rollenspiel (Quelle: http://www.inf-schule.de/rechner/bonsai/mur-melrechner/einfachermurmelrechner/akteure, besucht: 10.5.2015)



Mittels Einsatz zwei verschiedener Farben für die Murmeln kann man zwischen Befehlen und Parametern unterscheiden. Angenommen, der Befehlscode für Inkrementieren ist 1 und in einem Becher liegen eine grüne (grün=Befehlscode) und vier rote Murmeln (rot=Parameter), entspräche dies der Instruktion „INC 4“. Ein Rechenverfahren könnte nun wie folgt aussehen [15]:

prüfe, ob Gefäss 1 leer ist 0 tst 1wenn ja, dann... 1 jmp 3...beende den Vorgang 2 jmp 6wenn nein, dann... 3 dec 1...entferne eine Murmel aus Gefäss 1 4 inc 0...lege eine Murmel in Gefäss 0 5 jmp 0....beginne wieder am Anfang 6 hlt

Tab. 1: Beispiel eines Rechenverfahrens für den Murmelrechner

Man sieht bei diesem Rollenspiel sehr schön, wie ein Computer in einfachen einzelnen Schritten arbeitet, und bekommt ein Gefühl dafür, dass sehr viele Schritte notwendig sind, um komplexe Abläufe und Programme abarbeiten zu können. Schüler des Gymnasiums Edenkoben haben sich die Mühe gemacht, ein Video des Rollenspiels zu drehen [16].

3.1.3.4 Paper Processor

In eine ähnliche Kerbe wie der Murmelrechner schlägt der Paper Processor von Saito Yutaka [17]. Auch hier geht es darum, auf spielerische Weise die Funktionen und Abläufe eines Computers erleben zu können. Dazu kann man auf der Website von Saito Yutaka den Paper Processor als PDF herunterladen und die beweglichen Elemente ausschneiden.

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

Es gibt 3 Register: Programmzähler, Register und Status Register (Over Flow). Da der Befehlssatz lediglich aus 3 Instruktionen besteht, ist es relativ einfach, den Paper Processor zu „programmieren“. Man startet wie im Bild oben rechts. Die erste Instruktion wird ausgeführt (1 wird ins Register „geschrieben“), der Programmzähler eins erhöht, und somit „rutscht“ der Pfeil eine Zeile herunter. Jetzt wird die nächste Instruktion analysiert und ausgeführt. So geht es Schritt für Schritt weiter. Man bewegt physisch den Pointer und füllt die 3 Register mit



den ausgeschnittenen Feldern. Natürlich ist man bei nur 3 Instruktionen schnell fertig, aber für einen aller- ersten spielerischen Einstieg ist der Paper Prozesser eine gelungene Sache.

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

3.1.3.5 WDR-1-Bit-Computer

Das Bedürfnis nach Methoden, eine leichte Einführung in die Welt der Computer zu bekommen, reicht in der Zeit weit zurück. So findet man bereits Mitte der 80er Jahre den WDR-1-Bit-Computer [18] der einzig mit dem Ziel entstand, Schülerinnen und Schülern einen einfachen Einstieg in die Thematik zu geben. Basierend auf dem 14500-Baustein von Motorola wurde der Computer nach didaktischen Gesichtspunkten vereinfacht, damit er anschliessend von den Schülern aufgebaut und programmiert werden konnte.

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

3.1.3.6 Ein 8-Bit Computer Marke Eigenbau

Was jetzt folgt ist nicht unbedingt ein Beispiel eines didaktischen Computers für Lernende, aber es zeigt, dass es schlussendlich gar nicht so schwer ist, selber einen Computer zu bauen. Auf der Website www.instructables.com [19] zeigt ein Mitglied mit dem Pseudonym „spel3o“ [19] in 18 Einzelschritten, was es alles dazu benötigt. Angefangen mit der Elektronik, wird anschliessend die Logikebene erklärt. Der Autor schreibt „This project is intended to help anyone interested in building their own computer and gaining the wonderful knowledge that comes along with the process [20]“. Am Schluss hat man einen programmierbaren Computer, der zugegebe-nermassen etwas wild aussieht mit all den Kabeln, aber man hat viel gelernt auf dem Weg dahin.



Abb. 11: 8-Bit Computer Marke Eigenbau (Quelle: http://www.instructables.com/id/How-to-Build-an-8-Bit-Computer/, besucht 18.5.2015)

3.1.3.7 Ein einfacher 4-Bit Computer für den Klassenraum

David Feinberg von der „The Harker School“ entschied sich 2005, zusätzlich zum softwarefokussierten Com-puterkurs den Studenten die Möglichkeit zu bieten, für wenig Geld selber einen einfachen 4-Bit Computer bauen zu lassen [21]. Drei Ziele wollte er damit erreichen: zu erforschen, was ein Computer ist, das Zusammen-spiel von Hard- und Software zeigen sowie die Maschine mit den Programmkonstrukten verbinden. Seiner Meinung nach war es viel wertvoller, mit echter Hardware zu arbeiten anstatt nur mit Simulationssoftware, wie es zu der Zeit gemacht wurde. Mit drei klaren Anforderungen - der Computer sollte einfach zu verstehen sein, in kurzer Zeit zusammengesetzt werden können und wenig Geld kosten - machte er sich auf die Suche nach simplen Prozessor-Designs. Es war relativ schnell klar, dass es ein 4-bit Computer werden sollte, damit einerseits die Komplexität niedrig gehalten und andererseits die Funktionsweise sinnvoll aufgezeigt werden konnte. Es gab zwar ein Hand voll Prozessoren, aber diese waren entweder nicht gut dokumentiert oder aber bereits zu komplex. Also wurde entschieden, auf eigene Faust einen Prozessor zu designen: „The CHUMP“ wurde geboren („Cheap Homebrew Understandable Minimal Prozessor“).

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



Das Design basiert auf der RISC-Architektur, mit einem einfachen 4-Bit breiten Bus und einem kleinen Be-fehlssatz (14 Instruktionen). Daten und Programmcode sind getrennt in RAM und EEPROM. Ein CHUMP- Befehl besteht aus 8 Bit, unterteilt in den Opcode (die ersten 4 Bits) und den Wert (die restlichen 4 Bits). Durch die Einschränkung auf 4 Bits kann ein Programm nur aus 16 Zeilen Code bestehen, womit man natürlich kein sinnvolles Programm erstellen kann. Es gibt auch keine Interrupts, dadurch lässt sich der Prozessor nicht durch externe Eingaben interaktiv steuern. Abschliessend sind in der ALU keine Vergleiche möglich. Diese Einschränkungen könnten mit zusätzlicher Hardware leicht behoben werden, doch würde dies wiederum die Komplexität steigern. Aber ansonsten sind alle benötigten Elemente vorhanden: ALU, Akkumulator, Speicher, Programmzähler, Multiplexer etc. Am Ende des Kurses, der ein grosser Erfolg war, hatte jeder der Studenten seinen eigenen Computer zusam-mengebaut, getestet und programmiert. Der Materialwert betrug weniger als $65 für alle Teile inklusive Steck-platine.

3.1.3.8 Visuelle Simulation einer 6502 CPU auf Transistorebene

Einen spannenden Ansatz verfolgt das Projekt Visual6502.org [22]. Hier geht es darum, historische Chips zu studieren, zu dokumentieren und in einer visuellen Form wieder aufleben zu lassen. Als erster Chip wurde 2010 der 6502 gewählt, ein Chip, der sozusagen eine zentrale Rolle in der Heimcomputerrevolution gespielt hat. Er kam bei allen wichtigen Computern zum Einsatz: Atari, Apple, Commodore, Nintendo etc. Der Chip wird bis ins letzte Detail mittels Vektorgrafik komplett nachgebaut, sodass man die Vorgänge am Schluss sehen und somit erleben kann. Durch die Vektorgrafik ist es möglich, ganz nahe heranzuzoomen, Ausserdem kann man interaktiv einzelne Leiterbahnen anklicken und diese hervorheben. Durch Verwendung von verschiedenen Farben für die Stati „high“ und „low“ kann so exakt gezeigt werden, wie die CPU arbeitet. Das sehr genaue Modell kann sogar klassische Programme von Computern wie dem Atari laufen lassen. Für diejenigen, die sich mehr mit der Simulation der 6502 CPU und vor allem der Assemblerprogrammierung aus-einandersetzen möchten, gibt es eine Seite auf Github, Easy 6502 [23], die sich dem Thema ausführlich widmet.

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



3.1.3.9 Simulationen mit Logisim

Logisim [24] ist eine Grafiksoftware, mit deren Hilfe sich Logikschaltungen und Simulationen erstellen lassen.Die Software ist kostenlos und als Javaprogramm auf Windows, Mac und Linux Computern lauffähig.

Für den Einstieg bietet sie sehr gute Möglichkeiten, selber Logikschaltungen zu erstellen und die Zusammen-

hänge auszuprobieren. Eigene Schaltungen lassen sich als Komponenten wiederum in grösseren Schaltungen

integrieren. So kann man Schritt für Schritt auch komplexe Szenarien zusammenbauen. Es gibt eine Unzahl

an Beispielen, die mit Logisim umgesetzt wurden. „An Example Hardwired CPU“ [25] zeigt beispielsweise

eine 8-Bit CPU, die auf einer extra Website jedes Element ausführlich erklärt, inklusive dem Befehlssatz. Eine

Suchanfrage bei Youtube liefert über 6000 Resultate [26]: Man findet unzählige Videos, in denen Benutzer

stolz ihre Schaltungen präsentieren und teilweise sogar schrittweise erklären. Manche Benutzer erstellen fertig

funktionierende Spiele wie zum Beispiel „Snake“ und „Tetris“ [27]. Es erfordert allerdings einige Einarbei-

tungszeit, bis man solche Schaltungen selber erstellen kann.

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

3.1.3.10 Weitere Simulationsprogramme

Es gibt neben Logisim auch noch weitere Simulationsprogramme, auf die aber nicht im Detail eingegangen wird. Der Vollständigkeit halber werden hier ein paar davon, in zufälliger Reihenfolge, kurz erwähnt:

• HADES: ein Framework für interaktive Simulation [28]. Das Javaprogramm kann auch als Applet in Websites integriert werden. Als ursprüngliches Forschungsziel sollte das Programm die Hard- und Soft-



ware Co-Simulation unterstützen. Es hat eine höhere Einstiegshürde als Logisim, scheint dafür aber sehr mächtig zu sein.

• CPUSim: Ein Javaprogramm, das es dem Benutzer ermöglicht, auf Microcode-Ebene einfache CPUs zu gestalten und Maschinencode darauf laufen zu lassen [29].

• JLS - A Pedagogically Targetted Logic Design and Simulation Tool [30]. Ein Javaprogramm, welches digitale Logikschaltungen simuliert. Leider ist es nicht Open Source, daher wurde es im Rahmen dieses Berichts nicht weiter ausprobiert.

3.1.4 FazitEs gibt eine Menge an guten Beispielen und Lösungen, welche die Funktionsweise eines Computers erklären. Die Palette reicht von spielerischer Herangehensweise wie dem Murmelrechner oder Paper Processor über self-made Computer, zusammengebaut aus wenigen kostengünstigen Einzelteilen, bis hin zu wunderschönen visuellen Simulationen wie der 6502-CPU. Der Fokus liegt dabei auf ganz unterschiedlichen Bereichen.

Abb. 15: Struktur eines Computers mit 6 Ebenen (Quelle: [31], S.22)

Gemäss Abb. 15 wird in der nachfolgenden Tabelle versucht, die bisher untersuchten Lösungen den ver-schiedenen Ebenen zuzuordnen. Die Spalte ganz rechts zeigt die Bereiche, die das geplante Simulations- programm dieser Arbeit abdecken soll.

Little Man Computer

Bonsai- Rechner

Murmel-rechner

Paper Processor

WDR 1-Bit Processor

8-Bit Computer Eigenbau

8-Bit Computer Klassen-raum

Visuelle Simulation 6502

geplantesSimulations- Program

Ebene 5Ebene 4Ebene 3Ebene 2Ebene 1Ebene 0

Tab. 2: Zuweisung der untersuchten Lösungen zu den 6 Ebenen des Computers


ZHAW - Masterarbeit - Christian Kaegi - 28.8.2015 - v2.0.3 Lösungsansatz

Erstaunlich ist, wie viele Personen sich mit dem Thema auseinandersetzen und zum Teil komplexe Simulatio-nen erstellen. Minecraft [32] zum Beispiel ist eigentlich ein Computerspiel, bei dem es darum geht, aus Blöcken Strukturen zusammenzubauen. Es gibt aber auch hier viele Spieler, die sich zum Ziel gesetzt haben, ganze CPUs mit diesen Blöcken zu erstellen. Auf Youtube findet man dazu viele Beispiele, sogar aufgebaut als Tuto-rials [33]. Trotz der Fülle von selbstgebauter Hardware und Simulationen scheint keine Lösung zu existieren, die den Benutzer „an der Hand nimmt“ und ihn durch einen Vorgang im Inneren einer CPU führt, um die Zusammenhänge erleb- und somit fassbar zu machen. Die Tabelle Tab. 2 zeigt, dass das geplante Simulations-programm beabsichtigt, die Ebenen 0 bis 2 sowie Ebene 4 im Zusammenspiel zu zeigen.

3.2 LösungsansatzEs hat sich herausgestellt, dass Logisim mit seinem Funktionsumfang die perfekte Basis darstellt, um ein Simulationsprogramm im Rahmen dieser Arbeit zu erforschen und für die spätere Applikation vorzuberei-ten. Im Gegensatz zu den anderen Simulationsprogrammen ist Logisim sehr einfach zu bedienen und be-schränkt sich auf das intuitive Erstellen von digitalen Schaltungen, ohne den Anspruch zu erheben, diese später auf Hardware zu implementieren. Trotzdem ist es möglich, genügend tief ins Detail zu gehen, um funktionierende Schaltungen zu bauen. Das erste Ziel ist nun, anhand einer Logisim-Simulation die Vorgänge zu verstehen und herauszufinden, welche Komponenten nötig sind, um eine nicht zu komplexe Vorlage für die Implementierung zu bekommen. Um das Rad nicht neu zu erfinden, wurde eines der vielen Tutorials als Vorlage genutzt. Dabei bot sich die Serie „MM4001 - 4 Bit CPU Step by Step “ von „Minecraftmonkeys“ [34] an; eigentlich ist dies auch das einzige brauchbare und halbwegs komplette Tutorial. Es ist bereits über zwei Jahre alt, besteht aus sieben Teilen und ist leider nicht fertig gestellt. Mehrere Kontaktversuche mit dem Autor blieben erfolglos, die letzten hoch-geladenen Videos sind auch schon über ein Jahr alt. Aufgrund der Recherche und Analyse hat sich schnell herauskristallisiert, dass eine 4-Bit Architektur die beste Möglichkeit bietet, eine sinnvolle Visualisierung zu erstellen, die ein guter Kompromiss aus Einfachheit und Komplexität ist. Mit 4 Bit lassen sich 16 Befehle im ROM ablegen; das genügt, um ein kleines Programm ablaufen zu lassen. Da jede Leitung später als einzelne Grafik für das Simulationsprogramm erstellt werden muss, verdoppelt sich bei 8 Bit die Anzahl und damit der Aufwand beträchtlich, ohne einen erkennbaren Vorteil zu bringen.Der Bus besteht aus 8 Bit, getrennt in jeweils 4 Bit für Befehle und 4 Bit füt Daten (bzw. Adressen). Programm-daten werden im ROM, Daten im RAM abgelegt. Durch diese saubere Trennung wird es später einfacher zu verfolgen, was genau wann passiert. Logisim hat viele fertige Komponenten wie zum Beispiel FlipFlops, Pro-grammzähler, Multiplexer und Decoder. Dies macht es einfach, in kurzer Zeit eine funktionierende Schaltung zusammenzuklicken. Aber leider sieht man dann nicht, wie diese aufgebaut ist. Also müssen alle verwende-ten fertigen Elemente durch nachgebaute Komponenten ersetzt werden, um die Vorgänge überall bis auf das NAND-Gatter hinunter zu zeigen. Die fertige Logisim-Schaltung dient allerdings nur als Blaupause. Die eigent-liche Arbeit beginnt erst danach: Aus der Simulation soll ein Programm erstellt werden, das es dem nicht-tech-nikaffinen Benutzer ermöglicht, online in seinem Tempo und seinem Wissensdurst angepasst die Struktur zu erforschen. Das Programm soll dabei als eine Art Index dienen, zu dem man jederzeit zurückkehren kann, um an jeder beliebigen Stelle in die gewünschte Detailtiefe abzutauchen. Die Grenze liegt bei der digitalen Logikebene – die darunterliegende Implementierung auf Ebene der Elektrotechnik wird nicht weiter berück-sichtigt, da dies den Rahmen sprengen würde.


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

3.3 Die KomponentenNachfolgend werden die einzelnen Komponenten beschrieben, die im Simulationsprogramm zum Einsatz kommen. Die Architekur ist bewusst einfach gehalten und setzt sich zusammen aus einem Steuerwerk (Cont-rol Unit), zwei Registern, einem Rechenwerk (Arithmetic Logic Unit inklusive Akkumulator) sowei einer nur am Rande integrierten Eingabe (als Keyboard) und Ausgabe (als Display). Eingabe und Ausgabe werden als „Blackboxen“ behandelt: Es wird nicht weiter darauf eingegangen, wie diese die Informationen selber verarbei-ten. Externe Geräte wie zum Beispiel Festplatten oder Drucker werden nicht weiter betrachtet.

Com

puter

Speicher

ROM RAM

Prozessor CPU

SteuerwerkCU

Control Unit

Register Rechenwerk

ALUArithmetic Logic Unit

Output

Input

Bus

External Harddisk

Printer

Architektur

Abb. 16: Architektur des geplanten Simulationsprogramms

Da das Simulationsprogramm für pädagogische Zwecke eingesetzt werden soll, hält es sich nicht streng an eine bestimmte Architektur wie beispielsweise Harvard oder Von Neumann. Im Prinzip handelt sich um eine Mischform: Der Speicherbereich besteht bewusst aus RAM (Daten) und ROM (Programme), um den Unter-schied zwischen flüchtigem und nichtflüchtigem Speicher zu erklären und den Bezug zu „Embedded Systems“ aufzuzeigen, in denen die Programmdaten fest im ROM gespeichert sind. Der Bus ist 8 Bit breit und getrennt in 4 Bit Befehlscode und 4 Bit Daten respektive Adresscode. Die Verarbeitung in den einzelnen Komponenten ist auf 4 Bit beschränkt.

Bei der Darstellung der Symbole wird bewusst die amerikanische Form und nicht die Norm nach IEC (Inter-national Electrotechnical Commission) gewählt. In den in dieser Arbeit referenzierten Quellen werden durch-gehend die amerikanischen Symbole verwendet; sowohl in Büchern als auch in Logisim. Auf der deutschspra-chigen Wikipedia-Seite steht zu lesen: „Früher waren auf dem europäischen Kontinent die deutschen Symbole (rechte Spalte) verbreitet; im englischen Sprachraum waren und sind die amerikanischen Symbole (mittlere Spalte) üblich. Die IEC-Symbole sind international auf beschränkte Akzeptanz gestoßen und werden in der amerikanischen Literatur durchgängig ignoriert.“ [35]



Abb. 17: Typen von Logikgattern und Symbolik (Quelle: https://de.wikipedia.org/wiki/Logikgatter, besucht 04.07.2015)

3.3.1 Befehls-, Daten- und AdressbusBei dem Simluationsprogramm soll es sich um eine 4-Bit CPU handeln. Für den Bus werden 8 Leitungen benötigt, wobei die ersten 4 Bits für den sogenannten Opcode reserviert werden und die verbleibenden 4 Bits für die Daten (rsp. Adressen). Die verwendeten Instruktionen werden unter 3.4.1 „Befehlssatz“ auf Seite 38 ausführlich beschrieben.

3.3.2 LogikgatterDigitale Schaltungen sind Hardware-Komponenten, mit deren Hilfe binäre Informationen manipuliert wer-den. Sie werden mittels Transistoren und komplexen Verbindungen implementiert, welche zusammen „Integ-rierte Schaltung“ genannt werden. Eine einzelne Schaltung nennt man „Logikgatter“ ([1], S.38). Ein moderner Computer hat mittlerweile Millionen (bei der GPU „Kepler GK110“ von Nvidia sind es sogar schon 7,1 Milliar-den [36]) dieser Gatter verbaut: jedes erfüllt eine spezifische Aufgabe, die in Kombination mit anderen Gattern und Schaltungen komplexe Abläufe realisiert. Für das Simulationsprogramm dieser Arbeit kommen folgende Gatter zum Einsatz: NAND, AND, OR, XOR und NOT (Inverter).

Abb. 18: NAND-Gatter (erstellt in Logisim)

Das NAND-Gatter ist das wichtigste Gatter überhaupt, die „Mutter aller Gatter“ sozusagen. Mit dem NAND-Gatter lassen sich alle anderen Gatter nachbilden, siehe auch Abb. 19. Der Ausgang (out) ist immer



aktiv, solange nicht beide Eingänge „A“ und „B“ gleichzeitig aktiv sind. Die Wahrheitstabellen der verschiede-nen Gatter sind wie folgt:

NAND AND OR XOR NOTA B out A B out A B out A B out A out0 0 1 0 0 0 0 0 0 0 0 0 0 11 0 1 1 0 0 1 0 1 1 0 1 1 00 1 1 0 1 0 0 1 1 0 1 11 1 0 1 1 1 1 1 1 1 1 0

Tab. 3: Logikgatter im Vergleich

Abb. 19: Gatter und die entsprechenden Umsetzungen mit NAND-Gattern (erstellt in Logisim)

Die Kunst ist es, bei der Implementierung mit so wenig Gattern wie möglich auszukommen, um die Material- und Produktionskosten möglichst tief zu halten.

3.3.3 SpeicherUm einen Computer überhaupt Berechnungen ausführen zu lassen, ist es nötig, Informationen speichern zu können. Die kleinste Informationseinheit ist das Bit. Um den Zustand eines Bits (also 0 oder 1, respektive „Strom fliesst nicht“ oder „Strom fliesst“) festzuhalten, wird eine Schaltung wie in Abb. 20 gezeigt, benötigt.



Abb. 20: 1-Bit Speicher (erstellt in Logisim, ([37], S.24))

Die Funktionsweise ist wie folgt: Der momentane Zustand von Abb. 20 zeigt, dass beim Ausgang von Gatter A Strom fliesst, da „Input“ und „Set“ nicht aktiv sind. Auch bei Gatter B fliesst Strom beim Ausgang, weil „Set“ nicht aktiv ist. Der Ausgang von Gatter D ist aktiv, weil einer der beiden Eingänge inaktiv ist. Der Ausgang von Gatter D wird wiederum an einen Eingang von Gatter C geleitet. Somit haben beide Eingänge bei Gatter C Strom, dadurch ist der Ausgang von Gatter C inaktiv, also ist „Output“ 0. Wenn nun „Set“ aktiviert wird, ohne dass „Input“ aktiv ist, ändert sich der Ausgang von Gatter B zu inaktiv, weil jetzt beide Eingänge aktiv sind. Da sich aber Gatter D davon unbeindruckt zeigt (sein Ausgang bleibt inaktiv, auch wenn kein Eingang aktiv ist), ändert sich am Zustand von Gatter C nichts, also bleibt auch „Out-put“ auf 0. Wenn „Input“ aktiviert ist und danach „Set“ aktiviert wird, sieht es anders aus: Jetzt hat Gatter A an beiden Eingängen Strom, also ist sein Ausgang inaktiv. Ein Eingang von Gatter C (von Gatter A kommend) ist nun ebenfalls inaktiv. Der Ausgang von Gatter B ist aktiv, weil nur ein Eingang aktiv ist. Somit ist sein Ausgang in-aktiv, wird in Gatter C geführt, welches nun beide Eingänge inaktiv hat. Dies wiederum schaltet den Ausgang von Gatter C auf aktiv und führt diesen gleich wieder als Eingang zu Gatter D. Somit ist „Output“ 1. Wenn nun „Set“ wieder deaktiviert wird, spielt es keine Rolle, welchen Zustand “Input“ hat: „Output“ behält seinen Wert, solange der Strom fliesst ([37], S.24). Sobald Speicherelemente ins Spiel kommen, spricht man von „Sequential Circuits“, weil nun der Zustand zu einem bestimmten Zeitpunkt gespeichert werden kann. Es wird unterschieden zwischen „Latches“ und „Flip Flops“, welche es wiederum in verschiedenen Formen gibt: SR-Latches, D-Latches, SR-Flip Flops, Edge-Triggered Flip Flops usw. Der Hauptunterschied zwischen Latches und FlipFlops liegt in der Anzahl Eingänge und der Art und Weise, wie diese den binären Zustand beeinflussen. Die grundlegendsten Elemente sind Latches, welche in Flip Flops eingesetzt werden ([1], S.220-230).

Abb. 21: 4-Bit Speicher (erstellt in Logisim, ([37], S.40))



Will man mehr als nur ein einzelnes Bit speichern, werden mehrere dieser 1-Bit Speicher zu neuen Einheiten kombiniert, wie in Abb. 21 dargestellt (Das „M“ steht für Memory).

Abb. 22: 4-Bit Register (erstellt in Logisim, ([37], S. 40))

Um die Kontrolle zu haben, ob und zu welchem Zeitpunkt die gespeicherten Bits zu Verfügung gestellt werden sollen, wird an die vier Ausgänge noch ein sogenannter „Enabler“ ([37], S.40) angehängt. Erst wenn dessen „Enable“ aktiv ist (siehe Abb. 22) ist, werden die gespeicherten Bits durchgelassen und können dort verwendet werden, wo sie benötigt werden.

Abb. 23: 4-Bit RAM (erstellt in Logisim, ([37], S.52))



Vier 1-Bit Speicherelemente, kombiniert mit einem 4-Bit Enabler, ergeben zusammen ein 4-Bit Register, einen der elementarsten und wichtigsten Bausteine eines Computers. Diese Register werden benötigt, um alle Informationen von laufenden Programmen und Daten zwischenzuspeichern, bevor sie zum Teil wieder auf nichtflüchtigen Speichermedien wie zum Beispiel Festplatten abgelegt werden. Im RAM, dem „Random Access Memory“, sind unzählige dieser Register verbaut. Im Beispiel des geplanten Simulationsprogramms sind es zum Glück nur 16, da es mit vier Bit nicht mehr als 16 (24) Adressen gibt. Im RAM benötigt es zu den Registern, welche Daten oder Befehlscode enthalten, noch das sogenannte MAR (Memory Adress Register), um entscheiden zu können, von welchem Register man Werte holen kann oder in welches Register anstehende Daten gespeichert werden sollen.

3.3.4 Auswahlschaltungen

Abb. 24: 4-Bit Enabler (erstellt in Logisim, ([37], S. 40))

Die Aufgabe des Enablers ist es, Daten entweder durchzulassen oder nicht. Dazu werden AND-Gatter benötigt, welche einfach wie in Abb. 24 gezeigt zu der benötigten Anzahl Bits kombiniert werden. Die Enabler-Schaltung kommt in praktisch allen Schaltungen des Simulationsprogrammes vor.



Abb. 25: 4x2 Multiplexer (erstellt in Logisim)

Der Multiplexer lässt nach bestimmten Regeln nur einen von mehreren Datenströmen durch. In Abb. 25 stehen vier Eingänge an. Mittels den „Schaltern“ S1 und S2 wird entschieden, welcher von diesen Eingängen weitergeleitet wird. Die Zustände sind wie folgt: S1=0, S2=0 -> Eingang 1, S1=1, S2=0 -> Eingang 2, S1=0, S2=1 -> Eingang 3 und S1=1, S2=1 -> Eingang 4. Natürlich werden die Eingänge nur weitergeleitet, wenn „Enable“ aktiv ist.

Abb. 26: 4x2 Multiplexer, 4 Datenbits (erstellt in Logisim)

Für das Simulationsprogramm werden vier Datenbits benötigt, also muss der Multiplexer an den vier Eingän-gen auch jeweils vier Bits durchlassen. Dies wird erreicht, indem wie in Abb. 26 gezeigt, vier 1-Bit Multiplexer (siehe Abb. 25) eingesetzt werden. An diesem Beispiel kann man bereits sehr schön erkennen, wie mittels Kombination von mehreren einfachen Schaltungen immer komplexere Schaltungen erstellt werden.



Abb. 27: 2x4 Dekoder (erstellt in Logisim, ([37], S.48))

Der Dekoder nutzt zwei Eingänge und aktiviert entsprechend der Codierung einen der vier Ausgänge. Die Zustände in Abb. 27 sind wie folgt: S1=0, S2=0 -> Ausgang 1, S1=1, S2=0 -> Ausgang 2, S1=0, S2=1 -> Ausgang 3, S1=1, S2=1 -> Ausgang 4. Auch hier kommt wieder der Enabler zum Einsatz, um bei Bedarf die Ausgänge zu unterdrücken respektive durchzulassen.

3.3.5 ArithmetikBei den nun folgenden arithmetischen Schaltungen werden Bits miteinander verglichen, addiert und subtrahiert.

Abb. 28: Komparator (erstellt in Logisim, [38])

Der Komparator (Abb. 28) vergleicht zwei Eingänge und aktiviert eine Ausgangsleitung, falls die Werte der beiden Eingänge gleich sind.



Abb. 29: 4-Bit Zähler (erstellt in Logisim, [38])

Der 4-Bit Zähler (Abb. 29) kommt im Simulationsprogramm als Programmzähler zum Einsatz. Das von „Clock“ kommende Signal setzt zuerst das Bit im ersten Flip Flop (A) auf 1 (Ausgänge = 0001 -> 1). Beim nächsten Takt wird das erste Flip Flop (A) wieder deaktiviert, dafür das nächste (B) aktiviert (Ausgänge = 0010 -> 2). Beim dritten Takt wird das erste Flip Flop (A) wieder aktivert, das zweite (B) bleibt davon unberührt (Ausgänge = 0011 -> 3). Beim vierten Takt wird das erste Flip Flop (A) wieder deaktiviert, das zweite (B) eben-so, dafür wird nun das nächste Flip Flop (C) aktivert (Ausgänge = 0100 -> 4). Dies geht nun immer so weiter bis alle Ausgänge gemeinsam aktiv sind, danach werden beim nächsten Takt alle Flip Flops wieder deaktivert und das Ganze geht von vorne los.Mit dem Eingangsschalter „0=inc, 1=set“ lässt sich steuern, ob die Eingänge 1-4 berücksichtigt werden sollen. Falls ja, wird der Zählprozess übergangen und der anstehende Wert der Eingänge 1-4 direkt in die Flip Flops geschrieben. Dies wird im Simulationsprogramm eingesetzt, um bei Jump-Befehlen den Programmzähler zu überschreiben.



Abb. 30: Halbaddierer (erstellt in Logisim, ([37], S.79))

Beim Halbaddierer (Abb. 30) werden zwei Bits zusammengezählt. Da es im Binärsystem nur 0 und 1 gibt, kann das Resultat von 1+1=2 nicht dargestellt werden. Das korrekte Ergebnis wäre 10, da aber nur ein Bit am Ausgang ankommt, wird der Übertrag im sogenannten „Carry-Bit“ festgehalten.

Abb. 31: Volladdierer (erstellt in Logisim, ([37], S.79))

Zwei Halbaddierer werden zu einem Volladdierer (Abb. 31) kombiniert. Dieser hat nun zusätzlich zu den zwei Eingängen A und B auch noch einen Eingang für das Carry-Bit eines weiteren Volladdierers. Er selber gibt wiederum sein eigenes Carry-Bit weiter und man kann so bereits gut erahnen, dass sich mehrere Volladdierer zu einem n-Bit Addierer zusammensetzen lassen.



Abb. 32: 4-Bit Addierer (erstellt in Logisim, ([37], S.79))

Für das Simulationsprogramm werden vier Datenbits benötigt, in Abb. 32 kann man sehen, dass vier Voll- addierer (welche ihrerseits aus zwei Halbaddierern bestehen), zu einem 4-Bit Addierer zusammengesetzt wur-den. Mit dem „Sign Bit“-Eingang kann man die Funktionalität vom Addierer zum Subtrahierer umschalten. Was bei dieser Schaltung nicht berücksichtigt wurde: Bei grossen Zahlen kommt es beim Addieren zu einem Überlauf. Dies wird jedoch zugunsten der Einfachheit des Simulationsprogrammes bewusst vernachlässigt.

Abb. 33: ALU „Arithmetic Logic Unit“ (erstellt in Logisim, [34])

In der ALU findet man die besprochenen Schaltungen wieder: Der Komparator (1) erkennt, ob und um welchen ALU-Befehl es sich handelt. Er ist mit dem Multiplexer (7) verbunden und lässt aufgrund des Befehl-codes einen der vier Ausgänge der 4-Bit Addierer (2-5) durch. Der erste Addierer (2) addiert, der zweite (3) sub-


ZHAW - Masterarbeit - Christian Kaegi - 28.8.2015 - v2.0.3 Simulation in Logisim bauen

trahiert (das Sign Bit ist 1), der dritte (4) inkrementiert um 1 und der vierte Addierer (5) dekrementiert um 1. Bei einer ALU-Operation werden immer alle Addierer angesprochen, aber nur ein Resultat findet den Weg durch den Multiplexer zum Ausgang. Im zweiten Komparator (6) werden die 2 Eingänge (A+D) miteinander verglichen: sind sie gleich, ist „equal“=1, ansonsten bleibt es 0. Es gibt in einer ALU natürlich noch weit mehr Ele-mente, auf diese wird aber zugunsten der Einfachheit im Simulationsprogramm verzichtet. Im Zusammenhang mit der ALU muss noch ein spezielles Register erwähnt werden: der Akkumulator. Dieser wird auch als Ziel- register bezeichnet, welches jeweils das Resultat der ALU-Operation enthält ([1], S. 465).

3.3.6 TaktgeberDer Taktgeber (oder die „Clock“) ist sozusagen das Herz des Computers. Er produziert ein periodisches Takt-signal und sorgt dafür, dass alle Schaltungen innerhalb eines Computers synchron zueinander mit Stromim-pulsen versorgt werden. Pro Sekunde werden mehr als eine Milliarde Taktsignale gesendet; moderne CPUs haben mittlerweile Taktfrequenzen von über 2 GHz [39]. Die Frequenz wird in Hertz gemessen: 1 Sekunde = 1 Hz.

Abb. 34: Taktsignal (Quelle: http://de.f-alpha.net/elektronik/digitale-elektronik/flip-flop/los-gehts/experiment-8-master-slave/, besucht 19.6.2015)

Als Taktzyklus bezeichnet man den Zeitraum zwischen zwei steigenden Flanken, siehe Abb. 34. Pro Takt-zyklus kann somit genau ein Befehl ausgeführt werden. Erst durch die unvorstellbare Geschwindigkeit der Taktsignale wird der Eindruck erweckt, der Computer sei intelligent. In Wahrheit ist er einfach nur unfassbar schnell, die einzelnen Schritte sind für sich selber betrachtet banal. Darin liegt das eigentliche Geheimnis des Computers: Die Geschwindigkeit gepaart mit der extrem hohen Anzahl von Transistoren auf kleinstem Raum ermöglichen komplexeste Berechnungen in kürzester Zeit.

3.4 Simulation in Logisim bauenAls Basis für die Analyse des Simulationsprogramms in Logisim wird, wie unter 3.2 „Lösungsansatz“ auf Seite 24 bereits erwähnt, die Serie „MM4001 - 4 Bit CPU Step by Step“ [34] herangezogen. Bei dieser Serie wird der Aufbau einer 4-Bit CPU Schritt für Schritt erklärt. Dabei geht es nicht darum, die Schaltung eins zu eins nachzubauen, sondern die Funktionsweise zu verstehen. Logisim bietet viele fertige Bauelemente an: ROM, RAM, Flip Flops, Multiplexer, Dekoder, Komparatoren, Addierer, Zähler usw. Es ist sehr verlockend, diese Schaltungen so einzusetzen wie sie sind, leider handelt es sich dann aber um „Blackboxen“. Im finalen Simulationsprogramm soll es jedoch möglich sein, an beliebiger Stelle bis hinunter zum einzelnen Gatter die Funktionsweise zu sehen und interaktiv auszuprobieren. Daher ist es erforderlich, alle Fertigkomponenten mit Gattern nachzubauen. Bei den Speicherbausteinen wie Register, Flip Flop, RAM und ROM innerhalb von Logisim muss aber trotzdem auf die Fertigkomponenten zurückgegriffen werden, da Logisim im Startzustand einen Fehler auf den Leitungen anzeigt (siehe Abb. 35).



Abb. 35: Fehler auf den Leitungen (erstellt in Logisim)

Die einzelnen Komponenten wurden bereits vorgestellt (3.3 „Die Komponenten“ auf Seite 25), die fertige Simulation in Logisim sieht dann so aus wie in Abb. 36. Es wurde versucht, jede einzelne Leitung zu zeigen. Dies war nicht überall möglich; beim oberen ODER-Gatter (rot markiert) werden zum Beispiel 16 Leitungen hineingeführt, was schon aus Platzgründen in Logisim problematisch ist. Deshalb wurde, wo nötig, auf den sogenannten „Verteiler“ zurückgegriffen, um mehrere Leitungen zu einer einzelnen zusammenzufassen. In der Abbildung (Abb. 36) sind diese als schwarze Linien erkennbar. Im finalen Simulationsprogramm wird dann aber versucht, wirklich jede einzelne Leitung auch als solche erkennbar zu machen.Im rechten unteren Teil von Abb. 36 sieht man den „Keyboard Buffer“ und den „Frame Buffer“. Ursprünglich war geplant, eine Tastatureingabe zu ermöglichen. Dies hätte aber bedingt, auch einen Interrupt einzubauen. Das wiederum hätte die Komplexität unverhältnismässig erhöht, daher wurde darauf verzichtet. Es ist aber möglich, den Keyboard Buffer abzufragen, um eingegebene Tastaturzeichen abzuholen und in ein Register zu speichern. Ebenso kann man einen Wert an den Frame Buffer senden, welcher dann die Bildschirmausgabe bedienen kann. Dies wurde als guter Kompromiss angesehen, um die Ein- und Ausgabe darzustellen, ohne die Komplexität zu erhöhen. Da die Adressbreite im Simulationsprogramm auf vier Bits beschränkt ist, sind auch nur 16 Befehle möglich, damit kann man natürlich keine umfangreichen Programme ablaufen lassen.



Abb. 36: Fertige Vorlage für das Simulationsprogram (erstellt in Logisim)

3.4.1 BefehlssatzDamit der Computer überhaupt irgend etwas Sinnvolles vollbringt, ist es nötig, dass man ihm genau sagt, was er tun soll. Es muss bestimmt werden, zu welchem Zeitpunkt in einer bestimmten Reihenfolge jede Leitung mit Strom versorgt wird, um dann im richtigen Moment die richtigen Gatter ansprechen zu können, damit diese im Zusammenspiel die Bits an die entprechenden Orte schicken respektive speichern können.Der Bus ist acht Bit breit, so viele Bits stehen insgesamt zur Verfügung. Der Computer benötigt einerseits einen Befehl, damit er weiss, was er machen soll, und andererseits Daten, die er verarbeiten muss. Dazu wird der Bus in zwei Teile zerlegt: die ersten vier Bits werden für den Befehl genutzt, die restlichen vier Bits für die Daten oder Adressen. Somit sind 16 verschiedene Befehle möglich (24). Der Computer kann pro Taktzyklus genau einen Befehl verarbeiten. Da er nur 0 und 1 versteht, könnten ein paar Programmzeilen also wie folgt aussehen:

Schritt Befehl Erklärung1 0010 0010 Initialisiere den Akkumulator mit 22 0001 0100 Bewege den Wert des Akkumulators in das Register 13 0010 0001 Initialisiere den Akkumulator mit 1



4 0011 0000 Addiere den Wert des Registers 1 zum Wert des Akkumulators und speichere das Resultat im Akkumulator

5 0100 0000 Speichere den Wert des Akkumulators im RAM in Zelle 06 0111 0000 Schicke den Wert des Akkumulators zum Display7 0010 0010 Initialisiere den Akkumulator mit 28 0011 0000 Addiere den Wert des Registers 1 zum Wert des Akkumulators9 0100 0001 Speichere den Wert des Akkumulators im RAM in Zelle 110 0111 0000 Schicke den Wert des Akkumulators zum Display11 0101 0000 Lade den Wert von Zelle 0 im RAM in den Akkumulator12 0011 0001 Subtrahiere den Wert des Registers 1 vom Wert des Akkumulators13 0101 0001 Lade den Wert von Zelle 1 im RAM in den Akkumulator14 0011 0001 Subtrahiere den Wert des Registers 1 vom Wert des Akkumulators15 0111 0000 Schicke den Wert des Akkumulators zum Display16 0001 1000 Bewege den Wert des Akkumulators in das Register 2

Tab. 4: Beispiel von Programmzeilen

Die binäre Form, in welcher die Befehle definiert sind, wird als „Maschinensprache“ bezeichnet. Für den Pro-grammierer ist es aber ziemlich umständlich, nur mit Befehlen in Form von Nullen und Einsen zu arbeiten. Daher wurde eine symbolische Sprache entwickelt, welche die „Opcodes“ (Operation Codes) und die Daten resp. Adressen in textlicher Kurzform darstellt: die sogenannte „Assemblersprache“ ([1], S.461). Diese Sprache ist eng an den jeweiligen Prozessor geknüpft. Nachfolgend nochmals die Programmzeilen des vorangegange-nen Beispiels; dieses Mal zusätzlich mit den programmiererfreundlicheren Assemblerbefehlen:

Schritt Befehl Assembler Erklärung1 0010 0010 LDI 2 Initialisiere den Akkumulator mit 22 0001 0100 MOV R1 Bewege den Wert des Akkumulators in das Register 13 0010 0001 LDI 1 Initialisiere den Akkumulator mit 14 0011 0000 ADD Addiere den Wert des Registers 1 zum Wert des Akkumulators und

speichere das Resultat im Akkumulator5 0100 0000 SDA 0 Speichere den Wert des Akkumulators im RAM in Zelle 06 0111 0000 OUT A Schicke den Wert des Akkumulators zum Display7 0010 0010 LDI 2 Initialisiere den Akkumulator mit 28 0011 0000 ADD Addiere den Wert des Registers 1 zum Wert des Akkumulators9 0100 0001 SDA 1 Speichere den Wert des Akkumulators im RAM in Zelle 110 0111 0000 OUT A Schicke den Wert des Akkumulators zum Display11 0101 0000 LDA 0 Lade den Wert von Zelle 0 im RAM in den Akkumulator12 0011 0001 SUB Subtrahiere den Wert des Registers 1 vom Wert des Akkumulators13 0101 0001 LDA 1 Lade den Wert von Zelle 1 im RAM in den Akkumulator14 0011 0001 SUB Subtrahiere den Wert des Registers 1 vom Wert des Akkumulators15 0111 0000 OUT A Schicke den Wert des Akkumulators zum Display16 0001 1000 MOV R2 Bewege den Wert des Akkumulators in das Register 2

Tab. 5: Beispiel von Programmzeilen, zusätzlich mit Assemblerbefehlen



Der Akkumulator ist das Zielregister für die Berechnungen in der ALU, daher muss es bei bestimmten Be-fehlen nicht explizit erwähnt werden. In der vorangegangengen Tabelle ist zum Beispiel bei dem Befehl ADD (Schritt 4) keine Zielangabe nötig, weil es in der Architektur dieses Simulationsprogramms nur möglich ist, Werte des Registers 1 zum Akkumulator zu addieren. Ebenso kann bei INC und DEC die Zielangabe weggelassen werden, weil es sich nur um den Akkumulator handeln kann. Der Entwickler einer Assemblersprache für einen speziellen Prozessor ist prinzipiell frei in der Gestaltung der Sprachlogik; wichtig ist jedoch, dass alles sauber dokumentiert ist [40], damit der Programmierer das Maximum aus der Hardware herausholen kann.Logisim bietet die Möglichkeit, Code in hexadezimaler Form in das ROM-Element zu laden. Dadurch sind die eben aufgeführten Programmzeilen sogar lauffähig in der Simulation. Das Programm sieht schlussendlich aus wie in Abb. 37.

Abb. 37: Programm in hexadezimaler Form für Logisim (erstellt in Textmate)

3.4.1.1 Erläuterung der Befehle

Im Folgenden werden die einzelnen Befehle erklärt. Diese entstammen grösstenteils ebenfalls den Tutorials von „Minecraftmonkeys“ [34], allerdings nur zum Teil: Die Mnemonics wurden den gängigen Assembler- befehlen angepasst und einige sind zusätzlich hinzugekommen (JE, JNE, JMP), da diese in den unvollständig zur Verfügung stehenden Tutorials nicht vorkommen. Die Aufteilung der 8 Bits ist wie folgt (die vorderen 4 Bits = Opcode, die hinteren 4 Bits = Daten/Adresse):

Opcode Daten/Adresse0000 0000

Der Opcode hat 11 Bedeutungen:

Opcode Mnemonic Erklärung0000 NOP „No Operation“: Keine Aktivität0001 MOV „Move“: Bewege den Wert des Akkumulators ins Register 1 oder 20010 LDI „Load Immediate“: Initialisiere das Akkumulatorregister mit einem Wert0011 ALU „Arithmetic Logic Unit“: Aktiviere die ALU

Hinweis: Der Befehl ALU wird so nicht direkt verwendet: In Verbindung mit dem Daten-/Adressteil wird er ausgelöst durch ADD, SUB, INC und DEC (siehe Tab. 7).

0100 SDA „Store Data“: Speichere Wert des Akkumulators im RAM0101 LDA „Load Data“: Lade Wert vom RAM in den Akkumulator0110 INP „Input“: Hole Wert aus dem Keyboard Buffer0111 OUT „Output“: Sende Wert an den Frame Buffer (Display)1000 JE „Jump Equal“: Springe zu einer bestimmten Codezeile, falls der Wert im Register 1

und dem Akkumulator gleich ist.1001 JNE „Jump Not Equal“: Springe zu einer bestimmten Codezeile, falls der Wert im

Register 1 und dem Akkumulator nicht gleich ist.1010 JMP „Jump“: Springe zu einer bestimmten Codezeile

Tab. 6: Bedeutungen des Opcodes



Der Daten/Adress-Teil hat abhängig vom Opcode verschiedene Bedeutungen:

In Kombination mit (Opcode)...

Daten/ Adresse

Erklärung Beispiel Maschinencode

Beispiel Assemblercode

...MOV -> 0001 0100 Wert des Akkumulators ins Register 1 kopieren 0001 0100 MOV R1

1000 Wert des Akkumulators ins Register 2 kopieren 0001 1000 MOV R2

...LDI -> 0010 0000-1111 Wert unmittelbar in den Akku-mulator laden 0010 0110 LDI 6

...ALU -> 0011 0000

Wert des Registers 1 zum Wert des Akkumulators addieren und Ergebnis im Akkumulator speichern

0011 0000 ADD

0001

Wert des Registers 1 vom Wert des Akkumulators subtrahieren und Ergebnis im Akkumulator speichern

0011 0001 SUB

0010 Wert des Akkumulators um 1 erhöhen (inkrementieren) 0011 0010 INC

0011 Wert des Akkumulators um 1 erniedrigen (dekrementieren) 0011 0011 DEC

...SDA -> 0100

...LDA -> 0101 0000-1111

Adresse der Speicherzelle (Re-gister) im RAM, a) in welche der Wert des Akkumulators gespei-chert wird oder b) von welcher der Wert in den Akkumulator geladen wird)

0100 00110101 1000

SDA 3LDA 8

...INP -> 0110 0011 Wert des Keyboard Buffers in den Akkumulator kopieren 0110 0000 INP A

0111 Wert des Keyboard Buffers ins Register 1 kopieren 0110 0100 INP R1

1011 Wert des Keyboard Buffers ins Register 2 kopieren 0110 1000 INP R2

...OUT -> 0111 0000 Wert des Akkumulators an den Frame Buffer schicken 0111 0000 OUT A

0110 Wert des Registers 1 an den Frame Buffer schicken 0111 0100 OUT R1

1001 Wert des Registers 2 an den Frame Buffer schicken 0111 1000 OUT R2

...JE -> 1000 ...JNE -> 1001 ...JMP -> 1010

0000-1111 Zeilennummer im Programm-code

1000 00111001 01001010 1100

JE 3JNE 4JMP 12

Tab. 7: Bedeutung des Daten- und Adressteils in Zusammenhang mit dem Opcode

3.4.1.2 Zeichencode

Der ursprüngliche ASCII-Code (American Standard Code for Information Interchange) wurde 1963 veröffentlicht [41]. Er weist spezifische Zeichen jeweils einer 7-Bit Adresse zu. Mit diesen 7 Bit lassen sich 128 Zeichen darstellen (27), siehe Abb. 38. Damit wurde ein Standard festgelegt, wie Zeichen in Computern welt-weit einheitlich enkodiert werden sollten.



Abb. 38: ASCII-Tabelle (Quelle: http://worldpowersystems.com/J/codes/X3.4-1963/page5.JPG, besucht 21.6.2015)

Das Simulationsprogramm dieser Arbeit soll ebenfalls die Möglichkeit bieten, Code im Frame Buffer als Zei-chen darzustellen. Dazu soll gezeigt werden, wie das Display die einzelnen Schriftzeichen im Frame Buffer entschlüsselt und als Buchstaben ausgibt. Mit vier Bit sind jedoch nur 16 Zeichen möglich, daher wurde ein eigener Zeichencode kreiert, damit wenigstens ein „WELCOME!“ möglich ist. Dementsprechend wurde eine kleine Spezifikation erstellt:

Code Zeichen Code Zeichen0000 A 1000 I

0001 B 1001 L

0010 C 1010 O

0011 D 1011 M

0100 E 1100 S

0101 F 1101 W

0110 G 1110 !

0111 H 1111 (BLANK)

Tab. 8: Eigener Zeichencode

Damit ist ein „WELCOME!“ wie folgt umsetzbar:

1101 0100 1001 0010 1010 1011 0100 1110

W E L C O M E !

Tab. 9: WELCOME! mit eigens erstelltem Zeichencode


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

3.5 Anforderungen an das Simulationsprogramm Im folgenden werden die Anforderungen an das Simulationsprogramm spezifiziert, die sich aus der gesam-melten Erfahrung mit der Simulation in Logisim ergeben haben. Mittlerweile gibt es auch einen Projekt- namen, der im weiteren Verlauf dieses Berichts verwendet wird: „TurtlebiteSim“. Der Name Turtlebite existiert bereits länger und wurde vom Autor dieses Berichts schon für andere Zwecke verwendet. Die Bedeutung und Herkunft wird im Rahmen dieser Arbeit nicht weiter erläutert, da es keine Relevanz hat für diesen Bericht. „Sim“ steht für Simulation.

Funktionale Anforderungen• Es sollen verschiedene (Assembler-) Programme ausgewählt werden können• Die Taktraten müssen in einem Bereich von 1 Hertz bis 1 Kilohertz geändert werden können

• Dem Thema „Takt“ soll spezielle Beachtung geschenkt werden, da hier das eigentliche Geheimnis des Computers liegt. Anhand eines Textes auf der Companion-Website soll ein Vergleich „Mensch-Computer“ gemacht werden, der die Geschwindigkeit vorstellbar macht.

• Der Taktgeber soll jederzeit pausiert werden können.• Der Benutzer soll selber manuell den Takt in Einzelschritten auslösen können.• Der Benutzer soll zu einem beliebigen Zeitpunkt die gerade aktive Instruktion anschauen und ändern

können. • Der Benutzer soll in die Benutzeroberfläche „einzoomen“ können (die Navigation ausgenommen).• Der Benutzer soll in einzelne Bauteile einzoomen können, bis hinunter zum einzelnen Gatter.

Die betroffenen Komponenten sind hier aufgelistet:• Comparator• Decoder• Enabler• Programcounter• Register• Multiplexer• ALU• Accumulator• RAM• ROM

• Der Benutzer soll den Inhalt des ROMs anschauen können:• die einzelnen 16 Befehle werden aufgelistet mit Befehlsnummer, Assemblercode,

Maschinencode, Hex-Wert und Beschreibungstext.• Der Benutzer soll zwischen verschiedenen Beispielprogrammen wählen können.• Der Benutzer soll einzelne Befehle auswählen und ändern können.• Der Benutzer soll Programme auf die lokale Festplatte speichern können.• Der Benutzer soll Programme von der lokalen Festplatte laden können.

• Der Benutzer soll jederzeit in jedem Bauteil das einzelne Element respektive Gatter interaktiv ausprobieren können.

• Es soll eine „Companion“-Website zur Verfügung stehen, die einerseits die Browserversion von Turtle- biteSim beherbergt und andererseits weiterführende Links und Erläuterungen bereithält.

• TurtlebiteSim erhebt nicht den Anspruch, innerhalb der Applikation Erklärungen zu den Schaltkreisen und Vorgängen abzugeben: es sollen aber an ausgewählten Stellen direkte Links zu gezielten Infor- mationen bereitgestellt werden.


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

Nicht-funktionale Anforderungen und Randbedingungen• TurtlebiteSim soll auf möglichst vielen Plattformen lauffähig sein, um viele Benutzer anzusprechen.• Es soll im Browser abrufbar sein.• Es soll auf Tablets (iOS und Android) als App installiert werden können.• Es soll auch international zur Verfügung gestellt werden und daher zwei Sprachen unterstützen: deutsch

und englisch.• Es soll sowohl mit dem Finger auf Touchscreens als auch mit der Maus bedienbar sein.• Das Benutzererlebnis soll „flüssig“ sein, also ohne Verzögerungen.• TurtlebiteSim soll intuitiv und einfach bedienbar sein.

3.6 Technologie-Evaluation

3.6.1 ZielplattformGemäss Anforderung soll TurtlebiteSim für eine breite Masse einfach zugänglich sein und auf verschiedenen Plattformen laufen.

3.6.2 JavaUnter diesem Aspekt kommt als erstes Java als mögliche Umsetzungs-Programmiersprache in Frage, da es plattformunabhängig ist und in der JVM (Java Virtual Machine) auf PC, Mac und Linux läuft. Java wurde vor genau 20 Jahren (1995) der Öffentlichkeit vorgestellt und wurde schnell beliebt: Bereits zwei Jahre später arbeiteten ungefähr 400‘000 Entwickler mit Java; es war zu dem Zeitpunkt bereits die Num-mer 2 der Programmiersprachen. Fünf Jahre nach der Veröffentlichung hatte Java sich vom anfäng-lichen Werkzeug für animierte Websites zu einer ernstzunehmenden Entwicklungsplattform für alle möglichen Geräte wie Smartcards, Kameras, Server, Pager usw. etabliert. 2010 war die Java-Entwickler- gemeinde bereits 4.5 Millionen gross, es gab schon 2.5 Milliarden javafähige Geräte [42]. Android, das Betriebssystem von Google für Smartphones und Tablets, basiert ebenfalls auf Java [43]. Damit wäre diese Programmiersprache eigentlich die perfekte Wahl für ein Programm, das auf PC, Mac, Linux und Android Tablets läuft. Apple iOS unterstützt Java nicht direkt, mit der RoboVM [44] scheint es allerdings mög-lich, Javacode auf iOS lauffähig zu machen. Diese Variante wurde allerdings für TurtlebiteSim nicht weiter in Betracht gezogen, da die RoboVM monatlich $19 kostet (es gibt zwar eine kostenlose Version, aber bei dieser fehlt der Debugger und der Interface Builder).

3.6.3 ActionscriptActionScript ist eine leistungsfähige, objektorientierte Programmiersprache. Ähnlich wie Java wird sie in einer virtuellen Maschine (der AVM – ActionScript Virtual Machine) auf dem jeweiligen Gastsystem (PC, Mac, Linux) ausgeführt: im sogenannten Flash Player. Die auch heute noch aktuelle Version 3 hatte ihren Ursprung im Flash Player 9 [45] [46]. Anfangen hatte alles um das Jahr 2000, als der Flash Player noch unter dem Namen „Future Splash Animator“ – ein Produkt der Firma Macromedia – hauptsächlich für vektorbasierte Animatio-nen im Internet eingesetzt wurde [47]. Der eigentliche Durchbruch von Flash begann allerdings erst nach der Übernahme von Macromedia durch Adobe Systems Inc. im Jahr 2005 [48]. Zu dieser Zeit schossen Websites, die auf Adobe Flash basierten, wie Pilze aus dem Boden. 2008 veröffentlichte Adobe „AIR“ (Adobe Integrated Runtime) [49]: Damit wurde es möglich, Applikationen auf Desktopsystemen auch ausserhalb des Browsers



auf verschiedenen Betriebssystemen lauffähig zu machen. 2010 folgte dann eine Version von AIR, die auch auf mobilen Geräten ausserhalb des Browsers funktionierte [50]. Auf ihrer Produkte-Website schreibt Adobe: „The Adobe® AIR® runtime enables developers to package the same code into native apps for Windows and Mac OS desktops as well as iPhone, iPad, Kindle Fire, Nook Tablet, and other Android™ devices, reaching the mobile app stores for over 500 million devices.“ [51]Aus dieser Sicht wäre ActionScript eigentlich prädestiniert, für TurtlebiteSim eingesetzt zu werden, wäre da nicht – einmal mehr – Apple. 2010 veröffentlichte Steve Jobs seine folgenschweren Gedanken zu Flash [52] und brachte damit die Technologie rund um den Flash Player ins Wanken. Obwohl mit der neuen Version von AIR Apps für mobile Geräte erstellt werden konnten, waren die Endbenutzer immer mehr der Meinung, dass Flash auf mobilen Geräten nicht mehr geduldet würde. Langsam fing man an, sich von Flash abzuwen-den. Als Entwickler (der Autor dieses Berichts spricht aus eigener Erfahrung) wurde es immer schwieriger, Kunden davon zu überzeugen, dass AIR auf Mobilgeräten nicht gleichbedeutend sei mit Flash. In den Köp-fen setzte sich immer mehr fest, dass man besser nativ für mobile Geräte entwickelt. Gleichzeitig tauchte HTML5 mit seinen neuen Möglichkeiten auf und begann, im Web die von Flash dominierten Bereiche (spe-ziell die Animationen), aufzuweichen. Mittlerweile ist es sogar verpönt, Flash im Web zu nutzen. Google hat in seinem Webbrowser „Chrome“ angefangen, Plugins zu deaktivieren. Flash läuft heute bereits nicht mehr standardmässig in diesem Browser; man muss es manuell aktivieren. Dadurch soll weniger Batteriestrom bei Laptops verbraucht werden [53]. In Zukunft sollen weitere Plugins verschwinden [54]. Nachdem auch You- tube Flash den Rücken kehrt und Videos im Web standardmässig mit HTML5 abspielt [55], scheint es keinen Grund mehr zu geben, im Web auf Flash zu setzen. Somit ist AIR zwar noch ein guter Kandidat, um Turtle- biteSim als App auf Android Tablets und iPads zu bringen, aber im Web sieht es rund um Flash düster aus. Obwohl vom technischen Standpunkt her betrachtet eine sehr gute Wahl, ist es wahrscheinlich besser, von ActionScript die Finger zu lassen: zu ungewiss ist seine Zukunft. Alex Stamos, Sicherheitschef von Facebook, twittert am 12. Juli 2015: „It is time for Adobe to announce the end-of-life date for Flash and to ask the browsers to set killbits on the same day.„ [56] Es scheint, als wäre Javascript die bessere Wahl für Webappli-kationen.

3.6.4 Javascript/HTMLAls das World Wide Web kreiert wurde, waren alle Websites statisch. Es gab keine Möglichkeit der Interaktion. Um mit einer Website interagieren zu können, musste zuerst eine eigene Programmiersprache entwickelt wer-den. Damit die Website direkt auf Eingaben des Benutzers reagieren konnte, war es nötig, dass die Program-miersprache auf dem Computer des Benutzers ausgeführt wurde und nicht auf dem Server. Zu damaliger Zeit waren die Verbindungen noch nicht so schnell, und es hätte viel zu lange gedauert, bei jeder Eingabe auf den Server zuzugreifen. Javascript entstand 1995, um sich genau diesem Problem anzunehmen. Der eigentliche Durchbruch gelang der Programmiersprache allerdings erst nach 2005, als Jesse James Garett [57] ein White Paper veröffentlichte, in welchem er den Begriff „Ajax“ prägte. Er beschrieb das Zusammenspiel verschiedener Technologien rund um Javascript, mit denen es möglich war, Daten in Webapplikationen im Hintergrund zu laden. Damit konnte das Neuladen kompletter Webseiten vermieden und dem Nutzer eine viel dynamischere Applikation zur Verfügung gestellt werden. Dies hat Javascript enormen Aufwind gegeben, und Frameworks wie jQuery [58] oder das neuere AngularJS [59] haben ihren Teil dazu beigetragen, Javascript populär zu machen.



Javascript hat nichts mit Java zu tun: Der Name war ganz am Anfang „LiveScript“, wurde aber wenig später in Javascript geändert, um von der Popularität von Java zu profitieren. Dadurch konnte mehr Aufmerksamkeit erzeugt werden: strategisches Marketing sozusagen! [60] Javascript ist eine eventgesteuerte Scriptsprache. Der Code ist in HTML-Seiten eingebettet und wird auf dem Computer des Endbenutzers im Browser ausgeführt. Javascript kann nicht direkt mit dem Server kommuni-zieren. Die Programmiersprache wird vor ihrer Ausführung nicht kompiliert, sondern interpretiert. [61]Da Javascript im Browser läuft, kann es theoretisch auf allen Geräten genutzt werden. Es muss sich allerdings zeigen, ob die Performanz der interpretierten Sprache für TurtlebiteSim ausreicht.

3.6.5 DartDart wurde 2011 in Aarhus, Dänemark der Öffentlichkeit vorgestellt. Zu dem Zeitpunkt war Javascript all- gegenwärtig. Dart wurde nicht als Konkurrenz angepriesen, sondern es sollte einfacher werden, grosse Applikationen für das Web zu erstellen. Dart ist eine objektorientierte Sprache, die wie Java Bibliotheken unterstützt und sich typensicher in gängigen IDEs (Integrated Runtime Environments) wie zum Beispiel Eclipse [62] oder IntelliJ [63] programmieren lässt. Dadurch ist es möglich, einen sauber strukturierten Code zu erstellen [64].Dart kann über die dart:io-Bibliothek direkt mit dem Server kommunizieren. Der Code kann kompiliert in einer eigenen virtuellen Maschine im Browser ausgeführt werden. Eine spezielle Browserversion von Google Chrome, „Chromium“, hat die VM direkt integriert. Der „Frog Compiler“, der im Dart SDK enthalten ist, kann Javascript Code generieren [65]. Dadurch ist es möglich, ein in Dart geschriebenes Programm überall laufen zu lassen. Da die Dart-VM zur Zeit nur im Chromium-Browser eine echte Option darstellt und kompilierten Code ausführen kann, muss für alle anderen Plattformen immer noch auf generierten Javascript Code zurück- gegriffen werden. Sollte Javascript leistungsfähig genug sein, um für TurtlebiteSim eingesetzt werden zu können, wäre Dart eventuell eine gute Wahl.Unabhängig davon hat Dart allerdings einen leicht schalen Beigeschmack: Google ist bekannt dafür, relativ überraschend die Weiterentwicklung ihrer Produkte einzustellen, wenn sich herausstellt, dass diese sich nicht bewähren [66], [67], [68], [69]. Da Dart auch heute, vier Jahre nach seiner Veröffentlichung, noch keine grosse Verbreitung hat (gemäss Tiobe Index liegt die Bewertung bei 0.671% [70]), ist es vielleicht nicht so ratsam, auf Dart zu setzen...

3.6.6 HaxeDamit TurtlebiteSim auf allen Plattformen mit der optimalsten Gschwindigkeit ausgeführt werden kann, wäre es natürlich am besten, die Applikation für jedes Gerät nativ umzusetzen. Von den bisher genannten Pro-grammiersprachen käme nur ActionScript in die Nähe einer nativen Implementation auf allen Plattformen. Die Alternative, für jedes Gerät in der jeweiligen Sprache zu programmieren, kommt aus aufwandtechnischen Gründen nicht in Frage. Das Haxe Projekt wurde 2005 von Nicolas Cannasse gestartet. Seine Passion für das Design von Program-miersprachen und die aufkommenden Möglichkeiten, verschiedene Technologien zusammenzubringen, mündeten in der Kreation einer ganze neuen Sprache [71]. Auf der Website von Haxe steht: „Haxe is an open source toolkit based on a modern, high level, strictly typed programming language, a cross-compiler, a com-plete cross-platform standard library and ways to access each platform‘s native capabilities.“ [72] Damit ist es



möglich, in Haxe geschriebene Programme nativ auf den meistgenutzten Plattformen einzusetzen. Über die sogenannten „Haxelibs“ kann Haxe um spezifische Funktionen erweitert werden. Zum Beispiel gibt es eine Haxelib für Animationen, eine andere, um auf native Funktionen der jeweiligen Plattform zuzugreifen usw. [73] OpenFL (Open Flash Library) ist eine Opensource-Implementation der Flash-API, die auf Haxe aufbaut. Dadurch wird es für Entwickler mit Flash-/ActionScript-Vorwissen einfacher, Programme mit OpenFL um-zusetzen [74].In einem Test, bei dem ein kleines Programm erstellt wurde, das mehrere Ebenen von Grafiken lädt (wie es dann auch bei TurtlebiteSim der Fall sein wird), konnte der Code erfolgreich kompiliert und gestestet werden: im Javascript/HTML5-Format im Browser auf dem Desktop, als Flash-Applikation auf dem Mac, als native Mac-Applikation, als native iOS-Applikation auf dem iPad und als native Android-Applikation auf einem ASUS Transformer Pad. Es ist zu bemerken, dass Haxe am Beispiel von iOS ein komplettes Xcode-Projekt erstellt, das man auch mit Xcode kompilieren kann. Ähnlich verfahren wird mit der Version für Android, bei der sämtliche benötigten Java-Dateien erstellt werden. Da Haxe wie erwähnt auch Javascript generieren kann, konnte auf dem iPad sowie dem Android Tablet die Performanz von nativ versus Javascript/HTML5 im Browser verglichen werden: Die nativen Versionen schneiden, wie erwartet, in Sachen Geschwindigkeit besser ab als die Javascript-Version im Browser. Ein Nachteil hat Haxe aber gegenüber den anderen Technologien: Es gibt noch keine ausgereiften UI-Frame-works, um einfach und schnell Benutzeroberflächen zu erstellen, wie beispielsweise mit JavaFX [75] für Java oder Flex [76] für ActionScript. Im Falle von TurtlebiteSim ist dies allerdings nicht unbedingt ein Nach-teil, da hier keine speziellen Elemente wie Farbwähler, Bildlaufleisten, komplizierte Menüs oder Formulare vorkommen, sondern praktisch ausschliesslich eigens erstellte Pixel- und Vektorgrafiken. Somit steht nach dem Vergleich der 5 Programmiersprachen fest: Haxe scheint die passendeste Wahl zu sein für die Implemen-tation von TurtlebiteSim.

3.6.7 EntscheidNach der Evaluation steht fest, dass Haxe am meisten Punkte sammeln kann und somit für die Umsetzung von TurtlebiteSim eingesetzt wird.

Technologie Unterstützt nativ alle Plattformen (Desktop, iOS, Android)

Zukunftssichere Programmiersprache

Kann die Anforderun-gen des Simulationspro-gramms erfüllen

Java 2: iOS nur mit RoboVM 1 1Actionscript 2: iOS und Android

nur verpackt in AIR 3 1

Javascript/HTML 3 1 1Dart 3 2: Der Willkür von

Google ausgeliefert 1

Haxe 1 1: Open Source, grosse Community 1

1: gut, 2: gut mit Einschränkung, 3: unbrauchbar

Tab. 10: Vergleich der Technologien nach der Evaluation


ZHAW - Masterarbeit - Christian Kaegi - 28.8.2015 - v2.0.3 Design und Implementierung

3.7 Design und Implementierung

Platine

ALU

Akkumulator

4-Bit Speicher

1-Bit Speicher

NANDGatter

4-Bit Enabler

ANDGatter

4-Bit Addierer

Voll-Addierer

Halb-Addierer

NANDGatter

ANDGatter

ORGatter

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

TurtlebiteSim soll es ermöglichen, entweder „top-down“ oder „bottom-up“ die Funktionsweise der Kompo-nenten zu erforschen (siehe Abb. 39). Diese Methode lässt sich am ehesten mit dem Babuschka-Prinzip ver-gleichen. Man kann mit der ganzheitlichen Simulation beginnen (sozusagen auf der „Platine“) und sich dann in die Tiefe bis zu der untersten Ebene, den Gattern, durcharbeiten. Umgekehrt soll es aber auch möglich sein, isoliert mit einem einzelnen Gatter zu starten: Man wählt in der Navigation z.B. das NAND-Gatter, probiert es interaktiv aus, und lässt sich anschliessend zeigen, wie es in einer einfachen Schaltung verwendet wird. Diese Schaltung wiederum wird in einer weiteren Schaltung verwendet, und so weiter, bis eine Komponente komplett ist und man sich wieder auf der „Platine“ befindet. Es soll möglich sein, an jeder Stelle und zu jedem Zeitpunkt den Taktgeber zu starten bzw. manuell das Taktsignal auszulösen und so das Tempo selber zu be-stimmen, mit dem die Vorgänge erforscht werden.

Um TurtlebiteSim nicht mit Informationen zu überladen, soll auf der Companion-Website eine kurze Einlei-tung die Möglichkeiten beschreiben. Ein weiterer Vorteil dieser Zusatz-Website ist, dass man schnell Texte und Links ergänzen kann, ohne die TurtlebiteSim Applikation updaten zu müssen. Gerade für die Tablet-versionen (iOS und Android) ist dies ein nicht zu unterschätzender Vorteil, da man so den Weg über die App Stores sparen kann.



……

…

…

……

…

…

…

Platine

ALU

Akkumulator

4-Bit Speicher

1-Bit Speicher

4-Bit Enabler

4-Bit Addierer

Voll-Addierer

Halb-Addierer

NAND AND OR XOR NOT

1-Bit 4x2 Multiplexer

4-Bit4x2 Multiplexer

Top-Down

Bottom-Up

Abb. 40: Navigation: Top-Down und Bottom-Up

In Logisim ist es üblich, bei den Simulationen mehrere Leitungen mit sogenannten Verteilern zu einer einzel-nen Mehrbit-Leitung zusammenzuführen, um die Übersicht zu behalten. In Abb. 23 zum Beispiel entspricht jede schwarze Linie genau vier einzelnen Leitungen.Jede Linie zu zeichnen wäre schlicht zu umständlich. In TurtlebiteSim ist aber genau dies gewollt, um sehen zu können, wann welche Leitung Strom hat und wann nicht. Jedes einzelne Bit lässt sich so verfolgen.

3.7.1 Wichtige Elemente der Companion-WebsiteNeben Erläuterungen zur TurtlebiteSim-Applikation sollen hier vor allem Hinweise zu weiterführender Literatur, Links zu anderen Simulationsprogrammen, Videos, Wikipedia-Einträgen sowie Empfehlungen und eigene Texte bereitgestellt werden.

Beispiel eines eigenen Textes:

Das eigentliche Geheimnis des ComputersDer Schlüssel zum Verstehen des Computers ist die Geschwindigkeit ([37], S.6). Wie man in TurtlebiteSim sehr gut nachvollziehen kann, wird pro Takteinheit genau ein Befehl ausgeführt. Ein Computer führt diese Befehle allerdings in einem so unvorstellbaren Tempo durch, dass der Eindruck sehr hoher Komplexität entsteht. In TurtlebiteSim ist es möglich, dieses Tempo zwischen 1 Hertz (also einmal pro Sekunde) und 1 Kilohertz (1000 mal pro Sekunde) einzustellen. Allerdings werden die 1 Kilohertz in TurtlebiteSim, abhängig von der Plattform, nicht wirklich erreicht. Heutige Computer sind mit über 2 Gigahertz getaktet: also mehr als eine Million mal schneller als in TurtlebiteSim.

Veranschaulichung 1: Punkte malenUm die hohe Geschwindigkeit eines Computers fassbar zu machen, wird folgender Vergleich angestellt: ein kariertes A4 Blatt soll mit Punkten gefüllt werden. Ein Blatt hat rund 70 Zeilen à 60 Quadrate, das ergibt 4200 Quadrate. Von Hand wird jetzt in jedes Quadrat ein Punkt gemalt. Vernachlässigt man die Zeit, um vom Ende



einer Zeile zum Anfang der nächsten Zeile zu gelangen, ebenso die Ermüdungserscheinungen und das rapide Nachlassen der Konzentration, kommt man nach 8 Zeilen oder 480 gemalten Punkten auf durchschnittlich 0.4375 Sekunden pro Punkt. Der Einfachheit halber wird dieser Wert zur weiteren Berechnung auf 0.4 Sekun-den pro Punkt abgerundet.

Abb. 41: Punkte malen

Ein Mensch benötigt also pro A4 Blatt 28 Minuten (4200 Punkte * 0.4 Sek. = 1680 Sek./ 60 = 28 Min.). Nimmt man 500 Blatt zu einer handelsüblichen Verkaufseinheit als Paket zusammen, liegt die benötigte Zeit bereits bei über 9 Tagen (28 Min. * 500 Blatt / 60 Min. / 24 Std. = 9.72 Tage) für ein Paket. Stellt man sich 5 dieser Pakete in einem Karton vor, 40 dieser Kartons gestapelt auf einem Palett (5 * 8 Kartons, siehe Abb. 42), erhält man eine Punktemaldauer von über 5 Jahren (9.72 Tage * 5 Pakete * 40 Kartons = 1944 Tage / 365 = 5.32 Jahre). Nicht berücksichtigt wird die Tatsache, dass der Mensch natürlich nicht 5 Jahre lang 24 Stunden am Stück ohne Pause durchmalen kann.

Abb. 42: Palette mit Kopierpapier (Quelle: http://www.papierexpert.de/shop-c13-Kleinmengen-unter-Palette, besucht 19.6.2015)

Wenn man jetzt zum Vergleich annimmt, dass ein Computer für einen Punkt 5 Taktzyklen brauchen würde und die Taktfrequenz bei 1 GHz liegt, benötigt er 0.021 Millisekunden für ein A4 Blatt (4200 Punkte * 5 Takt-zyklen = 21‘000 Taktzyklen / 1‘000‘000‘000 Hz = 0.000021 Sek.), 0.0105 Sekunden pro Paket (0.000021 Sek. * 500 Blatt = 0.0105 Sek.), 0.0525 Sekunden pro Karton (0.0105 Sek. * 5 Pakete = 0.0525 Sek.), demzufolge 2.1 Sekunden für ein ganzes Palett (0.0525 Sek. * 40 Kartons = 2.1 Sek.). Wenn der Mensch also den sechsten Punkt malt und noch knapp 420 Millionen (4200 * 500 * 5 * 40 = 420‘000‘000 - 6 = 419‘999‘994) Punkte und mehr als 5 Jahre vor sich hat, ist der Computer bereits mit dem ganzen Palett fertig.



Veranschaulichung 2: Tischtennisbälle in TurnhalleDie Turnhallen in der Schweiz sind genormt auf 16m * 28m Grundfläche und 7m Raumhöhe [77]. Dies ergibt ein Volumen von 3‘136 m3. Die Grösse eines Tischtennisballs ist ebenfalls genormt auf 39.5 - 40.5mm [78]. Für das Beispiel wird der Mittelwert von 40mm gewählt. Pro Meter haben also genau 25 Tischtennisbälle Platz, das bedeutet 15‘625 Bälle pro Kubikmeter (25 * 25 * 25). In eine leere Turnhalle passen somit exakt 49‘000‘000 Tischtennisbälle (3‘136m3 * 15‘625 Bälle). Wenn nun wie im vorherigen Beispiel der Computer 5 Taktzyklen benötigen würde, um einen Ball durch ein 41mm grosses Loch ins Freie zu befördern und wieder von einer Taktfrequenz von 1 GHz ausgegangen wird, wäre die Turnhalle in 0.245 Sekunden leer (49‘000‘000 Bälle / 1‘000‘000‘000 Taktsignale * 5 = 0.245 Sek.). Angenommen, der Mensch schafft 5 Bälle pro Sekunde, bräuchte er über 113 Tage, bis die Halle leer ist (49‘000‘000 Bälle / 5 Sek. = 9‘800‘000 Sek. / 60 = 163‘333.33 Min. / 60 = 2722.22 Std. / 24 = 113.43 Tage).

3.7.2 User InterfaceBevor die Programmierung starten kann, muss erst einmal herausgefunden werden, welche Navigations- und Grafikelemente benötigt werden. Mit Hilfe eines Wireframes (siehe Abb. 43) wird die Informationsarchitek-tur festgelegt und ausprobiert, an welchen Stellen welche Elemente am besten positioniert werden. In Axure RP (eine spezielle Software für das Erstellen von Prototypen [79]) wird bewusst darauf geachtet, einen hand- gezeichneten Stil ohne Farben (ausser Pink für „Hotspots“) zu verwenden, um nicht vom eigentlichen Zweck des Wireframes abzulenken.

Abb. 43: Wireframe für iPad



Dabei wird von Anfang an berücksichtigt, dass die TurtlebiteSim Applikation auch auf Tablets (mit Finger) be-dient werden soll; aus diesem Grund ist das Wireframe für das iPad ausgelegt. Das UI Design soll unverändert bleiben, auch für Desktop-Versionen, die mit der Maus bedient werden. Demzufolge müssen die Interaktions- elemente wie Buttons und Menüs so konzipiert sein, dass beides möglich ist. Wenn es also auf Tablets bedien-bar ist, dann geht es auch automatisch auf dem Desktop (egal ob native Applikation oder als HTML/Javascript Version im Browser). Eventuell macht es für einen späteren Release Sinn, zwei verschiedene Varianten zu implementieren.

3.7.2.1 Grafikelemente

In der TurtlebiteSim Applikation geht es darum, viele einzelne Linien ein- und auszuschalten. Es muss gut überlegt sein, wie das am besten umgesetzt werden könnte. Eine Variante ist, die einzelnen Linien im Code zu erstellen, also mit der Grafik-API zu programmieren. Dafür spricht, dass man so die maximale Kontrolle hat. Dagegen spricht, dass es ein immenser Aufwand ist, jede einzelne Linie zu programmieren. Jeder Punkt muss definiert, jede Linie sprichwörtlich gezeichnet werden. Vom Startpunkt zum nächsten Eckpunkt und wieder zum nächsten Eckpunkt, bis irgendwann der Endpunkt erreicht ist. Bei so vielen Linien ist das ein enormer Zeitaufwand. Ausserdem ist es fraglich, ob nicht die Performanz darunter leidet, wenn jede einzelne Linie zur Laufzeit gezeichnet werden muss. Die offensichtlich einfachere und leistungsfähigere Variante ist, für jede Linie, die für sich alleine aktiv sein kann, eine eigene Bitmapgrafik zu erstellen. Im Code werden dann diese Bitmaps geladen und zum entsprechenden Zeitpunkt (sprich beim Taktsignal) nur noch eingeblendet. Für TurtlebiteSim wird der zweite Ansatz gewählt.

3.7.2.2 Grafiken in Adobe Illustrator erstellen

In Adobe Illustrator wird die ganze Grafik als Vektorzeichnung erstellt. Das Vektorformat hat gegenüber dem Pixelformat den Vorteil, dass es beliebig skalierbar ist, ohne Qualität einzubüssen.

Comparator

Comparator

Comparator

Comparator

Comparator

Comparator

Comparator

Comparator

Comparator

Comparator

2

1

3

4

5

6

7

8

9

A

Enab

ler

Enab

ler

Register

Register

7

Multiplexer

Register

ALU

Dec

oder

Program-Counter

ROM4

Clock

RAM4

Abb. 44: Eine frühe Version, erstellt in Adobe Illustrator



Gut wäre es, wenn in Haxe das SVG-Format (Scalable Vector Graphics [80]) genutzt werden könnte. Damit würde die Grafik immer perfekt aussehen, egal auf welchem Gerät und mit welcher Bildschirmauflösung. Leider geht dies nicht, sodass man auf Bitmaps zurückgreifen muss. Die Grafiken müssen also von Illustrator als PNG exportiert werden, um sie überall nutzen zu können. Es hat sich leider herausgestellt, dass es auch nach mehreren Versuchen mit verschiedenen Export-Grössen nicht möglich ist, die Pixelgrafiken so hinzu-bekommen, dass die Linien sauber gezeichnet werden. Dies liegt daran, dass die Linien exakt 2 Pixel breit sein und genau auf dem Pixelraster liegen müssen, was aber nicht der Fall ist. Sie werden, je nachdem ob beim Importieren in Adobe Photoshop „Glätten“ aktiviert ist oder nicht, entweder weichgezeichnet (Anti-Aliasing 1) oder haben harte, unsaubere Kanten.

Abb. 45: Links mit Anti-Aliasing, rechts mit Kantenglättung

Beides ist unbefriedigend und sieht auf dem iPad (mit Retina-Auflösung) sehr unschön aus. Es bleibt also nichts anderes übrig, als die Grafiken direkt im Pixelformat in der entsprechenden Zielauflösung in Pho-toshop zu erstellen. Hier wird nun peinlichst genau darauf geachtet, dass die Linien exakt auf dem Pixelraster liegen und sich gut durch 2 teilen lassen (damit man der doppelten Auflösung des Retina-Displays beim iPad Rechnung tragen kann). Im gleichen Atemzug wird jetzt auch eine sogenannte Pixelschrift eingesetzt: Diese ist speziell wegen der Anti-Aliasing-Problematik erstellt worden. Das Resultat kann sich sehen lassen (siehe Abb. 46).

Abb. 46: Pixelgenaue Grafik - kristallklar und scharf: das Anti-Aliasing ist weg

1 Durch Pixelraster können unschöne Effekte entstehen, bei der ungerade Linien treppenartig dargestellt werden. Durch Anti-Aliasing (Kantenglättung) werden angrenzende Pixel bei der Berechnung mit einbezogen und durch Anpassen der Farbe und Hinzufügen von zusätzlichen Pixeln geglättet. In vielen Fällen ist dies erwünscht, in manchen Fällen aber nicht, da es immer auch mit dem Verlust von Schärfe verbunden ist.



Bei der neuen Version der Grafiken sind auch die Kontaktpunkte auf den Linien als Quadrate realisiert, um der Anti-Aliasing-Problematik aus dem Weg zu gehen. Die Grafik lässt sich jetzt in der Auflösung 1024 x 650 Pixel einsetzen, auf dem iPad wird sie mit dem Faktor 2 auf 2048 x 1300 Pixel skaliert. (Die effektive Auflö-sung auf dem iPad ist 2048 x 1536 Pixel. Die in der Bitmapgrafik nicht benutzten unteren 236 Pixel werden für die Naviagion benötigt). Glücklicherweise sieht man bei den Linien keinen Unterschied: Diese werden sauber von 2 Pixel Breite auf 4 Pixel skaliert, sodass hier sogar noch Ladezeit (durch die kleinere Dateigrösse der Bit-mapgrafiken) gespart werden kann. Die Gatter leiden allerdings etwas beim Skalieren: Ihre runden Formen profitieren nicht von der pixelgenauen Anordnung. Um dies zu umgehen, werden sie für das iPad in einer separaten Ebene in der vollen Grösse (2048 x 1300 Pixel) als eigene Grafik geladen. In Photoshop ist jetzt Fleissarbeit angesagt: Jede Linie, die unabhängig von den anderen aktiv sein kann, muss grün eingefärbt (grün = aktive Leitung) als einzelne Grafik gespeichert werden.

3.7.2.3 Zusätzliche Grafikebenen

Um es noch einfacher zu machen, den einzelnen Bits über die Leiterbahnen zu folgen, ist es möglich, eine zusätzliche Ebene einzublenden, welche die Flussrichtung der Daten mit Pfeilen markiert. Ausserdem lässt sich eine sogenannte „Highlight“-Funkion aktivieren, welche alle gerade nicht aktiven Komponenten visuell abschwächt. Dies wird dadurch erreicht, indem im Code mit der Grafik-API an der entsprechenden X- und Y-Position ein Rechteck – mit der exakten Grösse der jeweiligen Komponente und mit der gleichen Farbe wie der Hintergrund – gezeichnet wird, welches mit 80% Transparenz die darunterliegende Grafik der Kompo-nente abdeckt.

Abb. 47: Anzeige des Datenflusses und Ausblenden gerade nicht beteiligter Komponenten



3.7.2.4 Navigation

Um die Anzahl Bitmapgrafiken nicht zusätzlich unnötig zu erhöhen, wird bei der Navigation darauf ge-achtet, mit der Grafik-API in Haxe alle dafür benötigten Elemente zu erstellen. Wie eingangs erwähnt, gibt es bisher noch keine wirklich brauchbare GUI-Bibliothek, welche fertige Komponenten wie Menüleisten, Popup-Windows, Buttons usw. bereit stellt. Zum Glück ist die Anzahl der benötigten Menü-Bausteine über-schaubar: Diese können ohne grösseren Aufwand erstellt werden. Auf Rollover-Effekte wird bewusst verzich-tet, da diese beim Touchscreen bei den Tablets auch nicht zum Einsatz kommen.

Abb. 48: Die fertige Hauptnavigation

3.7.3 Software Design

3.7.3.1 MVC Framework

Beim Softwaredesign soll von Anfang an auf eine saubere Trennung des Codes in die drei Bereiche „Model“, „View“ und „Controller“ geachtet werden. Mit PureMVC [81] wird ein Framework gewählt, das einen ganz entscheidenden Vorteil hat: Es ist verfügbar für eine grosse Anzahl von Programmiersprachen. Neben Haxe sind dies unter anderem: ActionScript 3, C++, C#, Dart, Java, Javascript, Objective C, Perl, PHP, Python, Ruby, Typescript und seit neustem auch Swift [82].



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

PureMVC wurde von Cliff Hall im November 2006 ins Leben gerufen, ursprünglich als MVC Framework für ActionScript 3. Cliff Hall schreibt im ersten Newsbeitrag: „The PureMVC project aims to deliver a simple framework that enables quick implementation of rich client applications“ [84]. Das Projekt wurde nicht nur von der ActionScript Community sehr gut aufgenommen: Bald schon gab es Portierungen für andere Spra-chen. Das PureMVC Framework besteht aus nur 21 Klassen, und es wurde streng darauf geachtet, gemäss dem kleinsten gemeinsamen Nenner nur Funktionen und Design Patterns zu verwenden, welche in allen portierten Sprachen vorkommen. Nur so war es mögich, stabile Versionen zu bekommen, die nicht mit jedem neuen Re-lease der jeweiligen Programmiersprache wieder angepasst werden müssen. Die Version 2.0.4 von PureMVC für ActionScript 3 ist seit 2008 stabil [85], die Version 1.4 für Haxe wurde das letzte Mal am 20. April 2013 aktualisiert. [86] In Abb. 49 kann man gut erkennen, dass die Bereiche „View“ (View Components) ganz links und „Model“ (Data Objects) ganz rechts ausserhalb des eigentlichen Frameworks angesiedelt sind. Dadurch wird es mög-lich, die View- und Data-Komponenten beliebig auszutauschen, ohne die eigentliche Architektur ändern zu müssen. Die Idee dahinter ist, dass man das einmal erworbene Wissen über PureMVC beim Portieren einer Applikation in eine andere Sprache zu grossen Teilen übernehmen kann. Cliff Hall hat dazu im Jahr 2010 ei-nen eigenen Newsbeitrag geschrieben, in dem er aufzeigt, warum das so viele Vorteile bringt [87]. Ironischer-weise veröffentlichte Steve Jobs (siehe 3.6.3 „Actionscript“ auf Seite 44) nur einen Monat früher im gleichen Jahr seine „Gedanken zu Flash“ [52].


ZHAW - Masterarbeit - Christian Kaegi - 28.8.2015 - v2.0.3 Tests und Validierung

3.7.4 Vorgehensweise bei der ImplementierungDie Grundidee ist, ein zentrales Taktgeber-Proxy zu erstellen. Dieses sendet das Taktsignal als sogenannte Notification, welche auf einen Command (Controller) gemappt wird. Dieser organisiert alle benötigten Daten aus dem Model und verschickt sie wiederum als Notification. Die Mediatoren, von denen jeder seinen eigenen View betreut, haben diese Notification abonniert und reagieren entsprechend, indem sie in der View-Kompo-nente die benötigten Bitmapgrafiken aktivieren bzw. deaktivieren. Damit wird eine lose Kopplung erreicht; die View-Komponenten brauchen nichts von der darunterliegenden Architektur zu wissen, und die eventuelle Portierung von TurtlebiteSim in eine andere Programmiersprache wird vereinfacht. Für die erste Version der Applikation wird noch auf das externe Laden und Speichern (für die Programmdaten im ROM) verzichtet. Mit der eingesetzten Architektur ist es jedoch sehr einfach, dies später nachzuholen.

3.8 Tests und ValidierungDie TurtlebiteSim Applikation wurde bei verschiedenen Personen der Zielgruppe getestet. Dazu wurde vorab geklärt, wie der Wissensstand und das Interesse ist. Bei den versierteren Probanden wurde kurz die Funktionsweise erläutert und dann das Tablet (oder die Maus) übergeben, um zu schauen, wie vorgegangen wird. Schnell wurde klar, dass TurtlebiteSim (noch) nicht selbsterklärend ist. Bei einer geführten Demonstra-tion bei den nicht-technikaffinen Testpersonen war es sehr spannend zu beobachten, wie das wilde Blinken all der Leitungen Erstaunen hervorrief. Als dann auf den manuellen Modus umgeschaltet und gezeigt wurde, wie die einzelnen Bits von den verschiedenen Komponenten verarbeitet und weitergeleitet werden, gab es ein Aha-Erlebnis.Bei den technisch weniger bewanderten Testpersonen musste zuerst grundlegendes Wissen aufgebaut wer-den, z.B. was sind Register, ALU etc. Aber genau dies war anhand von TurtlebiteSim sehr gut erklärbar, und es konnte schnell vermittelt werden, warum all diese Komponenten benötigt werden. Die Fragen waren ganz unterschiedlich, entweder zu Assembler, Gattern, Taktgeber... aber alle Fragen konnten zufriedenstellend be-antwortet und sehr schön in der Simulation „erlebt“ werden.Wie erwartet konnte somit gut aufgezeigt werden, wie ein Computer Instruktion für Instruktion einzeln abarbeitet. Die Möglichkeit, beim Akkumulator bis zum NAND-Gatter des 1-Bit Speichers vorzudringen, hat bei den technisch versierten Testpersonen Diskussionen zum aktuellen Stand der Computertechnik ausgelöst. Die weniger technikinteressierten Personen waren mit der Erfahrung zufrieden, dass ein Computer wirklich nur Nullen und Einsen verarbeiten kann, dies jedoch mit einer unglaublichen Geschwindigkeit. Es hat sich jedoch gezeigt, dass noch Animationen eingebaut werden müssten, um den Datenfluss besser zu visualisieren und damit TurtlebiteSim zu einer selbsterklärenden Applikation zu machen.


ZHAW - Masterarbeit - Christian Kaegi - 28.8.2015 - v2.0.3 Ergebnisse und Zusammenfassung

3.9 Ergebnisse und ZusammenfassungDer Haxe-Programmcode von TurtlebiteSim besteht mittlerweile aus 93 Klassen (PureMVC nicht eingerech-net) und 7190 Zeilen Quellcode (ohne Leerzeilen, Kommentare etc.). Der Code konnte für folgende Platt- formen kompiliert und getestet werden:

Mac Windows Linux iPad (iOS) ASUS Transformer Tablet (Android)Flash (SWF)NEKOHTML5Mac OSiOSAndroid

Tab. 11: Übersicht: auf welchen Plattformen läuft der kompilierte Haxe-Code?

Eine native Version für Windows muss auf einem PC kompiliert werden. Ein kurzer Versuch in einer virtu-ellen Maschine auf dem Mac (VMware mit Windows 7) zeigte beim Kompilieren noch eine grössere Anzahl Fehlermeldungen, sodass dieser Weg im Rahmen dieser Arbeit nicht weiter verfolgt wurde. Mit Haxe ist es aber möglich, neben Windows und den bereits genutzten Zielplattformen auch noch Emscripten [88], Tizen [89], Linux, Blackberry und webOS [90] auszuwählen.

3.9.1 PlattformunterschiedeIn der IntelliJ IDE geschieht die Auswahl der entsprechenden Zielplattform durch Selektion in einer Drop-down-Liste: Dies macht die Kompilierung zum Kinderspiel. Haxe bietet ein sehr hilfreiches Feature an, ver-schiedene Anweisungen für die unterschiedlichen Zielplattformen in der gleichen Codebasis zu verwalten: Mit Kompiler-Anweisungen kann man direkt im Code dafür sorgen, dass z.B. beim Kompilieren für iOS der Codeabschnitt A gewählt wird, beim Kompilieren für HTML5 aber der Codeabschnitt B. Dies geschieht mit einfachen IF-ELSE Anweisungen, siehe Abb. 50.

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

Die Implementierung für die verschiedenen Plattformen hat dennoch einige Unterschiede ergeben, welche im folgenden detailliert aufgezeigt werden.

3.9.1.1 Flash

Flash bietet – als einzige Zielplattform – mit der SDK von Flex die Möglichkeit, in der Programmierumgebung (Eclipse oder IntelliJ) den Code zu debuggen. Dazu kann man bequem sogenannte Breakpoints setzen und die Ausführung an beliebiger Stelle unterbrechen, um den gerade aktuellen Zustand zu untersuchen. Aus diesem Grund empfiehlt es sich, mit dieser Konstellation zu entwickeln und zwischendurch immer wieder zu testen, wie es auf den anderen Zielplattformen aussieht. Das Resultat ist optisch in Ordnung (saubere Schriften und



Grafiken), trotzdem hat Flash zwei schwerwiegende Nachteile gezeigt: Das Benutzererlebnis wird etwas ge-trübt, da es teilweise Unterbrüche gibt, wenn neue Grafiken nachgeladen werden. Bei einem anderen Anwen-dungsfall resp. Programm käme dies wahrscheinlich nicht zum Tragen, bei der Simulation in TurtlebiteSim müssen jedoch die Grafiken, die die aktiven Leitungen darstellen, in hohem Tempo ein- und ausgeblendet werden. Neben dem teilweise ruckeligen Erlebnis kommt noch hinzu, dass ab und zu bereits geladene Grafiken einfach kurzzeitig verschwinden.

3.9.1.2 Neko

Neko ist auf der einen Seite eine Programmiersprache, es gibt aber auch einen Kompiler und eine Virtuelle Maschine. Auf der Website steht „The Virtual Machine is very lightweight and yet well optimized so it is run-ning very quickly. The VM can be easily embedded into any application and your libraries can be accessed using the C foreign function interface.“ [91]. Die Kompilierung von TurtlebiteSim ins Nekoformat funktioniert ohne Probleme. Im Vergleich zur Flash-Version gibt es hier keine Grafiken, die plötzlich verschwinden. Aber auch die VM von Neko hat etwas Mühe, die schnellen Grafikwechsel flüssig ablaufen zu lassen. Ausserdem sind die Schriften nicht mehr so scharf und klar wie in der für Flash kompilierten Version. Unmittelbar nach der Kompilierung in IntelliJ läuft die Applikation stabil; wenn man sie allerdings später noch einmal ausser-halb der IDE starten möchte, stürzt sie immer mit einem „unbekannten Fehler“ ab: Dadurch wird Neko als Zielplattform ungeeignet.

3.9.1.3 Mac OS

Die für das Mac OS kompilierte Version von TurtlebiteSim läuft im Vergleich zu allen anderen Plattformen am besten resp. am leistungsfähigsten. Hier gibt es keine Ruckler und keine Grafikaussetzer, allerdings wird der Text unscharf und nicht korrekt dargestellt.

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

Betimmte Zeichen wie zum Beispiel die Anführungs- und Schlusszeichen (« ») bei «Store Data» werden gar nicht angezeigt, und der Text läuft aus dem Textrahmen hinaus, ohne umzubrechen.

3.9.1.4 HTML5

Die für HTML5 ertellte Version erzeugt eine HMTL- sowie eine Javascript-Datei. Die letztere ist 1.4 MB gross und enthält über 35‘000 Zeilen Code. Erstaunlicherweise läuft diese Variante von TurtlebiteSim sehr flüssig und schnell, zumindest im Browser auf dem MacBook (auf dem iPad ist die Ausführungsgeschwindigkeit nicht mehr so gut). Der einzige Schönheitsfehler ist, dass auch hier die Schriften nicht absolut scharf dargestellt werden. Dafür fehlen keine Zeichen, und der Textumbruch in den Textrahmen stimmt. Die Buch- staben sitzen generell etwas zu tief verglichen mit den anderen Versionen, aber dies ist gut zu umgehen, indem man anhand von Kompileranweisungen im Code eine Ausnahme für HTML erstellt und dort die Textfeld- Positionierung korrigiert.



3.9.1.5 iOS

Kompiliert man ein Haxe Projekt als iOS Version, wird ein komplettes Xcode Projekt erstellt. In den ersten kompilierten Versionen von TurtlebiteSim kam es auch auf dem iPad vor, dass teilweise bereits geladene Grafi-ken wieder entladen wurden, um neuen Grafiken Platz zu machen. Nach einer Änderung im Code, bei der alle Grafiken nur noch dann geladen und angezeigt werden, wenn sie benötigt werden, ist dieses Verhalten nicht mehr aufgetreten. Die ursprüngliche Überlegung war, dass es performanter ist, einmal geladene Grafiken im Speicher zu behalten und einfach bei Bedarf ein- und auszublenden. Anscheinend kommt der Kompiler mit der anderen Variante, sprich die Grafiken nur bei Bedarf zu laden, besser zurecht. Das eingesetzte iPad Retina hat einen 1.4 GHz Dual-Core Prozessor. Beim Starten der TurtlebiteSim App gibt es spürbare Verzögerungen, bis es flüssig läuft. Wenn aber einmal alle Grafiken aktiviert sind, ist die Geschwindigkeit vergleichbar mit der Mac OS Version. Wie erwartet läuft die native Variante gegenüber der HTML Version auf dem iPad klar besser. Allerdings gibt es noch Raum für Optimierung: Die iPad App neigt zum Absturz, wenn man zu hektisch navigiert. Ausserdem gibt es auch hier wieder kleine Probleme mit den Schriften: Diese werden zwar kristallklar und scharf angezeigt; wenn allerdings in einem Textfeld die Hinter-grundfarbe und die Textfarbe geändert wird, ist der Text nicht mehr sichtbar.

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

Abb. 54: Bei den anderen Plattformen funktio-niert die Änderung der Textfeldfarben

Dies wird sehr pragmatisch gelöst, indem auf das Ändern der Farben in Textfeldern zur Laufzeit verzichtet und stattdessen eine kleine Bitmapgrafik eines Rechtecks genutzt wird, um das gerade aktive Textfeld zu um-randen und damit zu kennzeichnen.

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

3.9.1.6 Android

Damit man Android als Zielplattform nutzen kann, muss zuerst das Android NDK [92] installiert werden. Danach werden, ähnlich wie bei iOS, beim Kompilieren alle erforderlichen Javaklassen erstellt. Für den Test auf Android steht ein ASUS Transformer Pad (1 GHz Quadcore Prozessor mit 1 GB RAM) aus dem Jahre 2011 zur Verfügung. Die TurtlebiteSim Applikation ist für die Bildschirmgrösse des iPad optimiert (2048 x 1536 Pixel), daher erscheinen auf dem leicht breiteren ASUS Transformer Pad links und rechts schwarze Balken. Die Geschwindigkeit der nativen TurtlebiteSim App ist nicht so gut wie auf dem iPad, aber auch hier nach anfänglichen Startschwierigkeiten akzeptabel. Leider kommt es öfters zu Abstürzen, was schlussendlich die App in der jetzigen Version zumindest für dieses Tablet unbrauchbar macht.



Die HTML-Version läuft im Browser auf dem ASUS Pad bedeutend schlechter als auf dem iPad, welches auch ein neueres Modell ist und mehr Leistung hat.

3.9.2 Vergleich der Ergebnisse

Plattform Performanz Stabilität Grafik- darstellung

Schrift- darstellung

Fazit: einsetzbar?

Flash 2 1 3 1 3: Nicht brauchbar, da Grafiken teilweise plötzlich verschwinden

Neko2 3 1 2

3: Nicht brauchbar, da die Applikati-on meistens sofort nach dem Starten abstürzt

Mac OS1 1 1 3

2: Unsaubere Schrift, fehlende Schriftzeichen. Ansonsten die beste Leistung

HTML 5 auf Desktop 1 1 1 2 1: Einzige Einschränkung: unscharfes

Schriftbild, ansonsten perfektHTML 5 auf iOS 2 1 1 2 2: Neben unscharfem Schriftbild

etwas ruckelig in der AusführungHMTL 5auf Android 3 1 1 2

3: Zumindest auf dem ASUS Trans-former Pad (2011) zu langsam und ruckelig

iOS nativ

2 3 1 1

3: Perfektes Schriftbild und nach Startschwierigkeiten sehr gute Performanz. Leider instabil, stürzt oft ab

Android nativ 2 3 2 1

3: Nach Startschwierigkeiten akzep- table Performanz. Leider instabil, stürzt oft ab

Windows Nicht getestet1: gut, 2: gut mit Einschränkung, 3: unbrauchbar

Tab. 12: Vergleich der Ergebnisse der Applikation auf den verschiedenen Zielplattformen

Die Tabelle zeigt, dass das Ergebnis in der Praxis sehr durchwachsen und bei den getesteten Plattformen nur die HTML 5 Version für den Desktop zu empfehlen ist. Bei der Auswahl der Taktfrequenz bietet Turtle- biteSim einen Bereich von 1 Hz bis 1 KHz. Allerdings ist ab 64 Hz bei allen Plattformen praktisch kein Ge-schwindigkeitszuwachs mehr festzustellen. Hier ist definitiv noch Raum für Optimierung.


ZHAW - Masterarbeit - Christian Kaegi - 28.8.2015 - v2.0.3 Fazit und Ausblick

3.10 Fazit und Ausblick

3.10.1 ZielerreichungDas eigentliche Ziel – ein Simulationsprogramm zu erstellen, welches die Vorgänge in einem Computer visua-lisiert – wurde teilweise erreicht. Unter 2.4 „Abgrenzung“ auf Seite 12 steht: „Die Applikation beschränkt sich auf einen Vorgang nach dem EVA-Prinzip“: Diese Zielsetzung wurde nicht ganz erfüllt, da bei der Umset-zung von TurtlebiteSim auf Interrupts zugunsten der Einfachheit verzichtet wurde. Die Eingabe ist allerdings in Form eines angedeuteten Keyboards vorbereitet, und es könnten auch Daten aus dem Keyboardbuffer aus-gelesen werden, aber dieser Teil konnte aus Zeitgründen nicht mehr fertig implementiert werden. Dafür wurde dem Thema Assemblersprache mehr Aufmerksamkeit geschenkt als ursprünglich geplant. Die anfänglich anvisierte Volksschule als Zielgruppe (Sekundarstufe I und II) hat sich als nicht optimal herausgestellt: Das vorhandene Wissen (und Interesse!) bei den Schülern ist im Allgemeinen noch zu gering. Mit dem Einsatz von Personas konnte die Zielgruppe nachträglich genauer definiert werden. Die Analyse und anschliessende Auseinandersetzung mit der Lösung in Logisim hat sehr viel mehr Zeit in Anspruch genommen als gedacht. Um nicht alles von Grund auf neu erfinden zu müssen, wurde nach einer bereits existierenden Lösung gesucht, die sich in Logisim umsetzen und dann später als Vorlage für das Simulationsprogramm nutzen lässt. Die gefundene Variante einer 4-Bit CPU [34] hat vielversprechend aus-gesehen; sie war aber nicht komplett, und so mussten diverse Komponenten zusätzlich erstellt werden. Der Versuch, mit dem Autor der Logisim-Datei Kontakt aufzunehmen, blieb leider erfolglos. Das Hauptziel jedoch, jedes einzelne Bit auf seinem Weg über die Leiterbahnen, durch die Schaltungen und Gatter hindurch zu be-obachten – zu sehen, wie alles im Zusammenhang funktioniert – wurde erfüllt. Einzelne Vorgänge sind durch TurtlebiteSim erleb- und fassbar geworden und lassen sich jetzt anschaulich erklären.

3.10.2 Technische HürdenDas vollmundige Versprechen von Haxe – „With Haxe, you can easily build cross-platform tools targeting all the mainstream platforms natively.“ [72] – ist sehr verlockend. Tatsächlich ist das Erstellen von Programmen für die verschiedenen Plattformen sehr einfach; die Auswahl der Zielplattform ist mit ein paar Klicks erledigt und somit ein Kinderspiel. Ein kleiner anfänglicher Test hat dies auch bestätigt. In der Praxis und im späte-ren Verlauf hat sich dann allerdings gezeigt, dass es doch nicht ganz so einfach ist: Beim Test unter Windows zum Beispiel spuckt der Kompiler diverse Fehlermeldungen aus. Auch unter Mac OS funktionert das Kompi-lieren erst jeweils beim zweiten Anlauf, und die kompilierte Neko-Version stürzt bei jedem Startversuch mit einem unbekannten Fehler ab. Auf jeder Plattform gibt es mindestens ein fehlerhaftes Verhalten resp. eine Unschönheit. Die Probleme sind dabei jeweils unterschiedlich; angefangen bei fehlenden Schriftzeichen auf Mac OS bis zu Grafikaussetzern in Flash und gelegentlichen Abstürzen unter iOS und Android. Mit zusätz-lichem Aufwand wären diese Probleme aber womöglich zu beheben. Mit sogenannten Native Extensions [93] soll es möglich sein, Haxe mit spezifischen Schnittstellen der jeweiligen Plattform kommunizieren zu lassen. Dadurch könnte man auf native Komponenten der jeweiligen Zielplattform zugreifen und so eventuell zum Beispiel das Textdarstellungsproblem lösen. Es gibt rund um Haxe einige vielversprechende Erweiterungen, etwa die Möglichkeit, native Textfelder für iOS und Android [94] zu verwenden oder mit „Guise“ ein einheit-liches UI auf Haxe-Basis einzusetzen [95]. Leider gibt es in der Praxis dann doch keine zahlreichen fertigen und bewährten Erweiterungen. Sie werden schlecht bzw. gar nicht gepflegt und weiterentwickelt. Das Code



Repository auf Github am Beispiel von Guise wurde seit über 2 Jahren nicht aktualisiert [96]. Damit ist man schnell einmal sich selbst überlassen und muss für sich entscheiden, ob man mit Einschränkungen (wie am Beispiel von TurtlebiteSim mit der unscharfen Schrift) leben kann (und möchte), oder ob man den Aufwand auf sich nimmt, selber Erweiterungen zu entwickeln.

Die Tatsache, dass Haxe am Beispiel von iOS ein komplettes Xcode Projekt erstellt, gibt einem die trügerische Sicherheit, das Projekt später in Xcode öffnen zu können, um dort eventuell noch Anpassungen vorzunehmen. In der Praxis aber macht dies wenig Sinn, weil Haxe den Code beim Cross-Kompilieren bereits optimiert und die Programmzeilen dadurch für den Menschen nicht mehr gut lesbar sind. Somit nützt es auch nichts, wenn man in Xcode debuggen möchte: Der Hinweis auf die fehlerhafte Codestelle stiftet höchstens noch mehr Ver-wirrung.

Abb. 56: Nach dem Konvertieren von Haxe zu iOS ist der Programmcode nicht mehr wirklich lesbar

Ähnlich sieht es mit der HTML-Version aus: Hier wird eine einzelne, über 35‘000 Zeilen grosse Javascript- Datei generiert. Die Programmzeilen sind zwar immerhin besser lesbar als bei iOS in Xcode, aber auch hier macht es wenig Sinn, nachträglich noch Hand anzulegen. Allerdings scheint Haxe die Möglichkeit zu bieten, sogenannte Source Maps zu generieren, um beim Debuggen in Javascript zu der entsprechenden Codestelle in den Haxe-Dateien zu gelangen [97] [98].



Abb. 57: Code-Ausschnitt der automatisch erstellten Javascript-Datei

Somit hinterlässt Haxe gemischte Gefühle: Auf der einen Seite kann es die Entwicklung für verschiedene Zielplattformen dramatisch beschleunigen, auf der anderen Seite steht man vielleicht plötzlich unerwartet vor einem schwer lösbaren Problem, welches den ursprünglichen Zeitvorteil wieder zunichte macht. Deshalb sollte man aufgrund der zu entwickelnden Applikation genau abwägen, ob Haxe in Frage kommt oder nicht. Auf jeden Fall lohnt es sich, Haxe weiterhin im Auge zu behalten. Die Entwicklergemeinde ist gross und aktiv: Je-des Jahr findet zum Beispiel eine Haxe Konferenz statt, zuletzt Ende Mai 2015 in Paris [99]. Es bleibt spannend zu beobachten, wie sich Haxe weiterentwickelt und ob es zu einem späteren Zeitpunkt die Bedürfnisse besser abdeckt.

3.10.3 AusblickViele Bereiche in TurtlebiteSim sind noch nicht fertig. Man kann in der jetzigen Version lediglich in die Akkumulator-Komponente bis zum 1-Bit-Speicher vordringen. Um in die verbleibenden Komponenten wie Comparator, Decoder, Program Counter, Multiplexer, ALU, Register, ROM, RAM etc. „einzutauchen“, müssen die jeweiligen Bitmapgrafiken der einzelnen Leitungen erstellt werden. Der zeitliche Aufwand dafür ist be-trächtlich: Allein für die Basis – also die eigentliche „Platine“ – existieren bereits über 100 einzeln erstellte Grafiken, und allein für die RAM-Komponente wären es noch einmal soviele. Um die Applikation selbsterklä-render zu gestalten, bräuchte es zusätzliche Animationen, um zum Beispiel den Weg der Bits über die Leiter-bahnen besser zu visualisieren. Da die Leistung zumindest beim iPad und dem ASUS Transformer Pad an ihre Grenzen kommt, ist es ausserdem sinnvoll, zuerst über alternative Umsetzungen nachzudenken. Vielleicht lohnt sich ein Versuch, die Leitungslinien doch per API zu progammieren, um zu sehen, wie die verschiedenen Plattformen damit umgehen. Dadurch hätte man auch mehr Kontrolle über die Linienfarben und könnte diese je nach Situation anders einfärben: zum Beispiel die ersten vier Bits (Opcode) in grün und die restlichen vier Bits (Daten-/Adressteil) in blau.

Die TurtlebiteSim Applikation muss im jetzigen Zustand als Prototyp betrachtet werden. Damit könnte man sich zusammen mit Experten der Computertechnik und Pädagogik überlegen, wie sich der Ausbau optimie-


ZHAW - Masterarbeit - Christian Kaegi - 28.8.2015 - v2.0.3 Persönliches Fazit

ren und evtl. noch vereinfachen lässt. Mit der jetzigen Architektur und der Anzahl Befehle im ROM ist es praktisch nicht möglich, ein kleines sinnvolles Programm laufen zu lassen. Dies war ursprünglich auch nicht geplant, aber es wäre natürlich schön, wenn auch das berücksichtigt werden könnte, um TurtlebiteSim noch nützlicher zu machen. Je nachdem macht es dann vielleicht auch mehr Sinn, die Zusatzinformationen in eine ausgewachsene Applikation zu packen, anstatt sie in einer Companion-Website zu platzieren. Spätestens dann sind aber bewährte GUI-Elemente nötig wie beispielsweise Menüs, Popups, Tabellen usw. Und damit wäre Haxe definitiv als Technologie nicht mehr geeignet (zumindest zum jetzigen Zeitpunkt). Aufgrund der benötigten Leistung und den häufigen Abstürzen auf dem iPad und dem Android Tablet könnte aber auch folgendes Szenario die beste Lösung sein: Eine „ausgewachsene“ Java-Applikation für Mac, PC und Linux mit allen Informationen integriert (also ohne Companion-Website), und dann zusätzlich reduzierte Versionen für iOS und Android Tablets, die nur einen Ausschnitt der Funktionalität bieten und dazu dienen sollen, auf die Java-Version aufmerksam zu machen. Diese Tabletversionen könnten aufgrund der reduzierten Komplexität durchaus mit Haxe erstellt werden. Mit dieser Variante könnte man in der Desktop-Java-Applika-tion auch auf die für Touchscreen optimierten grossen Navigationselemente verzichten und hätte mehr Platz zur Verfügung für die eigentliche Simulation.

So oder so: TurtelbiteSim soll auf einer kleinen eigenen Website der Allgemeinheit zur Verfügung gestellt wer-den. Dort wird nach einer kurzen Einleitung und einigen hilfreichen Links erläutert, was in der ersten Version bereits funktioniert und was noch implementiert werden müsste. Ausserdem soll die Logisim-Datei der Simu-lationsvorlage sowie der Haxe-Quellcode allen Interessierten zum Download zur Verfügung gestellt werden.

3.11 Persönliches FazitVor dem MAS-Studium an der ZHAW haben sich meine Informatikkenntnisse auf Computeranwendung und Programmierung beschränkt. Von Anfang an hat mich die Thematik der Digitaltechnik fasziniert, aber ich hatte Mühe, das theoretisch Gelernte in der Praxis erleben zu können. Bei meiner Suche nach geeignetem Lernmaterial bin ich auf das Buch „But how do it know“ von J. Clark Scott [37] gestossen, welches die Grund-prinzipen der Computer für meinen Geschmack unglaublich gut behandelt. In Logisim, welches ich ungefähr zum gleichen Zeitpunkt bei meinen Recherchen im Internet entdeckte, habe ich angefangen, die beschriebe-nen Schaltungen nachzubauen und konnte so die Theorie in die Praxis umsetzen und erleben, warum zum Beispiel das „Random Access Memory“ so heisst, wie es heisst. Dabei ist ziemlich bald die Idee entstanden, ein Simulationsprogramm zu erstellen, welches diese Erfahrungen verarbeitet und anderen Studenten, die sich am Anfang des MAS-Studiums in der gleichen Situation befinden wie ich, ebenfalls helfen könnte. Der Umstand, dass ich mich zuerst in die ganze Thematik einarbeiten und alles von Grund auf verstehen musste, hat mir persönlich unglaublich viel gebracht. Rückblickend muss ich allerdings sagen, dass ich mich etwas zu sehr auf die Vorlagen und Aussagen von anderen verlassen habe. Sicher wäre es im Sinne eines noch lehrreicheren Simulationsprogramms besser gewesen, gleich von Anfang an Unterstützung von jemandem zu holen, der mit der Computerarchitektur bestens vertraut ist und dafür Sorge getragen hätte, dass die Um-setzung technisch noch korrekter ist. Dadurch hätte ich mich mehr auf die Programmierung konzentrieren können, und vielleicht wäre TurtlebiteSim umfangreicher geworden. In diesem Fall hätte ich mich aber auf bekannterem Terrain bewegt und hätte nicht soviel Neues lernen und davon profitieren können.


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

Die Tatsache, dass das ROM nur 16 Befehle fassen kann und ein paar wichtige Elemente nicht vorhanden sind, wie zum Beispiel die Assemblerbefehle für „Jump if less/greater than zero“ oder die Möglichkeit, Werte ohne Umweg über den Akkumulator direkt in die Register zu laden, ist auf den ersten Blick schade, wenn nicht so-gar etwas ärgerlich. Auf der anderen Seite muss ich aber auch sagen, dass die Assemblersprache ursprünglich überhaupt nicht geplant war: Somit handelt es sich hier offensichtlich um „Jammern auf hohem Niveau“.

Das Erstellen und Bearbeiten der benötigten Grafiken war unerwarteterweise eine echte Herausforderung. Einerseits war die effektive Anzahl der einzelnen Linien, die alle separat als Bitmapgrafiken erstellt werden mussten, viel höher als erwartet. Die Wahl des Werkzeugs Adobe Illustrator hat sich später als Fehlgriff her-ausgestellt, sodass ich hier viel Zeit verloren habe, weil ich alles nochmals in Photoshop erstellen musste.

4. SchlussfolgerungenNach Recherchen bestehender Lösungen und Gesprächen mit Informatik- und Pädagogikexperten hat sich bestätigt, dass für eine Applikation wie TurtlebiteSim – welche die Vorgänge im Computer erleb- und fassbar macht – ein echter Bedarf besteht. Aufgrund des noch nicht optimal und einheitlich integrierten Informatik- unterrichts an den Schulen ist es aber ungewiss, wo und wann das Simulationsprogramm am besten einge-setzt werden könnte: am ehesten wohl an den Berufs- und Hochschulen. Als öffentlich zugängliche Applika-tion steht TurtlebiteSim aber jedem offen, der damit auf spielerische Weise die Vorgänge in einem Computer erleben möchte.Haxe als mögliche Programmiersprache für alle Plattformen hat sich nur bedingt bewährt: Es gibt noch zu viele Herausforderungen (Schriftbild, Stabilität und Performanz) auf den Zielplattformen Mac OS, iOS, And-roid und im Browser. Als einzige brauchbare Version hat sich HTML herausgestellt – auch wenn diese Variante wegen der schnellen Grafikwechsel nicht performant genug läuft unter iOS und Android. Da Java für iOS nur mittels der kostenpflichtigen RoboVM in Frage kommt, wurde diese Variante im Rahmen dieser Arbeit nicht ausprobiert. Aufgrund der ernüchternden Ergebnisse mit Haxe ist es rückblickend aber sinnvoll, noch-mals über Java nachzudenken. Es hat sich auch gezeigt, dass doch einige GUI-Elemente nützlich gewesen wären, zum Beispiel für die aufklappbaren Untermenüs oder Tabellen (bei „Edit ROM“). Wenn die Performanz einer mit Java programmierten Version von TurtlebiteSim auf Mac und Windows gut läuft und die Portierung mittels RoboVM auf iOS reibungslos funktioniert, könnte Java doch besser geeignet sein. Spannend wäre auch, über eine Variante nachzudenken, bei der das eigentliche Programm mit Java für Mac, PC und Linux erstellt wird, und die iOS und Android Versionen für Tablets nur einen reduzierten Funktionsumfang haben. Damit könnte auch das Perfomanzproblem auf den mobilen Geräten umgangen werden. Der Einsatz von PureMVC hat sich jedoch gelohnt: Es ist für alle Programmiersprachen verfügbar. Bei einer Portierung des Haxe-Codes kann somit ein sehr grosser Teil der Architektur wiederverwendet werden, sei es Javascript für die HTML-Version, Java für Mac, Windows und Android, oder Swift für iOS.


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

5. Quellen[1] Morris Mano M., Kime C.: Logic and Computer Design Fundamentals, Pearson, Essex, Fourth

Edition, 2014[2] Lehrplan21: Medien und Informatik, Deutschschweizer Erziehungsdirektoren-Konferenz (D-EDK),

Luzern, 2014[3] fotolia.de, https://de.fotolia.com/search?k=56815171, besucht 22.7.2015[4] fotolia.de, https://de.fotolia.com/search?k=28834549, besucht 22.7.2015[5] fotolia.de, https://de.fotolia.com/search?k=56547991, besucht 22.7.2015[6] Massachusetts Institute of Technology: Stuart Madnick, http://esd.mit.

edu/Faculty_Pages/madnick/madnick.htm, besucht: 19.5.2015[7] Little Man Computer, http://en.wikipedia.org/wiki/Little_man_computer, besucht: 9.5.2015[8] LMC in Flash, http://ssjx.co.uk/games/educational/lmc.php, besucht: 9.5.2015[9] LMC als Java Applet, http://www.yorku.ca/sychen/research/LMC/LittleMan.html, besucht: 9.5.2015[10] LMC in Javascript, http://matt.krutar.org/LMC4/, besucht: 9.5.2015[11] LMC in Excel, http://www.ictcool.com/2011/12/16/download-lmc-simulation-v-1-5-2-requires-

micro-soft-excel/, besucht: 9.5.2015[12] Informatik in der Schule, http://www.inf-schule.de/, besucht: 9.5.2015[13] Informatik in der Schule: Bonsai Modellrechner, http://www.inf-schule.de/rechner/bonsai,

besucht 10.9.2015[14] Informatik in der Schule: Der Murmelrechner, http://www.inf-schule.de/rechner/bonsai/

murmelrechner, besucht: 9.5.2015[15] Informatik in der Schule: Der einfache Murmelrechner, Befehle und Programme, http://www.

inf-schule.de/rechner/bonsai/murmelrechner/einfachermurmelrechner/befehle, besucht 19.5.2015[16] Video zum einfachen Murmelrechner, 2012, https://www.youtube.com/

watch?v=QiiKDTUynx8&feature=youtu.be, besucht 10.5.2015[17] Yutaka, S.: Paper Prozessor, https://sites.google.com/site/kotukotuzimiti/, besucht 10.9.2015[18] Ludwig V., Paschenda K.: WDR-1-Bit-Computer, Vertrieb DATANorf, Neuss und Recklinghausen,

1986, http://wdr-1-bit-computer.talentraspel.de, besucht 18.5.2015[19] Member „spel3o“, http://www.instructables.com/member/spel3o/, besucht 18.5.2015[20] Member „spel3o“: How to Build an 8-Bit Computer, http://www.instructables.com/id/

How-to-Build-an-8-Bit-Computer/, besucht 18.5.2015[21] Feinberg, D.: A Simple and Affordable TTL Processor for the Classroom, Carnegie Mellon University

Research Showcase @ CMU, 2007. http://repository.cmu.edu/cgi/viewcontent.cgi?article=1595 &context=compsci, besucht 16.5.2015

[22] Visual6502.org: Visual Transistor-level Simulation of the 6502 CPU, http://www.visual6502.org, besucht 18.5.2015

[23] Morgan, N.: Easy 6502, http://skilldrick.github.io/easy6502/, besucht 18.5.2015[24] Burch C.: Logisim: a graphical tool for designing and simulating logic circuits.

http://www.cburch.com/logisim/, besucht: 9.5.2015[25] Toomey W.: An Example Hardwired CPU, 2010, http://minnie.tuhs.org/CompArch/Tutes/

week03.html, besucht: 9.5.2015



[26] Youtube: Suche nach „Logisim“, https://www.youtube.com/results?search_query=logisim, besucht 16.5.2016

[27] User „Kurence555“: Snake & Tetris in Logisim, 2014, https://www.youtube.com/watch? v=YCBa1NH4ORE, besucht: 9.5.2015

[28] Hendrich, N.: HADES (Hamburg Design System), University of Hamburg, Hamburg, 2006, https://tams.informatik.uni-hamburg.de/applets/hades/webdemos/index.html, besucht 17.5.2015

[29] Skrien, D.: CPUSim, Colby College, Maine, o.J., http://www.cs.colby.edu/djskrien/CPUSim/, besucht 17.5.2015

[30] JLS - A Pedagogically Targetted Logic Design and Simulation Tool, http://www.cs.mtu.edu/~pop/ jlsp/bin/JLS.html, besucht 17.5.2015

[31] Tanenbaum A.S., Computerarchitektur, Strukturen - Konzepte - Grundlagen, Pearson, 2006, 5. Auflage[32] Mojang: Minecraft, Schweden, https://minecraft.net/, besucht 17.5.2015[33] User „xWrubbelx“: Minecraft programmierbare CPU, 8 bit, 0,14 Hz Teil 1/5, 2011,

https://www.youtube.com/watch?v=AQXAK3m3l78, besucht 17.5.2015[34] User „Minecraftmonkeys“: MM4001 - 4 Bit CPU Step by Step, 2013, https://www.youtube.com/

watch?v=KKdl7R3GoNU&list=WL&index=4, besucht: 9.5.2015[35] Wikipedia: Logikgatter, https://de.wikipedia.org/wiki/Logikgatter, besucht 04.07.2015[36] Nvidia: NVIDIA’s Next Generation CUDATM Compute Architecture: Kepler TM

GK110, Whitepaper, Nvidia, 2012, http://www.nvidia.de/content/PDF/kepler/NVI-DIA-Kepler-GK110-Architecture-Whitepaper.pdf, besucht 15.6.2015

[37] Scott J. C.: But How Do It Know?, John C. Scott, Oldsmar, First Edition, 2009[38] Holdsworth B., Woods R.C.: Digital Logic Design, Oxford, 2002[39] Intel: Intel® Xeon® Processor E7-8890 v3, http://ark.intel.com/products/84685, besucht 19.6.2015[40] MOS TECHNOLOGY, INC.: MCS6500 MICROCOMPUTER FAMILY PROGRAMMING MANUAL,

Second Edition, Norristown, 1976, http://archive.6502.org/books/mcs6500_family_programming_manual.pdf, besucht 20.6.2015

[41] World Power Systems: American Standard Code for Information Interchange, ASA X3.4-1963, Ameri-can Standards Association, 1963, http://worldpowersystems.com/J/codes/X3.4-1963/, besucht 21.6.2015

[42] Oracle: Java Timeline, http://oracle.com.edgesuite.net/timeline/java/, besucht 25.6.2015[43] Google: Download Android Studio and SDK Tools, https://developer.android.com/sdk/index.html

#Requirements, besucht 25.6.2015[44] RoboVM: CREATE TRULY NATIVE iOS APPS IN JAVA, http://robovm.com/, besucht 04.07.2015[45] Grossman G., Huang E.: ActionScript 3 overview, 2006, https://www.adobe.com/devnet/actionscript/

articles/actionscript3_overview.html, besucht 25.6.2015[46] Brimelow L.: Six reasons to use ActionScript 3.0, 2008, https://www.adobe.com/devnet/actionscript/

articles/six_reasons_as3.html, besucht 25.6.2015[47] Waldron R.: The Flash History, 2000, http://www.flashmagazine.com/news/detail/the_flash_history/,

besucht 25.6.2015[48] Adobe: Adobe Completes Acquisition of Macromedia, San Jose, 2005, https://www.adobe.com/aboutad-

obe/pressroom/pressreleases/pdfs/200512/120505AdobeAcquiresMacromedia.pdf, besucht 25.6.2015



[49] Adobe: Adobe Technology Platform for RIAs Propels Innovation on the Web, San Jose, 2008, https://www.adobe.com/aboutadobe/pressroom/pressreleases/200802/022508AdobeAIR.html, besucht 25.6.2015

[50] Adobe: Adobe Unveils AIR on Mobile Devices, 2010, http://www.adobe.com/aboutadobe/pressroom/ pressreleases/201002/021510FlashPlayerMWC.html, besucht 25.6.2015

[51] Adobe: Adobe AIR | Deploy Applications, http://www.adobe.com/products/air.html, besucht 25.6.2015[52] Jobs S.: Thoughts on Flash, 2010, https://www.apple.com/hotnews/thoughts-on-flash/,

besucht 25.6.2015[53] Li T.: Better battery life for your laptop, Google Chrome Blog, 2015, http://chrome.blogspot.co.at/

2015/06/better-battery-life-for-your-laptop.html, besucht 25.6.2015[54] Schuh J.: The Final Countdown for NPAPI, 2014, Chromium Blog, http://blog.chromium.org/2014/11/

the-final-countdown-for-npapi.html, besucht 25.6.2015[55] Leider R.: YouTube now defaults to HTML5 <video>, Youtube Engineering and Developers Blog, 2015,

http://youtube-eng.blogspot.de/2015/01/youtube-now-defaults-to-html5_27.html, besucht 25.6.2015[56] Stamos A.: It is time for Adobe to announce the end-of-life date for Flash and to ask the browsers

to set killbits on the same day, Twitter, 12.7.2015, https://twitter.com/alexstamos/status/ 620306643360706561, besucht 22.7.2015

[57] Garrett J. J.: About me, 2006, http://www.jjg.net/about/, besucht 26.6.2015[58] jQuery, http://jquery.com/, besucht 27.6.2015[59] AngularJS, https://angularjs.org/, besucht 27.6.2015[60] The World Wide Web Consortium: A Short History of Javascript, 2012, https://www.w3.org/

community/webed/wiki/A_Short_History_of_JavaScript, besucht 26.6.2015[61] The University of Texas at Austin: What is Javascript?, 2005, https://www.utexas.edu/learn/javascript/

index.html, besucht 27.6.2015[62] Eclipse, The Eclipse Foundation, https://eclipse.org/, besucht 27.6.2015[63] IntelliJ: The Most Intelligent JAVA IDE, Jetbrains, https://www.jetbrains.com/idea/, besucht 27.6.2015[64] Bak L., Bracha G.: Dart, a new programming language for structured web programming, Google, 2011,

Aarhus, http://gotocon.com/dl/goto-aarhus-2011/slides/GiladBracha_and_LarsBak_OpeningKey-noteDartANewProgrammingLanguageForStructuredWebProgramming.pdf, besucht 27.6.2015

[65] Walrath K., Ladd S.: What is Dart?, O‘Reilly Media, 2012[66] Green A.: Powering Down Google Reader, Google Reader Blog, 2013, http://googlereader.blogspot.ch/

2013/03/powering-down-google-reader.html, besucht 25.6.2015[67] Hölzle U.: Update on Google Wave, Google Official Blog, 2010, http://googleblog.blogspot.ch/2010/08/

update-on-google-wave.html, besucht 25.6.2015[68] Horowitz B.: A fall sweep, Google Official Blog, 2011, http://googleblog.blogspot.ch/2011/10/

fall-sweep.html, besucht 25.6.2015[69] Hölzle U.: A second spring of cleaning, Google Official Blog, 2013, http://googleblog.blogspot.com.au/

2013/03/a-second-spring-of-cleaning.html, besucht 27.6.2015[70] TIOBE Software: TIOBE Index for June 2015, http://www.tiobe.com/index.php/content/paperinfo/

tpci/index.html, besucht 27.6.2015[71] Haxe Foundation: What is Haxe?, 2015, Haxe Foundation, http://haxe.org/manual/

introduction-what-is-haxe.html, besucht 27.6.2015



[72] Haxe Foundation: The Cross-platform Toolkit, 2015, Haxe Foundation, http://haxe.org/, besucht 27.6.2015

[73] Haxe Foundation: Haxelib, http://lib.haxe.org/, besucht 27.6.2015[74] OpenFL: Your vision, everywhere, 2015, http://www.openfl.org/, 2015, besucht 27.6.2015[75] Oracle: Using JavaFX UI Controls, Java Documentation, 2014, http://docs.oracle.com/

javase/8/javafx/user-interface-tutorial/ui_controls.htm#JFXUI336, besucht 27.6.2015[76] The Apache Software Foundation: Apache Flex® Tour de Flex Component Eplorer 1.2, 2014,

http://flex.apache.org/tourdeflex/index.html, besucht 27.6.2015[77] Bär P.: Richtlinien für Bau und Ausstattung von Turn- und Sporthallen, sowie die Erstellung

von Aussenanlagen, Sportamt Thurgau, Frauenfeld, 2004[78] Tischtennisball, http://www.google.com/patents/EP1924331B1?cl=de, besucht 19.6.2015[79] Axure Software Solutions: Axure RP7 - Create Prototypes of Websites & Apps Without Coding,

http://www.axure.com/, besucht 24.7.2015[80] W3C: Scalable Vector Graphics, http://www.w3.org/Graphics/SVG/, besucht 23.7.2015[81] Hall C.: PureMVC Framework - Code at the speed of thought, http://puremvc.org/, besucht 24.7.2015[82] Shams S.: PureMVC MultiCore Framework for Swift, https://github.com/PureMVC/

puremvc-swift-multicore-framework, besucht 24.7.2015[83] Hall C.: PureMVC Framework - Conceptional Diagram and Introduction,

PureMVC_Conceptual_and_Intro.pdf, 2008[84] Hall C.: PureMVC Project Begins, 2006, http://puremvc.org/content/view/31/181/, besucht 24.7.2015[85] Hall C.: puremvc-as3-multicore-framework/VERSION, 2008, https://github.com/PureMVC/

puremvc-as3-standard-framework/blob/master/VERSION, besucht 24.7.2015[86] Secchi M.: puremvc-haxe-multicore-framework/VERSION, 2013, https://github.com/PureMVC/

puremvc-haxe-multicore-framework/blob/master/VERSION, besucht 24.7.2015[87] Hall C.: Don‘t Hitch Your Dinghy to the Titanic, 2010, http://puremvc.org/content/view/159/181/,

besucht 24.7.2015[88] Emscripten, Emscripten is an LLVM-based project that compiles C and C++ into highly-optimizable

Javascript in asm.js format, https://kripken.github.io/emscripten-site/index.html, besucht 24.7.2015[89] Tizen, An open source, standards-based software platform for multiple device categories, including

smartphones, tablets, TVs, netbooks and automotive infotainment platforms, https://www.tizen.org/, besucht 24.7.2015

[90] Open webOS, The Next Generation Web Centric Plattform, http://www.openwebosproject.org/, besucht 24.7.2015

[91] Neko, One VM to run them all, http://nekovm.org/, besucht 25.7.2015[92] Android NDK, http://developer.android.com/intl/zh-CN/ndk/index.html, besucht 25.7.2015[93] Haxeflixel, Native Extensions, http://haxeflixel.com/documentation/native-extensions/,

besucht 27.7.2015[94] Shohat B.: Use native iOS/Android text fields in OpenFL, 2014, https://github.com/

bazzisoft-openfl-extensions/nativetext, besucht 27.7.2015[95] Byrne T.: Guise: Unified UI for Haxe, 2013, http://www.tbyrne.org/guise-unified-ui-for-haxe,

besucht 27.7.2015


ZHAW - Masterarbeit - Christian Kaegi - 28.8.2015 - v2.0.3 Selbständigkeitserklärung

[96] Byrne T.: Guise - A GUI library for Haxe supporting native and non-native controls, https://github.com/TomByrne/Guise, besucht 27.7.2015

[97] Haxe: Source debugging in Javascript, http://old.haxe.org/doc/js/source_debugging, besucht 28.7.2015[98] Seddon R.: Introduction to Javascript Source Maps, 2012, http://www.html5rocks.com/en/tutorials/

developertools/sourcemaps/, besucht 28.7.2015[99] Haxe: WWX 2015 - World Wide Haxe Conference, 2015, http://haxe.org/community/events.html,

besucht 16.08.2015

6. SelbständigkeitserklärungMit der Abgabe dieser Abschlussarbeit versichert der/die Studierende, dass er/sie die Arbeit selbständig und ohne fremde Hilfe verfasst hat (Bei Teamarbeiten gelten die Leistungen der übrigen Teammitglieder nicht als fremde Hilfe).Der/die unterzeichnende Studierende erklärt, dass alle zitierten Quellen (auch Internetseiten) im Text oder Anhang korrekt nachgewiesen sind, d.h. dass die Abschlussarbeit keine Plagiate enthält, also keine Teile, die teilweise oder vollständig aus einem fremden Text oder einer fremden Arbeit unter Vorgabe der eigenen Urheberschaft bzw. ohne Quellenangabe übernommen worden sind.

Ort, Datum: Stetten, 28. August 2015

Unterschrift Studierende/r:

Christian Kaegi

Simulationsprogramm zur Visualisierung der Vorgänge in ... · Abb. 46: Pixelgenaue Grafik -...

Documents

Transcript of Simulationsprogramm zur Visualisierung der Vorgänge in ... · Abb. 46: Pixelgenaue Grafik -...