MPASM und XC8 Assembler erzeugen nicht den gleichen Code

[Mike (Gast)]

Seit einiger Zeit wurde der MPASM durch den XC8 Assembler ersetzt. 
Letzterer wird auch von Microchip zur Verwendung empfohlen. 
Merkwürdigerweise erzeugen sie aus dem gleichen Assemblerprogramm nicht 
den gleichen Code:

Der Befehl CLRW wird vom MPASMmit 0x0100 übersetzt, der XC8 macht daraus 
0x0103. Letzteres ist zwar im Prinzip auch richtig, denn die untersten 7 
bit sind "Dont care", trotzdem empfiehlt Microchip, diese Bits aus 
Kompatibilitätsgründen auf 0 zu setzen:
"The assembler will generate code with x = 0. It is the recommended form 
of use for compatibility with all Microchip software tools"

Warum verletzt Microchip beim XC8 seine eigenen Kompatibiltätsregeln?

[APW (Gast)]

Welcher Zielprozessor ist denn ausgewählt?

[Mike (Gast)]

APW schrieb:
> Welcher Zielprozessor ist denn ausgewählt?
PIC16LF1519

andere PIC16 geben aber das gleiche Ergebnis

[APW (Gast)]

Es gibt kleinere PIC (PIC12C67X), da ist CLRW tatsächlich 0x0103, 
deshalb dachte ich, dass event. ein falscher Zielprozessor gewählt 
wurde.

[Mike (Gast)]

Könnte es sein, dass 0x0100 bei einigen PIC-Varianten einen internen 
Fehler auslöst?
CLRW ist ja vom Binärcode identisch mit CLRF f,w und vermutlich in der 
Hardware auch so implementiert. Da f weder gelesen noch geschrieben 
wird, ist die Registeradresse eigentlich egal. Vielleicht prüft die 
PIC16-Hardware aber doch auf Gültigkeit. Ist f=0, bedeutet das indirekte 
Adressierung, die schiefgeht, wenn im FSR eine ungültige Adresse steht. 
f=3 ist das Status-Register, das es in allen PICs gibt, so dass die 
Addresse immer gültig ist.

[APW (Gast)]

Mike schrieb:
> Könnte es sein, dass 0x0100 bei einigen PIC-Varianten einen internen
> Fehler auslöst?
Bei welchen z.B.?

> CLRW ist ja vom Binärcode identisch mit CLRF f,w und vermutlich in der
> Hardware auch so implementiert.
Erklär mir das mal ausführlicher, mit Verweis auf die Datenblatt-Stelle 
(denn beim PIC16LF1519 gibts kein CLRF f,w (und auch nicht bei den 
PIC12))

Ich beziehe mich auf das PIC16LF1516/7/8/9 -Datenblatt DS40001452F.pdf.

[Mike (Gast)]

Nun, ob ich CLRF f,w schreibe oder CLRW ist dem Controller egal. Der 
versteht nur Binärcode. Und der lautet bei den PIC16: 
[http://ww1.microchip.com/downloads/en/devicedoc/31029a.pdf]

00 0001 1fff ffff für CLRF f
00 0001 0xxx xxxx für CLRW


Die beiden Befehle unterscheiden sich also nur in einem Bit. Dieses Bit 
steht bei den Registeroperationen normalerweise für das Ziel d. Meine 
Vermutung ist daher, dass es sich bei CLRF und CLRW um ein und den 
selben Befehl CLRF f,d handelt, einmal mit d=1 (Ziel ist Register f) und 
einmal d=1 (Ziel ist W). Im letzten Fall wird f nicht angesprochen und 
kann im Prinzip beliebig gewählt werden.
Mein Verdacht ist eben, dass für CLRW keine besondere Dekodierlogik 
implementiert ist.

PS: Im 16LF1519 Datasheet steht 00 0001 0000 00xx mit dem ausführlichen 
Hinweis:
"x: don't care location. The assembler will generate code with x=0." Das 
tut er aber gerade nicht!

[A.P. W. (apw)]

OK, ich verstehe jetzt einigermaßen, was du meinst.
Vielleicht wollte man auf Assemblerebene für mehr Klarheit sorgen, indem 
man den theoretisch möglichen Maschinenbefehl CLRF f,w aufgesplittet hat 
in
CLRF f und CLRW.

Und was den Assembleroutput für CLRW angeht: Wollte man den auf billige 
Art kompatibel machen für Zielprozessoren, die ausschließlich 0x0103 als 
Opcode verlangen?