Gast
#4258700
Hallo, könnte mir jemand bitte sagen ob diese Expression richtig oder falsch ist bis.b #X,&YY jz Label es geht hier um bis und jz Gruß jani
Janine schrieb: > Hallo, > > könnte mir jemand bitte sagen ob diese Expression richtig oder falsch > ist > > > bis.b #X,&YY > jz Label > > > es geht hier um bis und jz > > Gruß > jani Das ist eine typische "Schrödinger-Expression". Sie ist sowohl richtig als auch falsch, beides zur gleichen Zeit, solange bis du verrätst um welchen Assembler bzw. welche Zielhardware es geht.
Die beiden Befehle gibt es beim MSP430. Auch die Operandensyntax scheint es zu geben. Ich habe aber sonst keine Ahnung von diesen Controllern, deswegen lege ich mich nicht auf ein eindeutiges Ja oder Nein fest.
Gast
#4258819
Hallo Vielen Dank für Ihre schnelle Antwort. ich habe den befehl in Assembler code von MSP430 gefunden. und gehe ich davon aus, derjeniger, der ihn geschrieben hat, woltte sowas schreiben "bit.b #X,&YY" anstatt "bis.b #X,&YY" Gruß Jani
MSP430 kenn ich zwar nicht persönlich, sondern weiß nur, daß die "PDP11 inspiriert" sind, aber ein kurzer Blick ins Internet verrät: Bit.b Bit Test eines Byte-Werts, AND der beiden Operanden, Status setzen, Ergebnis verwerfen (Op1 & Op2) Bis.b. Bit setzen eines ByteWerts, Op1 |= Op2
Gast
#4258859
Warum meinst du das? Geht das aus den vorhergehenden Operationen hervor? bis (bit set) ist ein gültiger und sinnvoller Opcode. In anderen Systemen auch OR genannt PS: das Z in JZ muss sich auf eine vorhergehende Operation beziehen, da bis die Status Flags nicht berührt.
Gast
#4258890
Hallo. ich meine nicht das bis.b falsch ist aber die Konstellation ist sinnlos. warum soll ich jz aufrufen und eine Sprung durchführen wenn ich keinen Test mit bit.b gemacht habe. bis.b ist in den fall unabhängig von die Status Bit „ Z“ im Register Gruß Jani
Janine schrieb: > Hallo. > ich meine nicht das bis.b falsch ist aber die Konstellation ist sinnlos. > warum soll ich jz aufrufen und eine Sprung durchführen wenn ich keinen > Test mit bit.b gemacht habe. > bis.b ist in den fall unabhängig von die Status Bit „ Z“ im Register Ich geb dir grundsätzlich recht. Jedoch kommt es auch vor, dass ein Status Bit "verschleppt" wird. D.h. der Befehl, auf dessen Ergebnis der JZ aus ist, befindet sich nicht unmittelbar davor sondern ein paar Zeilen davor. Wenn alle dazwischen liegenden Befehle dieses Status Bit in Ruhe lassen, dann reagiert der JZ auf ein Ergebnis das ein paar Befehle zuvor eingetreten ist.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
d.h. es reicht nicht, einfach nur 2 aufeinanderfolgende Befehle zu betrachten. Die Verwicklungen können komplexer sein. In letzter Konsequenz bleibt einem nichts anderes übrig als die implementierte Logik mit der vorgesehenen Logik (oder dem was man dafür hält) zu vergleichen und zu entscheiden, inwieweit das übereinstimmt bzw. ob da eventuell tatsächlich ein Fehler vorliegt. Es kann durchaus vom Programmierer gewollt sein, dass er den JZ vom Befehl 1 abhänigig macht. Es kann aber auch tatsächlich ein Fehler sein und der BIS müsste ein BIT sein. Die zu implementierende Logik im Vergleich mit der implementierten Logik kann diese Fragestellung beantworten. Mit formalen Kriterien, wie zb vor einem Conditional Jump muss immer ein Vergleich stehen, kommst du da nicht weiter. Dem Prozessor ist es ja wurscht welcher Befehl an welcher Stelle das Zero Bit gesetzt oder nicht gesetzt hat. Beim JZ wird einfach nur gefragt, ob es gesetzt ist. Wer das gemacht hat, interessiert nicht mehr.
Janine schrieb: > warum soll ich jz aufrufen und eine Sprung durchführen Weil sich (wie erwähnt) das jz evtl. auf einen vorhergehenden Vergleich oder eine Rechenoperation bezieht. Das kann jetzt so keiner wissen. Kann ja sein, dass derjenige vor dem Sprung hier nur ein Debug-Flag für den Logicanalyzer setzt. So wie sie dastehen, sind die beiden Assemblerzeilen nicht voneinander abhängig. EDIT: Hoppla, war ich soooooo langsam?
Gast
#4258946
Hallo Vielen Dank Lothar Miller, Karl Heinz und die anderen auch. es klingt total Logisch. ihr seid Schätze Gruß Jani
[sidekick] Wie war das noch mal: jeder Assemblerbefehl sagt klar aus, was er macht, oder? ;-)) [/sidekick]
Gast
#4259080
Carl D. schrieb: > [sidekick] > Wie war das noch mal: jeder Assemblerbefehl sagt klar aus, was er macht, > oder? ;-)) > [/sidekick] Stimmt doch auch. Hat jemand was anderes behauptet? Ich sehe hier keine gegensätzliche Aussage!
Gast
#4259108
Also nur die zwei Befehle lassen jetzt nicht erkennen was da wirklich
passiert.
Grundsätzlich solche Konstellationen benutze ich häufig beim
Programmieren um einen Entscheidungspfad im Programm zu sparen wenn ein
Zustand abgefragt wird und darauf hin ein Bit auf 0 oder 1 gesetzt wird.
Also in "Pseudo-Assembler":
cmp n,x ; Vergleich durchführen
bitset xxx,k ; davon ausgehen, dass das Ergebnis 1 sein könnte
jnz next ; es ist 1, also springen
bitreset xxx,k ; es ist 0, also wieder zurück setzen
next:
Gegenüber der lehrbuchmäßigen "sauberen" Variante:
cmp n,x ; Vergleich durchführen
jz setzero ; springen wenn null
bitset xxx,k ; setzen
jmp done ; dieser Sprung wird mit der anderen Variante
gespart
setzero:
bitreset xxx,k
done:
Damit spart man Speicherplatz für eine Sprunginstruktion, braucht aber
ggf. einen Tick mehr Ausführungszeit.
Guido Körber schrieb: > Damit spart man Speicherplatz für eine Sprunginstruktion, braucht aber > ggf. einen Tick mehr Ausführungszeit. Lass das mal bloss nicht Moby hören. Der kennt sich dann überhaupt nicht mehr aus, welche der beiden Varianten denn dann die 'optimale' ist.
Karl H. schrieb: > Lass das mal bloss nicht Moby hören. Der kennt sich dann überhaupt nicht > mehr aus, welche der beiden Varianten denn dann die 'optimale' ist. Kein Problem: Die optimale Variante ist seine :-)