010111 000i 1111 --------- sssssssss JMP S
010111 0001 1111 --------- --------- RET
Und wieder stößt sich alles am ominösen i.
Gruß PIC18F2550
drone265/278 Barbarus hic ergo sum, quia non intellegor ulli. Ein Barbar bin ich hier, da ich von keinem verstanden werde. ʎɐqǝ ıǝq ɹnʇɐʇsɐʇ ǝuıǝ ɹǝpǝıʍ ǝıu ǝɟnɐʞ ɥɔı ´uuɐɯ ɥo
Jo, genau so ist es. Da die Cog ja keinen Stack hat, modifiziert Call den entsprechenden Jmp, also die Rücksprungadresse. Ist quasi wie ein verteilter Stack.
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
Und genau deshalb verstehe ich nicht den Sinn des i Bits.
Gruß PIC18F2550
drone265/278 Barbarus hic ergo sum, quia non intellegor ulli. Ein Barbar bin ich hier, da ich von keinem verstanden werde. ʎɐqǝ ıǝq ɹnʇɐʇsɐʇ ǝuıǝ ɹǝpǝıʍ ǝıu ǝɟnɐʞ ɥɔı ´uuɐɯ ɥo
Naja, das i-Bit (immediate) definiert den Verarbeitungsmodus für das Sourcefeld im Befehlscode. Abhängig von diesem Bit wird der 9 Bit Wert im S-Feld als direkter, eingebetteter Parameter (immediate), oder als Adresse zu dem Parameter in einem Cog-Register interpretiert.
RET ist dabei quasi ein JMP mit gesetztem i-Bit und
CALL ist ein JMPRET mit gesetztem i-Bit.
Beide Befehle (Call/Ret) sind Assembler Makros, welche die Bezeichner in die entsprechenden Zielbefehle (JMP/JMPRET) umsetzen. Im Prinzip kannst du es überprüfen, indem du statt Call und Ret manuell einfach JMPRET und Ret setzt - funktioniert analog den Makros.
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
Der Unterschied ist nur in den d und s Elementen zu finden.
(nicht zur Laufzeit)
Beim RET sind d und s = 0,
Beim JMP ist nur d = 0
i = 1 ===> JMP nnn
i = 0 ===> JMP(nnn)
Analog des Z80
Fürs erste werd ich daher CALL und RET misachten
Gruß PIC18F2550
drone265/278 Barbarus hic ergo sum, quia non intellegor ulli. Ein Barbar bin ich hier, da ich von keinem verstanden werde. ʎɐqǝ ıǝq ɹnʇɐʇsɐʇ ǝuıǝ ɹǝpǝıʍ ǝıu ǝɟnɐʞ ɥɔı ´uuɐɯ ɥo