Merge branch 'master' of wien.tomnetworks.com:hwmod

diff --combined spec/spec.tex
index 9b6bbf63d33d2da694e3ab2ad2858abee6a1cebb,6a5d6f1943c5e1ee8a5b606a838537d65cd2f10d..68dd72281640d05b3b5afc4e08b8475787640f69
--- 1/spec/spec.tex
--- 2/spec/spec.tex
+++ b/spec/spec.tex
@@@ -46,7 -46,7 +46,7 @@@ EXPRESSION = OPERAND \{ OPERATOR OPERAN
  
  \req{Dabei soll Punkt- vor Strichrechnung gelten}
  
- \req{Die Zahlen dürfen im Zahlenbereich eines signed long liegen ($-2^31$ bis $2^31-1$)}
+ \req{Die Zahlen dürfen im Zahlenbereich eines signed long liegen ($-2^{31}$ bis $2^{31}-1$)}
  
  \req{Die Eingabe darf aus 70 Zeichen bestehen}
  
@@@ -74,30 -74,6 +74,30 @@@
  
  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!