Hardware > Hardware (Classic 16-/32-Bit)

68K30L, Falcon und Suska-III-T2

<< < (41/149) > >>

guest2205:
So der Vorzeichenbug wurde von Wolfgang gefixt aber jetzt wird es richtig kompliziert! Ich sage nur Interrupt! Der Validator hat jetzt einen Fall gefunden der im Amiga auch praxisrelevant ist. Wird beim Atari ST bestimmt auch so sein.
Über IPL wird ein Interrupt ausgelöst. Genau in dem Augenblick in dem die Interruptstatemaschine gestartet wird, wird der Interrupt an den IPL-Eingängen gelöscht - genau nach dem letzten Zyklus des Befehls vor dem Interrupt. Der IPL-Status im Auslösemoment des Interrupts wird nicht gespeichert und somit wird der Interruptvector von $000060 und nicht von der zum Interrupt passenden Adresse geholt. => Absturz!!!

Viele Grüße
TobiFlex

guest2205:
So es geht fleißig weiter:
Opcode: 0x486f  PEA
Der auf den Stack geschriebene Wert ist genau um 2 zu klein.

Opcode: 0xc5c1 MULS D1,D2 ist erstmal nur suspekt. Kann die Validatordiagramme noch nicht richtig deuten. Es scheint fast so als würde eine Interruptanmeldung über IPL die Multiplikation aus dem Tritt bringen. Bitte Simulieren!

Viele Grüße
TobiFlex

wfoerster:
Ok,
ich habe Punkt für Punkt durchgesehen.
Interrupts:
genau in dem Moment, in dem ein Intterrupt in Verarbeitung geht wird er in EXCEPTION_Q gespeichert. Das passiert im Prozess STORE_CURRENT_EXCEPTION. Ich habe beim Entwurf des Interrupt-Handlers auf diesen Punkt geachtet. Vielleicht ist er aber noch nicht ganz korrekt umgesetzt. In emutos und in TOS1.00, welche beide die Interrupts intensiv verwenden, funktioniert alles prima. Ich hatte seinerzeit Fehler drin, was sich in einer springenden Maus, in nicht restaurierten Menüs, in Abstürzen usw. wiederspiegelte. Das passiert aber mit der aktuellen Version unter emutos und TOS1.00 nicht mehr. Daher weiss ich nicht genau, ob der Absturz nicht eine Folge eines anderen Fehlers ist. Vielleicht kannst Du, Tobias, sagen ob so etwas möglich wäre. Also kurz zusammengefasst, Sobald ein Interrupt ausgelöst wird und in Verarbeitung geht, wird der Interrupt Vektor quellen-konsistent verwendet.

Zu den Spezialfällen:
ich habe mittlerweile zu den folgenden Fällen die gleiche Meinung wie Tobias. Diese Spezialfälle waren bisher nicht korrekt, sind aber nun richtiggestellt:
ADDA -(Ax), Ax: es wird zum undekrementierten Wert also Ax addiert.
CMPA -(Ax), Ax: es wird mit dem undekrementierten Wert von Ax verglichen.
SUBA -(Ax), Ax:  es wird vom undekrementierten Wert also Ax subtrahiert.
MOVE Ax, -(Ax): es wird der undekrementierte Wert, also Ax nach Ax-2 geschrieben.

Opcode: 0xc5c1 MULS D1,D2:
die Multiplikation dauert lange. Daher wird in dem Systemzustandsautomat im Zustand WAIT_OPERATION auf das Ergebnis gewartet und dann nach FETCH_BIW_1 verzweigt. Erst in FETCH_BIW_1 werden Interrupts, registriert. Die Interrupt-Zustandssteuerung wartet also bis nach FETCH_BIW_1 und dann nach IDLE verzweigt wird. Das steuernde Signal ist CTRL_RDY. Ich kann mir daher nicht vorstellen, dass da was schief geht. Ich würde vorschlagen das mit PEA erst zu richten und dann nochmal zu sehen, ob's nicht weitergeht.

PEA:
das ist vermutlich falsch. Ich werde es richten und Tobias ein Update schicken.

Spezialfälle:
ich habe vor ein Dokument zu verfassen, in dem alle Spezialfälle wie beispielsweise oben beschrieben zusammengestellt sind. Es gibt, wie ich gesehen habe, nicht nur bei uns Diskussionen über diese Dinge. Der Prozessor hat meiner Meinung nach etwa 10 bis 20 von diesen. Ferner ist das Prefetch-Verhalten des Prozessors ein Thema, um auch self-modifying Code lauffähig zu bekommen. Auch hier müsste man eventuell etwas machen.

Viele Grüße

Wolfgang

guest2205:

--- Zitat ---Opcode: 0xc5c1 MULS D1,D2:
--- Ende Zitat ---
Scheint in Ordnung zu sein - sah bloß komisch aus weil nach der langen Multiplikation gleich noch der Amigachipsatz auf den Bus zugriff.


--- Zitat ---PEA:
--- Ende Zitat ---
Das ist aus meiner Sicht auch im Augenblick der entscheidene Bug.


--- Zitat ---Interrupts:
--- Ende Zitat ---
Da läuft im Augenblick auf jeden Fall nochwas schief. Manchmal wird der Vector auch von $0000300 geholt.
Aber richte erstmal PEA.

Viele Grüße
TobiFlex

wfoerster:
Ich habe PEA untersucht und kann nichts entdecken. Es ist nun aber gemäß OPCODE 0x486f so, dass der Stack an der Operation beteiligt ist. Also könnte auch der Stack aus irgendeinem Grund verrutscht sein. Ich habe noch einen Bug in der CHK Operation gefunden (ich habe die auch immer LONG behandelt). Vielleicht hilft das weiter. Ich schicke demnächst ein Update durch. Falls es Deiner Meinung nach CHK nicht sein kann (weil zum Beispiel gar nicht verwendet), müsste ich noch etwas aus der Vorgeschichte zu PEA wissen. Ein Hexdump wäre geschickt, ein Disassembly perfekt.
Kannst Du den Stack sehen? Das würde natürlich auch weiterhelfen.

Viele Grüße

Wolfgang

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete