Verfügbare Informationen zu "Allgemeine Hinweise"
Qualität des Beitrags: Beteiligte Poster: 3am3yyp Forum: TGI-PRAKTIKUM SS06 Forenbeschreibung: Tsogoo, Le & Inna aus dem Unterforum: HINWEIS Antworten: 1 Forum gestartet am: Donnerstag 09.06.2005 Sprache: deutsch Link zum Originaltopic: Allgemeine Hinweise Letzte Antwort: vor 17 Jahren, 11 Monaten, 2 Tagen, 17 Stunden, 51 Minuten
Alle Beiträge und Antworten zu "Allgemeine Hinweise"
Re: Allgemeine Hinweise
3am3yyp - 22.05.2006, 11:57Allgemeine Hinweise
Allgemeine Hinweise
Diese Seite dient als praktischer Ratgeber bei der Durchführung eines Mikroprogrammierprojekts im Rahmen des Praktikums Technische Grundlagen der Informatik an der Technischen Universität München. Eine formale Praktikumsordnung finden Sie hier
Ablauf des Projekts
1. Legen Sie zunächst fest, wer aus Ihrer Gruppe für das Mikroprogrammierprojekt die Aufgabe des Projektmanagers übernimmt. Melden Sie den Namen des Projektmanagers an Ihren Betreuer (beachten Sie die Hinweise für den Projektmanager).
Wenn Sie mit dem Mikroprogrammierprojekt beginnen, machen Sie sich zunächst mit der Aufgabenstellung und der mikroprogrammierbaren Maschine vertraut. Lesen Sie dazu die zur Verfügung stehende Dokumentation, installieren Sie die entsprechende Software und testen Sie einige Mikroprogramme aus der TGI-Übung. Wenn dabei Probleme auftreten sollten, wenden Sie sich bitte an die studentischen Betreuer, die zu den angegebenen Zeiten in den Praktikumsräumen anzutreffen sind.
Legen Sie dann fest, wer aus Ihrer Gruppe für welche Teile der Aufgabenstellung zuständig ist und überlegen Sie sich einen Zeitplan. Auf Basis dieser Arbeiten erstellen Sie dann das Pflichtenheft (beachten Sie die Hinweise zum Pflichtenheft).
Beginnen Sie nun mit der Spezifikation der zu erstellenden Mikroprogramme (beachten Sie die Hinweise zur Spezifikation).
An dieser Stelle noch ein Hinweis: Die Praktikumsprojekte sind keine 'Aufgaben' in dem Sinne, daß es dafür schon eine Lösung gibt. Es kann sich daher bei einigen Aufgaben durchaus ergeben, daß sie (mit vernünftigem Aufwand) nicht exakt nach Vorgabe lösbar sind. Wenn Sie in der Spezifikationsphase über ein derartiges Problem stolpern, besprechen Sie dies bitte mit Ihrem Projektbetreuer. Seien Sie gewiß, daß Ihnen so etwas natürlich nicht negativ angerechnet wird, vorausgesetzt, Sie können Ihre Ansicht vernünftig begründen.
2. Spätestens, wenn Sie glauben, daß Ihr Pflichtenheft und Ihre Spezifikation fertig ist, machen Sie einen Termin mit Ihrem Projektbetreuer aus, um Pflichtenheft und Spezifikation vorzustellen. Bitte machen Sie diesen Termin aber bereits frühzeitig aus, und nicht erst zwei Tage vor Ihrem Abschlußtermin!
Betrachten Sie bei diesem Termin Ihren Projektbetreuer als Ihren Auftraggeber (im Sinne der projektorientierten Durchführungsweise des Praktikums), d.h. versuchen Sie, ihm bei diesem Treffen Ihr Projektmanagement und Ihre Vorgehensweise bei der Lösung Lösung möglichst gut zu ``verkaufen''. Sie sollten daher bei diesem Termin vorbereitet sein und auch schriftliche Unterlagen (Pflichtenheft, Spezifikation) mitbringen, die Ihr Projektbetreuer dann behalten kann. Die Betreuungstermine gehen mit in die Bewertung Ihres Projekts ein.
Sollte Ihr Pflichtenheft oder Ihre Spezifikation nicht ausreichend sein, wird Sie Ihr Projektbetreuer zu einem weiteren Termin verpflichten.
3. Wenn Sie es für nötig erachten, können Sie (vor oder nach der Vorstellung Ihrer Spezifikation) weitere Termine mit Ihrem Projektbetreuer abmachen. Sie sollten dies z.B. immer dann tun, wenn die Aufgabenstellung mehrdeutig ist oder sie aus irgendwelchen Gründen Modifikationen vornehmen wollen/müssen. Einfachere Fragen können Sie natürlich auch per e-mail an Ihren Projektbetreuer richten. Fragen bzgl. der Programmierumgebung (Simulator der mikroprogrammierten Maschine) richten Sie bitte an die studentischen Betreuer, die zu den angegebenen Zeiten in den Praktikumsräumen sind. Die studentischen Betreuer können Ihnen auch helfen, wenn es um die Gliederung (nicht den Inhalt) Ihres Pflichtenhefts und der Spezifikation geht. Sollten sie ein Problem haben, das sie mit den studentischen Betreuern nicht lösen können, wenden Sie sich bitte an Ihren Projektbetreuer. Erst nachdem Ihr Projektbetreuer (als Ihr Auftraggeber) Ihre Spezifikation genehmigt hat, beginnen Sie mit der Implementierung. Dies schließt natürlich nicht aus, daß Sie zur Einarbeitung bereits kleinere Teile der Mikroprogramme am Simulator vorher ausprobieren können.
4. Nachdem alle Mikroprogramme am Simulator realisiert wurden, testen Sie diese Hilfe eines kleinen Maschinenprogramms aus, das die von Ihnen implementierten Befehle verwendet. Testen Sie dabei nicht einfach `wild drauflos', sondern überlegen Sie sich vorher genau die kritischen Fälle und testen Sie diese auch konkret ab.
5. Zum Abschluß des Projekts erarbeitet ein Mitglied aus Ihrer Gruppe die endgültige schriftliche Ausarbeitung (beachten Sie die Hinweise zur Ausarbeitung), während ein anderes Mitglied eine ca. 10-minütige Präsentation Ihres Projekts vorbereitet (Hinweise zum Vortrag). Der Projektmanager hält ebenfalls einen ca. 10-minütigen Vortrag zur Projektorganisation und Projektablauf (Hinweise für den Projektmanager).
6. Die Vorträge finden üblicherweise in den Räumen 01.06.011 oder 01.06.020 statt. Nähere Informationen erhalten Sie von Ihrem Betreuer.
7. Zu diesem Abschlußtermin liefern Sie bei Ihrem Projektbetreuer auch auch die schriftliche Ausarbeitung (elektronisch und am besten auch als Papier) und die Simulatoreingabedatei mit ihren Mikroprogrammen und dem Maschinentestprogramm ab.
Hinweise für den Projektmanager
Ein Mitglied Ihrer Gruppe übernimmt für das Mikroprogrammierprojekt die Funktion des Projektmanagers. Der Projektmanager hat die folgenden Aufgaben:
* Er organisiert ein erstes Treffen der Gruppe, in der festgelegt wird, wer die schriftliche Ausarbeitung erstellt und wer den Abschlußvortrag hält. Das Ergebnis dieser Festlegung sowie der von Ihnen geplante Bearbeitungszeitraum des Projekts wird dem Projektbetreuer vom Projektmanager unverzüglich mitgeteilt.
* Er organisiert alle weiteren Treffen der Gruppe sowie die Besprechungstermine mit dem Projektbetreuer. Der Projektbetreuer hat u.a. dafür zu sorgen, daß die Gruppenmitglieder vollzählig, pünktlich und vorbereitet zu den Besprechungen erscheinen.
* Er erstellt und archiviert schriftliche Protokolle der Gruppentreffen und der Besprechungstermine. In den Protokollen ist kurz (aber aussagekräftig) zu notieren, welche Themen besprochen wurden. Insbesondere sind alle Entscheidungen, die während einer Besprechung gefällt wurden (z.B. Implementierungsentscheidungen, Anpassungen der Aufgabenstellung, Termine, ...), festzuhalten. Die Protokolle sollten dem Projektbetreuer unmittelbar nach einem Treffen / einer Besprechung zugesandt werden. Auf jeden Fall müssen sie der Dokumentation des Projektverlaufs (s.u.) beigefügt werden.
* Er organisiert und dokumentiert den Projektverlauf, insbesondere den Arbeits- und Zeitplan. Der Projektmanager ist für die Planung der Aufgabenverteilung im Projekt und die Zeitplanung ebenso verantwortlich wie für die Überwachung dieser Pläne. Der Projektmanager hat also zunächst diese Planungen zu erstellen. Dazu gehört unter anderem:
o wer hat welche Aufgaben zu erfüllen?
o welcher Zeitaufwand ist für diese Aufgaben notwendig?
o bis wann sollen die Arbeiten durchgeführt werden?
o wann werden Treffen der Gruppe durchgeführt?
o wann werden Treffen mit dem Betreuer notwendig?
Er hat die Einhaltung der Planung auch zu überwachen. Falls die Planung nicht eingehalten werden kann, sind die Ursachen zu ermitteln, und es müssen geeignete Maßnahmen ergriffen werden. Die Planungen, die Abweichungen, deren Ursachen und die getroffenen Maßnahmen sollen vom Projektmanager während der Projektlaufzeit dokumentiert werden. Diese Dokumentation ist am Projektende dem Projektbetreuer zu übergeben.
* Er hält am Ende des Projekts einen Vortrag von ca. 10 Minuten Dauer über den Projektverlauf. In diesem Vortrag ist konkret und im Detail auf die organisatorische Durchführung des Projekts einzugehen, insbesondere auf die Planung, Abweichungen von dieser Planung und deren Ursachen.
Hinweise zum Pflichtenheft
Ein gutes Pflichtenheft sollte folgende Punkte umfassen:
* Sollanalyse: Vollständige Beschreibung der Aufgabenstellung, also die zu realisierenden Befehle, Adressierungsarten, etc. Dabei brauchen die Befehlsbeschreibungen aus der Beschreibung der Zielarchitektur nicht wiederholt werden. Lücken, Mehrdeutigkeiten, Probleme etc. in der vorgegebenen Beschreibung sollten jedoch erkannt und geschlossen werden.
* Istanalyse: Beschreibung der für Ihr Projekt relevanten (!) Merkmale der mikroprogrammierten Maschine. Beschreibung der vorgegebenen Infrastrur, Dokumentation und Hilfsmittel.
Bei der Beschreibung der Merkmale der Maschine sollten Sie versuchen, bereits Bezug zu Ihrer Aufgabenstellung zu nehmen (also welche Merkmale könnten sich positiv/negativ auf Ihre Arbeit auswirken, wo sind Probleme zu erwarten). Diese Überlegungen benötigen Sie auch, um eine vernünftige Aufwandsschätzung für Ihren Zeitplan machen zu können.
* Aufstellung der von Ihnen zu liefernden Leistungen, also Ihrer 'Vertragsverpflichtungen'.
Das Pflichtenheft sollte also mehr sein, als eine bloße Aufstellung der von Ihnen zu realisierenden Befehle und eine allgemeine Beschreibung der Maschine.
Ausgehend von obigen Überlegungen sollten Sie einen detaillierten Zeit- und Arbeitsplan erstellen. Im Idealfall enthält dieser die genaue Aufteilung der einzelnen Teilaufgaben und Arbeitsschritte auf die beteiligten Personen (z.B. wer spezifiziert wann welche Befehle), Aufwandsschätzungen für die einzelnen Schritte, ihre zeitliche Abfolge, sowie Fertigstellungs- und Überprüfungstermine.
Hinweise zur Spezifikation
Zu spezifizieren ist hier, wie Sie die zu realisierenden Maschinenbefehle implementieren wollen. Die Spezifikation beschreibt also auf einer abstrakteren Ebene, was Ihr Mikroprogramm einmal tun soll.
* Bei komplexeren Befehlen sollte zunächst die globale Vorgehensweise dargelegt werden, also der Algorithmus, den Sie implementieren wollen.
* Die einzelnen (logischen!) Schritte Ihres Mikroprogramms sollten genügend detailliert dargelegt werden, so daß Sie glaubhaft machen können, daß Ihre geplante Vorgehensweise wirklich realisierbar ist. Es ist noch nicht erforderlich, daß Sie bis ins letzte Bit wissen, wie die Realisierung der einzelnen Schritte schlußendlich aussehen wird. Sie sollten sich hier also z.B. überlegen: wie fließen die Daten, welche Funktionseinheiten werden benutzt? Unwesentliches soll hier weggelassen werden, die Beschreibung soll auf relativ hoher Abstraktionsebene erfolgen (also z.B. Inhalt von Register R0 über die ALU an den Adreßbus legen, nicht: SRC=ZA, DEST=NOP, Y-MUX=AB). Wichtig ist, daß aus der Spezifikation hervorgeht, welche Lösungsideen sie für die Aufgabe haben. Als Darstellungsform kann z.B. ein Flußdiagramm oder auch einfach eine numerierte Stichpunktliste gewählt werden.
* Schwierigkeiten und Besonderheiten sollten angesprochen, Ihre gewählte Lösung begründet und Realisierungsalternativen diskutiert werden. Dieser Punkt ist wichtig!
Die Spezifikation soll im Idealfall noch so abstrakt sein, daß ein Leser ohne Spezialkenntnis der Maschine Ihren Lösungsansatz verstehen kann, aber auch nachvollziehen kann, warum Sie gerade diesen Lösungsweg gewählt haben. Andererseits sollte sie aber auch detailliert und genau genug sein, so daß ein Programmierer, der diese Spezifikation bekommt, die Befehle auch so implementiert, wie Sie es sich vorgestellt haben. Auf keinen Fall soll sie lediglich eine (womöglich erst nach der eigentlichen Implementierung) entstandene Beschreibung der einzelnen Mikrobefehle sein.
Hinweise zur Ausarbeitung/Dokumentation
Ein Mitglied Ihrer Gruppe zeichnet für die Ausarbeitung verantwortlich, die am Ende des Projekts bei Ihrem Projektbetreuer abzugeben ist. Die Ausarbeitung sollte die nachfolgende Aspekte umfassen:
* Anwenderdokumentation
* Entwicklerdokumentation
* Quellcode
Als Anlage sollte die Ausarbeitung eine aktuelle Kopie Ihres Pflichtenhefts und Ihrer Spezifikation enthalten. Siehe dazu die getrennten Hinweise zum Pflichtenheft und zur Spezifikation.
Anwenderdokumentation
Da die von Ihnen zu realisierenden Maschinenbefehle (die ja die 'Anwenderschnittstelle' Ihrer Mikroprogramme darstellen) in der Regel bereits in der Aufgabenbeschreibung hinreichend dokumentiert sind, brauchen Sie hier normalerweise nicht viel zu beschreiben (Sie müssen dann aber zumindest auf die Beschreibung verweisen!). Dieser Abschnitt Ihrer Dokumentation sollte jedoch (soweit es angebracht ist) folgende Punkte enthalten:
* Genaue Dokumentation etwaiger Abweichungen und Ergänzungen bzgl. der Beschreibung in der Aufgabenstellung (z.B. Änderung der Flags, eingeschränkte Wertebereiche etc.)
* Beschreibung des von Ihnen mit Ihren Befehlen erstellten Maschinenprogramms. Diese soll als eine Art 'Tutorial' für die Benutzung (einiger) Ihrer Befehle dienen.
Entwicklerdokumentation
Die Entwicklerdokumentation ist der Teil Ihrer Dokumentation, der bei einem richtigen Projekt firmenintern bliebe. Sie erfüllt mehrere Zwecke, u.a.:
Einarbeitung anderer Entwickler in Ihre Implementierung (z.B. bei späteren Modifikationen / Optimierungen)
* Weitergabe von Erfahrungen an andere Entwickler in ähnlichen Projekten
* Weitergabe von Verbesserungsmöglichkeiten an übergeordnete Abteilungen
* Qualitätssicherung
Ihre Dokumentation sollte im Idealfall alle diese Punkte berücksichtigen, d.h. die folgenden Themen abdecken:
* Beschreibung Ihres Mikroprogramms. Dies sollte eine Erweiterung der Spezifikation sein, in der sie verstärkt auf Details der Maschine eingehen, und auch die von Ihnen verwendeten 'Tricks' erklären. Insbesondere sollten Sie bei der Beschreibung der einzelnen Programmschritte begründen, warum Sie diese genau so realisiert haben, wie Sie es getan haben. Sie sollten hier auch dokumentieren, welche Stellen in Ihrem Programm womöglich problematisch sein könnten (nur weil das Programm auf dem Simulator läuft, muß es auch auf der realen Maschine laufen!), und wo das Programm noch optimiert werden könnte. Ebenso sollten Sie hier natürlich auch detailliert etwaige Abweichungen von Ihrer ursprünglichen Spezifikation beschreiben und begründen.
Falls erforderlich, kann in der Dokumentation auf Teile der Spezifikation (z.B. Algorithmus-Beschreibungen) verwiesen werden.
* Im Fall der Mikroprogrammierprojekte gibt es bei uns gleich drei 'übergeordnete Abteilungen': Die eine ist die, die die mikroprogrammierbare Maschine entwickelt (hat). Wenn Sie bei der Realisierung Ihrer Mikroprogramme also irgendwo auf Probleme gestoßen sind, die durch die Maschinenarchitektur gegeben sind (z.B. Sie können einen Datentransport nicht so durchführen, wie Sie es eigentlich bräuchten), sollten Sie darüber nachdenken, ob dieses Problem durch eine Anpassung der mikroprogrammierbare Maschine vermieden werden könnte, und der 'Hardware-Abteilung' eine entsprechende Modifikation vorschlagen (oder denen wenigstens das Problem klarmachen).
Ihre zweite übergeordnete Abteilung ist die, die die Zielarchitektur definiert (hat), die der Maschinenprogrammierer sieht. Auch hier kann es vorkommen, daß durch eine einfache, semantisch nicht relevante Änderung der Schnittstelle die Implementierung stark vereinfacht wird (z.B. könnte ein Befehl wesentlich einfacher zu realisieren sein, wenn man den Registeroperanden statt im RA- Adreßfeld im RB-Adreßfeld spezifiziert). Auch solche Optimierungsmöglichkeiten sollten sie spezifizieren.
Die dritte Abteilung ist endlich die, die die Programmier-Umgebung JMIC entwickelt. Besonders hier können und sollten sie konstruktive (!) Kritik und Verbesserungsvorschläge anbringen.
* Als Teil der Qualitätssicherung sollten sie schließlich auch noch dokumentieren, wie Sie Ihre Mikroprogramme getestet haben. Dabei ist nicht so sehr interessant, daß sie die Befehle im Simulator durchgelaufen sind (davon wollen wir doch einmal ausgehen). Vielmehr sollten Sie versuchen nachzuweisen, daß Ihre Programme wirklich in allen Situationen fehlerfrei sind, was sie nur durch genaue Angaben der Testbedingungen erreichen können, also: Welche Kombinationen von Befehlen haben Sie getestet? Mit welchen Operanden? Was kam dabei heraus? Wurden in der Testphase noch Fehler gefunden? Wenn ja, welche? Wie wurden sie behoben? Sie sollten hier konkrete Angaben machen, nicht nur pauschale Aussagen ("Wir haben alles getestet und es lief").
Insbesondere sind beim Testen natürlich immer auch Grenz- und Fehlerfälle zu prüfen (z.B. Division durch Null, Überlauf etc.)
Quellcode
Der Quellcode sollte in elektronischer Form (*.mpr Datei des Simulators JMic) abgegeben werden. Achten Sie darauf, das die entsprechende Datei nicht nur ein Mikroprogramm, sondern auch ein geeignetets Maschinenprogramm enthält, mit denen die Betreuer Ihre Arbeiten testen können. Die Dokumentation sollte in jedem Fall eine kurze Beschreibung dieser Testprogramme enthalten.
Technisches zur Abgabe
Die Ausarbeitung ist in Form eines HTML-Dokuments anzufertigen. Eine Einführung und Referenzen zu hat HTML finden Sie z.B. unter http://www.selfhtml.org. Nutzen Sie bitte die Möglichkeit der Rechnerbetriebsgruppe, in der Rechnerhalle eine eigene Homepage anzulegen. Senden Sie dann den entsprechenden Link an ihren Betreuer.
Um Ihr geistiges Eigentum zu schützen, sollten Sie ihre Ausarbeitung nur einem ausgewählten Personenkreis zugänglich machen. Näheres dazu finden Sie hier. Bitte vergessen Sie nicht, Ihrem Betreuer auch das entsprechende Passwort zuzusenden.
Achtung: Die Speicherung der Passwörter in der Rechnerhalle und das Versenden von Passwörtern per Email ist nicht sicher! Benutzen Sie daher für ihre TGI-Projekte keine "wichtigen" Passwörter.
Hinweise zum Vortrag
Am Ende Ihres Projekts haben Sie dieses in einer ca. 10-minütigen Präsentation vor einem Publikum, bestehend aus Ihrem Betreuer und einigen anderen Praktikumsgruppen, vorzustellen. Dazu einige Hinweise:
* Bereiten Sie Vortragsmaterialien vor. Vorträge finden üblicherweise in den Räumen 01.06.011 oder 01.06.020 statt. Dieser Räume sind neben einem Overheadprojektor auch mit einem Video-Beamer ausgerüstet, so daß sie Ihre Präsentationen auch z.B. mit Netscape oder PowerPoint machen können. Sie können entweder einen eigenen Laptop benutzen (stellen Sie vorher sicher, daß der VGA-Ausgang aktiviert ist!) oder einen vorhandenen Windows- 98 PC nutzen (teilen Sie dies rechtzeitig vorher Ihrem Betreuer mit!). Bei der Verwendung des PCs haben Sie allerdings das Problem, daß der Monitor beim Vortrag hinter Ihnen steht. Überlegen Sie sich in jedem Fall vorher gut, was Sie zeigen wollen, und probieren Sie gegebenenfalls auch die Technik vorher einmal aus.
Widerstehen Sie bitte der Versuchung, statt speziell ausgearbeiteten Folien einfach mittels Netscape die Ausarbeitung an die Wand zu projezieren.
* Achten Sie darauf, daß Ihre Folien (bzw. Bildschirmseiten, wenn Sie den Beamer verwenden) übersichtlich und lesbar sind. Die Schrifthöhe sollte auf Folien mindestens 5-7 mm betragen; Sans-Serif-Schriften (z.B. Helvetica) sind besser zu lesen als Schriften mit Serifen. Denken Sie auch bei Bildern an die Lesbarkeit der Beschriftung. Bei Verwendung des Beamers sollten Sie an dessen begrenzte Auflösung (1024x768) denken.
* Denken Sie daran, daß Sie in 10 Minuten sicher nicht Ihr ganzes Projekt in voller Tiefe vorstellen können. Sie sollten sich also interessante Aspekte herausgreifen und diese dann so vorstellen, daß der Zuhörer etwas davon hat. Es wird Ihnen keinesfalls negativ angerechnet, wenn Sie nicht auf alle zu realisierenden Befehle eingehen (vorausgesetzt, sie präsentieren nicht gerade nur die Primitiv-Befehle und lassen alles schwieriger zu erklärende weg). Es wird Ihnen aber negativ angerechnet, wenn Sie wesentlich zuviel Zeit brauchen. Die Präsentation sollte so gehalten sein, daß auch jemand, der nicht jedes Bit der mikroprogrammierten Maschine auswendig kennt, Ihrem Vortrag folgen kann. Sie sollten also im Regelfall nicht die Mikroprogramm-Tabelle auflegen und die einzelnen Bits erklären, sondern vielmehr auf abstrakterer Ebene die Vorgehensweise der Implementierung erläutern (etwa wie in der Spezifikation). Zudem sollten Sie im Vortrag natürlich auch kurz auf Aufgabenstellung, Test, Bewertung und Optimierungsmöglichkeiten eingehen.
* Kurz, versuchen Sie Ihr Projekt möglichst gut zu 'verkaufen'.
Weiterführende Dokumentation
* Beschreibung der mikroprogrammierbaren Maschine (ps)(ps.gz)(pdf)
* Allgemeine Aufgabenstellung (ps)(ps.gz)(pdf)
* Beschreibung der Zielarchitektur (ps)(ps.gz)(pdf)
* Die Unterlagen zur Übung im Wintersemester 2004/2005 finden Sie hier
Software
JMic: Installation und Starten des Programms
Im Praktikum wird der Simulator JMic eingestetzt, der die mikroprogrammierbare Maschine mit Hilfe eines Java-Programms simuliert. Dieser ist auf den Rechnern der Rechnerhalle bereits installiert. Zum starten des Simulators geben Sie einfach ein:
JMic &
Falls Sie lieber auf ihrem eigenen Rechner arbeiten wollen, können Sie sich hier das entsprechende JAR-Archiv herunterladen:
* JMic.v1.02.jar Simulator JMic, Version 1.02
Unter der Voraussetzung, dass Sie eine Java-Laufzeitumgebung (JRE) installiert haben, können Sie den Simulator dann mit Hilfe des Kommandos
java -jar JMic.v1.02.jar
starten. Unter Windows starten Sie das Programm mit einem Doppelklick.
MIC 5.3 - Simulator für Windows
Da JMic noch ein paar Kinderkrankheiten hat - siehe Fehlerliste im TGI-Wiki - wird der alte Simulator, der nur unter Windows läuft, zur Verfügung gestellt.
* mic.exe
* Anmerkungen zu dieser Version
* Implementierung von IFetch
* Beschreibung
* Errata zur Beschreibung
Bedienung von JMic
Allgemeines
Nach dem Start wird im oberen Fensterbeich der Mikroprogrammspeicher, links unten die Register und rechts unten der Hauptspeicher der mikroprogrammierbaren Maschine angezeigt. Sie können jederzeit über den Menüpunkt Ansicht neue Fenster öffnen. Im Hintergrund ist ein Übersichtsplan der mikroprogrammierbaren Maschine dargestellt.
Ganze Zahlen sollten in der Maschine hexadezimal eingegeben werden. Stellen Sie dazu dem Wert das Zeichen # voran. Ohne dieses Zeichen werden die Zahlen als dezimale Werte interpretiert.
Eingabe von Mikroprogrammen
Durch einen Doppelklick auf eine Mikroinstruktion im oberen Fenster öffnet sich ein Dialogfenster zur Eingabe von Mikroinstruktionen. In diesem Dialog können Sie links oben die gewünschte Mikroinstruktion auswählen. Daneben befindet sich ein Textfeld, in das Sie einen beliebigen Kommentar eingeben können. Bei Mikroinstruktionen, die als Einsprung in dei Implementierung eines Maschinenbefehls dienen, sollte hier der Mnemonic des Maschinenbefehls eingetragen werden (z.B. ADD RA, RB oder JNZ imm).
Darunter können Sie geeignete Mikroinstruktionen auswählen. Die Zahlen in eckigen Klammern entsprechen den jeweiligen Bits der Mikroinstruktion, wie sie in der Beschreibung der mikroprogrammierbaren Maschine erklärt sind. Diese Bits werden am unteren Rand des Dialogs auch binär dargestellt.
Am untersten Rand des Dialogs finden Sie vier Knöpfe, mit denen Sie die eingegebenen Werte übernehmen oder verwerfen können. Auserdem ist es möglich, die Mikroinstruktion mit Standardwerten zu belegen. Diese Werte bewirken, das sich bei der Ausführung der Mikroinstruktion kein Register und keine Speicherzelle der Maschine verändert.
Mapping PROM
Ein Programmieren des Mapping-PROMs, das die Zuordnung zwischen Op-Codes der Maschinenbefehle und den Anfangsadressen der sie realisierenden Mikroprogramme enthält, ist im Simulator nicht möglich. Stattdessen ist das Mapping-PROM nach der folgenden Regel fest programmiert:
Der Opcode i wird auf die Mikroprogrammadresse 16 * i abbgebildet
Beispiel: das Mikroprogramm des Maschinenbefehles mit Op-Code 47 (hex) beginnt an Adresse 470 (hex) des Mikroprogrammspeichers.
Hauptspeicher
Der Inhalt des Hauptspeichers ist im Fenster rechts unten dargestellt. In der ersten Spalte steht die Adresse der Speicherzelle, in der zweiten ihr Inhalt (beides in hexadezimaler Schreibweise). In der dritten Spalte wird versucht, den Opcode des Maschinenbefehls darzustellen. Dies ist nicht immer sinnvoll, da nicht jede Speicherzelle auch einen Maschinenbefehl enthält. Zum ändern einer Hauptspeicherselle klicken Sie bitte auf die mittlere Spalte.
Register
Im Fenster links unten werden die Registerinhalte angezeigt und modifiziert. Ganz links befinden sich die 16 Allzweckregister und das Q-Register. Per Konvention stehen dem Maschinenprogramm die Register r0-r7 zur Verfügung, während die Register r8-r15 sowie das Q-Register dem Mikroprogramm zur Speicherung von Zwischenergebnissen dient. Sie können den Register jederzeit beliebige Werte zuweisen.
Links neben den ALU-Registern werden oben die beiden 4-Bit Statusregister angezeigt. Auch diese können durch Anklicken gesetzt und gelöscht werden. Darunter wird die aktuelle Mikroinstruktion, der Mikrobefehlszähler, der Maschinenbefehlszähler und der Inhalt des Maschineninstruktionsregisters (IR) angezeigt.
Das Feld "Aktuelle Instruktion" enthält die Adresse der Mikroinstruktion, die sich gerade im Mikroinstruktionsregister befindet. Beim nächsten Taktimpuls wird also diese Mikroinstruktion ausgeführt. Das Feld "Mikro-BZ" zeigt den Inhalt des Mikrobefehlszählers des Am2910. Dieser ist in den meisten Fällen um eins größer als die aktuelle Mikroinstruktion. Die Felder "Maschinen-BZ" und "Maschinen-IR" sind selbsterklärend.
Achtung: in den allermeisten Fällen sollten nur die Felder "Aktuelle Instruktion" und "Maschinen-BZ" editiert werden.
Ausführen von Programmen
Nach der Eingabe von Mikro- und Maschinenprogrammen und der Initialisierung der Register kann die Arbeitsweise der Maschine simuliert werden. Zweckmäßigerweise beginnt man dabei bei einer schrittweisen Simulation, um das Verhalten der Maschine im Detail nachvollziehen zu können. Um die Abarbeitung eines Taktes zu simulieren, wählt man den Menüpunkt Einzelschritt im Menü Simulation oder drückt auf den Knopf mit dem senkrechten Balken und Pfeil in der Befehlsleiste.
Die Maschine kann auch in einen kontinuierlichen Simulationsmodus versetzt werden, indem man Starten im Menü Simulation auswählt. Es werden dann solange einzelne Takte ausgeführt, bis der Menüpunkt Stop ausgewählt wird. Alternativ kann diese Art der Simulation auch durch eine Betätigung der entsprechenden Knöpfe in der Befehlsleiste gewählt werden.
Mit dem Menüpunkt Haltepunkt setzten können sie Mikroinstruktionen kennzeichnen, bei denen eine Simulation immer anhalten soll. Setzen Sie beispielsweise einen Haltepunkt an der Mikroinstruktion 000, hält die Simulation immer zu Beginn der Ausführung eines Maschinenprogramms an.
Speichern und Laden
Über die Menüpunkte Öffnen und Speichern lassen sich die Daten auf die übliche Weise im Hintergrundspeicher ablegen. Es werden sowohl der Mikro-, also auch der Maschinenprogrammspeicher sowie die Registerinhalte gesichert. Die Datei wird in einem ASCII-Format gespeichert, das auch mit einem Texteditor manipuliert werdem kann.
Beim Öffnen von Dateien werden nur die Speicherbereiche überschrieben, die in der zu öffnenden Datei auch sinnvolle Werte enthalten. Dadurch wird es möglich, mehrere Dateien in Folge zu öffnen und so die verschiedenen Mikroprogramme miteinander zu kombinieren.
Mit folgendem Code, können Sie den Beitrag ganz bequem auf ihrer Homepage verlinken
Weitere Beiträge aus dem Forum TGI-PRAKTIKUM SS06
Ähnliche Beiträge wie "Allgemeine Hinweise"
Wichtige Hinweise - unknow (Freitag 08.09.2006)
allgemeine arbeitsrichtlinien - tinchen (Donnerstag 16.03.2006)
Alben - Allgemeine Chartspositionen - vanessa (Donnerstag 05.10.2006)
ALLGEMEINE FOREN REGELN! - Viper (Donnerstag 01.09.2005)
Allgemeine Regeln & Forum Regeln - Lindsay (Samstag 14.07.2007)
Flüsterpost - hannihorse (Dienstag 01.07.2008)
Allgemeine Storyline - AlbusDumbledore (Mittwoch 13.07.2005)
Hinweise für Meilenstein Präsentationen - jane (Donnerstag 19.10.2006)
Allgemeine Hinweise - ashanti (Donnerstag 29.03.2007)
Allgemeine Hinweise - Lars (Dienstag 27.06.2006)