Merge branch 'master' of wien.tomnetworks.com:hwmod
authorfabb <Administrator@WandTeppich.(none)>
Fri, 19 Mar 2010 17:53:09 +0000 (18:53 +0100)
committerfabb <Administrator@WandTeppich.(none)>
Fri, 19 Mar 2010 17:53:09 +0000 (18:53 +0100)
spec/Architektur.dia
spec/spec.tex

index 17a0869ac5bf596a791eb065e6ff16d29ff55978..176168ffab3ca7db92c74398f11efe51e2db777c 100644 (file)
Binary files a/spec/Architektur.dia and b/spec/Architektur.dia differ
index 6a5d6f1943c5e1ee8a5b606a838537d65cd2f10d..68dd72281640d05b3b5afc4e08b8475787640f69 100644 (file)
@@ -74,6 +74,30 @@ EXPRESSION = OPERAND \{ OPERATOR OPERAND \} ;
 
 In Abbildung \ref{fig:arch} ist der Aufbau des Taschenrechners zu sehen. Der Taschenrechner besteht aus folgenden Modulen:
 
+Bla:
+
+ps/2 schickt zeichen an controller, der nimmt nur gewünschte chars und schreibt die in die history in die editierbare "eingabezeile".
+
+dann bei einem "enter" sagt er dem parser dass der was hackeln soll
+
+der holt sich selbstständig den string aus der history und analysiert ihn mal - also ob es ein gültiger string ist
+
+dann brauchen wir schleifen, eine äußere für die strichrechnung und eine innere für die punktrechnung (k.a. wie das in vhdl geht)
+
+jedenfalls müssen bei z.b. a + b * c die b*c zuerst ausgerechnet werden
+
+diese einzelnen rechnungen - also z.b. b*c - schickt der parser an die alu die das ausrechnet und dann asynchron an den parser zurückschickt - das geht so lange weiter bis der ganze string abgearbeitet ist
+
+der parser muss bei den zwischenrechnungen die zwischenergebnisse im speicher behalten
+
+wenn er fertig ist liefert er das ergebnis an die history und benachrichtigt den controller dass er fertig ist
+
+achja, die zahlen zur/von der history muss der parser zum converter schicken - das geht leider nicht als zwischenstufe zwischen parser und history weil der parser sich einen erst zu analysierenden string von der history holt - es ist auch nicht sinnvoll zwischen alu und parser, weil zwischenergebnisse nicht neu umgewandelt werden müssen
+
+der controller verursacht dann den zeilenvorschub um 2 zeilen in der history (ringpuffer, index vorandrehen). eigentlich braucht der controller dem display modul nichts mitteilen, oder?
+
+es sollte vielleicht der controller das display modul veranlasen sich die daten aus der history zu holen (könnte auch die history)
+
 TODO Module soll der Parser in einer "`Schleife"' alle Teilberechnungen an die ALU weiterleiten und zB Zwischenergebnisse speichern? Die ALU könnte dann nur 2 Zahlen addieren/bla.
 Da in der History Zahlen als Character Strings abgelegt sind müssen diese für die ALU in Binärdarstellung umgewandelt werden - und Umgekehrt natürlich!