robo_wolf,
Du bewegst Dich schon sehr souverän in unserem Programm 
.
Am Beispiel des Flankenbit-Fehlers kann man gut sehen, wie wichtig es war, von vornherein die Tabellen-Indexprüfung einzubauen. Nur dadurch konntest Du die Fehlerursache sofort erkennen. Hätten wir die Prüfung weggelassen, hätte das Programm plötzlich komische Z-Werte geliefert und Du hättest sehr viel mehr Zeit gebraucht, um den Fehler ausfindig zu machen. Also: Die Programmiermethode "diesen Fall brauche ich nicht zu berücksichtigen, er kann ja gar nicht vorkommen" führt zu labilen Programmen. Was passieren kann, wird früher oder später auch passieren (noch ein Korollar zu Murphy's law 
).
Die andere Lösung für das Flankenbit-Problem ist eine modifizierte Übergangstabelle
Code:
TBL_UEBERGANG_01:
.dw 0x0010 ; Tabellenlänge
; T = 1 T = 0
.dw 0x0200 ; Z=0 -> Z=2,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0308 ; Z=1 -> Z=3,Flanke=0 / Z=0,Flanke=1 /
.dw 0x0400 ; Z=2 -> Z=4,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0501 ; Z=3 -> Z=5,Flanke=0 / Z=1,Flanke=0 /
.dw 0x0602 ; Z=4 -> Z=6,Flanke=0 / Z=2,Flanke=0 /
.dw 0x0703 ; Z=5 -> Z=7,Flanke=0 / Z=3,Flanke=0 /
.dw 0x0F04 ; Z=6 -> Z=F,Flanke=1 / Z=4,Flanke=0 /
.dw 0x0705 ; Z=7 -> Z=7,Flanke=0 / Z=5,Flanke=0 /
.dw 0x0200 ; Z=8 -> Z=2,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0000 ; Z=9 -> Z=0,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0000 ; Z=A -> Z=0,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0000 ; Z=B -> Z=0,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0000 ; Z=C -> Z=0,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0000 ; Z=D -> Z=0,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0000 ; Z=E -> Z=0,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0705 ; Z=F -> Z=7,Flanke=0 / Z=5,Flanke=0 /
;
Du siehst, ich habe sie um 8 zusätzliche Zustände erweitert. Dadurch kann man jetzt festlegen, welcher Z-Wert bei gesetztem Flankenbit angenommen werden soll - man braucht es also nicht mehr per Programm zu löschen.
Das sieht zuerst ziemlich banal aus, es steckt aber mehr dahinter: Beim Programmieren gibt's immer den Dualismus zwischen Algorithmus und Datenstruktur; so ähnlich wie der Teilchen-Welle-Dualismus in der Quantenphysik. Der erste, der auf diesen Sachverhalt hingewiesen hat, war, meines Wissens, Prof. Niklaus Wirth von der ETH in Zürich. Er hat darüber ein bis heute sehr lesenswertes Buch verfasst (Niklaus Wirth, "Algorithmen und Datenstrukturen", B.G. Teubner 1983, ISBN 3-519-02250-8. ). Er zeigt, dass man beim Programmieren immer die Wahl hat, einen bestimmten Ablauf entweder in der Datenstruktur (z.B. in Tabellen) oder als Algorithmus (z.B. einer "case"-Abfrage) abzubilden. Eigentlich habe ich die Übergangstabelle in unserem Beispiel nur eingeführt, damit Du 'mal beide Seiten kennenlernst. Welchen der beiden Wege man wählt, hängt immer von der Anwendung und vom persönlichen Geschmack ab. Ich nehme öfters den Weg über die Datenstruktur, weil komplizierte Abläufe so oft übersichtlicher und wartungsfreundlicher darzustellen sind.
Im übrigen ist das Beispiel von Prof. Wirth auch ein lehrreiches Kapitel Technikgeschichte: Er entwickelte die Programmiersprachen Lillith, Pascal, Modula und Oberon. Unter seiner Leitung genoss die Informatikforschung der ETH Zürich einen weltweit führenden Ruf. - Aber es war die Zeit, als in Deutschland allen Ernstes eine Diskussion über die Einführung einer "Computersteuer" geführt wurde und die Mittel für die Informatikforschung (auch in Deutschland) stark eingeschränkt, wenn nicht gar zusammengestrichen wurden. - Na, schlussendlich war spätestens nach seiner Emeritierung die Informatikforschung in der Schweiz so gut wie nicht mehr existent. Genau wie in Deutschland zog man es vor, einmalige Gelegenheiten gemütlich zu verschlafen 
, mit den bekannten Folgen.
Bin gespannt auf Deine nächste Version!
Ciao,
mare_crisium
ZitierenZitat von robo_wolf
- deswegen das RAM im Code-Schnipsel.
Lesezeichen