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?
Welcher Zielprozessor ist denn ausgewählt?
APW schrieb: > Welcher Zielprozessor ist denn ausgewählt? PIC16LF1519 andere PIC16 geben aber das gleiche Ergebnis
Es gibt kleinere PIC (PIC12C67X), da ist CLRW tatsächlich 0x0103, deshalb dachte ich, dass event. ein falscher Zielprozessor gewählt wurde.
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.
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.
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!
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?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.