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

68K30L, Falcon und Suska-III-T2

<< < (40/149) > >>

guest2205:

--- Zitat ---MOVE A0,A0:
Die CPU schreibt an die Speicherstelle X den Wert X.

--- Ende Zitat ---
Ist das selbe wie NOP. Du meinst sicher MOVE (A0),(A0) und dann liest und schreibt die CPU die Speicherstelle X.


--- Zitat ---MOVE -(A0),A0:
Die CPU schreibt an die Speicherstelle X den Wert (X-2). Oder schreibt sie an die Speicherstelle X-2 den Wert (X-2)?

--- Ende Zitat ---
Die CPU liest die Speicherstelle (X-2) und lädt den Wert nach A0. Dabei wird ein 16Bit Wert vorzeichenbehaftet auf 32 Bit erweitert. Oder die Cpu liest die Speicherstelle X-4 und der 32Bit Wert gelagt nach A0.


--- Zitat ---MOVE A0,-(A0):
Die CPU schreibt an die Speicherstelle X-2 den Wert X. Oder schreibt sie an die Speicherstelle X-2 den Wert X-2?

--- Ende Zitat ---
Die CPU schreibt an die Speicherstelle X-2 den Wert X.
Das ist in deinem Core noch ein Bug.


--- Zitat ---MOVE -(A0),-(A0):
Die CPU schreibt an die Speicherstelle X-2 den Wert (X-2). Oder schreibt sie an die Speicherstelle X-4 den Wert (X-2)?

--- Ende Zitat ---
Weiß ich auch nicht. Krieg ich aber raus.


Aber erstmal sollte es darum gehen alle praxisrelevanten Opcodes zu validieren. Wenn du Move A0,-(A0) gefixt hast kommt mein Validator an der Stelle auch wieder weiter. Und solange benutzte Opcodes Fehler machen wird er was finden. Ob die Opcodes die in der Praxis nie vorkommen genau wie im original 68000 arbeiten sollten wir später untersuchen.

Viele Grüße
TobiFlex

wfoerster:
Hallo Tobias, hallo an Alle,
Vielen Dank für die Infos weiter unten. Der Bug mit Ax, -(Ax) ist wohl dadurch (hoffentlich) Schnee von gestern. Aber ich habe noch was wo ich ich Infos benötige. Die Frage möchte ich natürlich gerne an alle stellen.
Vielleicht ist das ja der Grund für das Fehlverhalten des 68K00 Cores. Es geht um folgende Operationen:

ADDA.W
SUBA.W
CMPA.W

Es wird hier jeweils der Source Operand Sign-extended verwendet. Was passiert aber beispielsweise bei:

CMPA Ax,Ax.

Das würde ja immer schief gehen, sobald im Bereich Bits 31 bis 16 von Ax etwas drin steht was ungleich 0x0000 oder 0xFFFF ist.
Bei ADDA Ax, Ax und SUBA Ax, Ax kommt mir das auch komisch vor, dass der Source Operand Sign-extended wird und der Destination Operand, welcher de facto der selbe ist nicht.

Noch haariger wird es beispielsweise bei CMPA Ax, -(Ax). wird hier ebenfalls Ax als Operand verwendet und Ax-2 als Adresse? Und wie sieht es denn hier mit der Sign-Extension aus? Wird da Ax Sign extended aber die Adresse nicht? Mittlerweile habe ich den Verdacht, dass es an solchen Spezialfällen liegt.

Infos diesbezüglich würden der Sache bestimmt weiterhelfen.

Viele Grüße

Wolfgang

guest2205:
Lass uns Schritt für Schritt vorgehen.
Jetzt ist erstmal folgender BUG dran:
   moveq #$4000,d3
   add.w d3,d3

Jetzt müßte das Vorzeichenbit gesetzt sein - ist es aber nicht. D.h. OPCODE 0xD643 ist fehlerhaft.

Zu den Spezialfällen versuch ich mal was zu finden.
Viele Grüße

TobiFlex
   

wfoerster:
Hallo Tobias,
manchmal bin ich mit Blindheit geschlagen. Ich habe den Bug. Der betrifft alle WORD-weiten Operationen wie ADD, SUB, CMP usw. Ich kann ihn allerdings erst morgen richten, da ich jetzt auf dem Sprung bin. Du bist ein Profi.

Viele Grüße

Wolfgang

tuxie:
Wenn ich von Assembler mehr wissen würde, dann würde ich euch gern helfen.  Naja ich werds wohl auch noch lernen :-)

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete