Hallo Leute, ich habe gerade das Forum durchsucht weil ich nach einer Antwort suche. Es geht darum, was von einem conditional branche überprüft wird. Wird das Ergebnis der Rechenoperation davor überprüft, oder der Status des Zeroflags ? Ich habe folgende Antwort von einem Forummitglied gefunden: Hi, so wie ich dass verstehe. Werten die BRNE und BREQ das Z-Flag aus im Register SREG aus. BRNE setzt den Programmcounter mit der Sprungmarke(durch Assembler eine Adresse) bei Z=0 fort. Bei BREQ erfolgt das bei Z=1. (vgl. Datasheet Atmel Instruction Set) Das Z-Flag wird immer nur dann Z=1, wenn das Ergebnis einer Operation (Vergleich,inc,dec...) gleich 0 ist. So lassen sich die Befehle BRNE, BREQ vielfältig einsetzen in Verbindung mit den vorhergehenden Operationen. Dieser Beitrag wurde von anderen Usern bestätigt, ergibt jedoch für mich keinen Sinn. Es ist doch genau Umgekehrt wie von dem User beschrieben. Hier sein Zitat: Hi, "BRNE setzt den Programmcounter mit der Sprungmarke(durch Assembler eine Adresse) bei Z=0 fort. Bei BREQ erfolgt das bei Z=1." BRNE : Branche if not equal. Wenn das Ergebniss der Rechenoperation davor =0 war, dann wird doch das Z-Flag gesetzt und ist somit Z=1. Also springt BRNE bei Z=1. Wenn ich schonmal ein neuen Thread eröffne dann stelle ich gleich eine zweite Frage :) Was überbrüft BRNE wenn die vorige Rechenoperation ADIW war. Also Addition einer Hexzahl. Sagen wir mal es kam 30 raus. Was bedeutet das für unser Ergebniss ist es true oder false ? Vielen lieben Dank im Voraus. Wünsche allen ein schönes WE.
Luqman K. schrieb: > Was überbrüft BRNE wenn die vorige Rechenoperation ADIW war. Weshalb wird das Z(ero) Flag wohl so heissen? > Das Z-Flag wird immer nur dann Z=1, wenn das Ergebnis einer Operation > (Vergleich,inc,dec...) gleich 0 ist. Ebendies. Meistens. Bei SBC und CPC wirds etwas komplizierter. > Wird das Ergebnis der Rechenoperation davor überprüft, oder der Status > des Zeroflags ? Wie aus der Befehlsbeschreibung von BRxx eindeutig hervorgeht, werden die betreffenden Flags geprüft. Wodurch auch immer die zuletzt gesetzt wurden. Das kann der Befehl direkt vorher sein, aber auch ein früherer.
:
Bearbeitet durch User
Luqman K. schrieb: > [...] > Es geht darum, was von einem conditional branche überprüft wird. > Wird das Ergebnis der Rechenoperation davor überprüft, oder der Status > des Zeroflags ? Ich meine zwar, zu wissen worauf Du hinaus willst. Aber die Frage ist dazu nicht passend gestellt. Es gibt mehrere Arten von bedingten Sprüngen. Sie unterscheiden sich zum einen darin, von welchem Flag ihr Verhalten abhängig ist und darin ob sie nun die Ausführung an einer neuen Stelle weiterführen, wenn das Flag gesetzt ist oder wenn das Flag gelöscht ist. Das ist Dir, soweit ich das erkennen kann, wohl schon klar. Aber die Frage kann daher nicht allgemein auf bedingte Sprünge gestellt und beantwortet werden. Wenn ich Deine Frage mal neu formulieren darf: "Es geht darum, was von einem conditional branch, der vom Zero-Flag abhängt, überprüft wird. Wird das Ergebnis der Rechenoperation davor überprüft, oder der Status des Zeroflags?" Es wird der Status des Z-Flags geprüft. In der Beschreibung der Befehle siehst Du eine Liste, in der beschrieben wird, ob ein bestimmtes Flag überhaupt verändert wird und in welcher Weise das von den Operanden bzw. vom Ergebnis abhängt. Es gibt z.B. Befehle die das Z-Flag nicht beeinflussen. Dann hat das Z-Flag denjenigen Zustand, der von dem letzten Befehl, der das Z-Flag beeinflusst hat, abhängt. > Ich habe folgende Antwort von einem Forummitglied gefunden: > > Hi, > so wie ich dass verstehe. Werten die BRNE und BREQ das Z-Flag aus im > Register SREG aus. BRNE setzt den Programmcounter mit der > Sprungmarke(durch Assembler eine Adresse) bei Z=0 fort. Bei BREQ > erfolgt das bei Z=1. (vgl. Datasheet Atmel Instruction Set) > Das Z-Flag wird immer nur dann Z=1, wenn das Ergebnis einer Operation > (Vergleich,inc,dec...) gleich 0 ist. > So lassen sich die Befehle BRNE, BREQ vielfältig einsetzen in > Verbindung mit den vorhergehenden Operationen. > > > Dieser Beitrag wurde von anderen Usern bestätigt, ergibt jedoch für mich > keinen Sinn. Es ist doch genau Umgekehrt wie von dem User beschrieben. > Hier sein Zitat: > > Hi, > "BRNE setzt den Programmcounter mit der Sprungmarke(durch Assembler eine > Adresse) bei Z=0 fort. Bei BREQ erfolgt das bei Z=1." Dieses Zitat sagt genau das selbe aus, wie das darüber stehende Zitat. Es ist sogar identisch mit einem Teil des Zitats. Wo siehst Du da einen Unterschied? > BRNE : Branche if not equal. > Wenn das Ergebniss der Rechenoperation davor =0 war, dann wird doch das > Z-Flag gesetzt und ist somit Z=1. Also springt BRNE bei Z=1. Diese Schlussfolgerung ist falsch und es ist auch unklar, worauf sie beruht. Erkläre das mal. > Was überbrüft BRNE wenn die vorige Rechenoperation ADIW war. Also > Addition einer Hexzahl. Sagen wir mal es kam 30 raus. Was bedeutet das > für unser Ergebniss ist es true oder false ? BRNE überprüft IMMER das Z-Flag, egal welche Operationen vorher erfolgt sind. Es weiss sozusagen nicht, was die vorherige Operation war. ADIW beeinflusst das Z-Flag. Das Z-Flag wird gesetzt wenn das Ergebnis der Addition Null ist.
Vielen Dank für die schnellen Rückmeldungen. Ich habe vor lauter Bäumen den Wald nicht gesehen. Es macht wesentlich mehr Sinn jetzt. Prima erklärt a.k. und vor allem theor.
Ergänzend kann man noch folgendes hinzufügen: Die Befehle "BREQ" (Branch if equal) und "BRNE" (Branch if not equal) sind nicht in Bezug auf alle Befehle wortwörtlich so zu verstehen, dass sie springen bzw. nicht springen, wenn die Operanden gleich bzw. ungleich sind. Gegenbeispiele lassen sich leicht finden: So wird ein Bitweises "Und" von 0xF0 und 0x0F das Z-Flag setzen (weil das Resultat Null ist. Ein anschliessendes BREQ (das springt, wenn Z gesetzt ist) wird aber nicht deswegen springen, weil die Operanden tatsächlich gleich waren; sie waren es ja nicht. Das kann evtl. am Anfang zu Verwirrungen führen. In der Befehlsbeschreibung von BREQ und BRNE ist deswegen auch beschrieben, dass dieser Befehl nach den Befehlen CP, CPI, SUB, oder SUBI (dazwischen dürfen natürlich nur Befehle stehen, die Z nicht beeinflussen), abhängig davon springt ob die Operanden gleich (BREQ) oder ungleich (BRNE) waren. Davon ob die Operanden gleich oder ungleich waren wird in Bezug auf andere Operationen nichts gesagt (und was in Datenblättern nicht ausdrücklich gesagt wird ist auch nicht vorauszusetzen [auch wenn es manchmal trotzdem zutrifft]). Ein anderes Beispiel ist der erwähnte ADIW-Befehl. Selbst wenn das Ergebnis Null ist, etwa weil zu 0xFE noch 1 dazu addiert wurde, heisst eine Sprung durch BREQ nicht das die Operanden gleich waren. Das kann unter Umständen ein paar Mal zu Verwirrung führen, ehe man sich klar macht, dass die Bezeichnungen BRNE und BREQ sich sinngemäß eben nur auf die Ergebnisse von CP, CPI, SUB, or SUBI anwenden lassen. In allen anderen Fällen muss muss man sich BREQ als BREQZ(Branch if result equal to Zero) bzw. BRNEZ (Branch if result not equal to Zero) denken. Allerdings tue ich das gedanklich nicht so, weil es sich nach den ersten zwei oder drei Fällen in denen man darüber anfängt nachzudenken dann doch irgendwie einprägt, das es auf das Resultat ankommt, auch wenn es nicht irgendwo gespeichert wird (denn z.B. CP führt zwar eine Subtraktion durch, weist aber das Ergebnis keinem Register zu). Ein Vergleich ist demnach lediglich eine Operation bei der die Differenz Null ist, wenn die Operanden gleich sind und unterscheidet sich darin in keiner Weise etwa von dem Bitweisen-Und bei dem auch möglicherweise Null herauskommt.
Ups. Dieser eine Absatz über ADIW muss natürlich so lauten:
Ein anderes Beispiel ist der erwähnte ADIW-Befehl. Selbst wenn das
Ergebnis Null ist, etwa weil zu 0xFFFF noch 1 dazu addiert wurde, heisst
^^^^
eine Sprung durch BREQ nicht das die Operanden gleich waren.
Sorry.
Theor schrieb: > Allerdings tue ich das gedanklich nicht so, weil es sich nach den ersten > zwei oder drei Fällen in denen man darüber anfängt nachzudenken dann > doch irgendwie einprägt, das es auf das Resultat ankommt, auch wenn es > nicht irgendwo gespeichert wird (denn z.B. CP führt zwar eine > Subtraktion durch, weist aber das Ergebnis keinem Register zu). Ein Nein, es kommt eben nicht auf das Resultat an. Es wird einzig und allein Zeroflag geprüft. Zeroflag kann aber auch 10 Befehle vorher gesetzt bzw. zurückgesetzt worden sein. Unter anderem beeinflussen Jump, Bit Set und Reset, Load Befehle etc. den Zeroflag überhaupt nicht. Und es gibt gerade deswegen den Befehl SEZ (Set Zero Flag) und CLZ (Clear Zero Flag).
Ja, die kleinen Hässlichkeiten, man muss manchmal höllisch aufpassen :-) Am besten überlässt man den ganzen Quark einem Compiler, der kann das besser und irrt sich i.a. nicht. Auch eine Falle: R16=0xff inc R16 setzt zwar das zero-flag, aber nicht das carry-flag, wie man erwarten könnte.
H.Joachim S. schrieb: > Auch eine Falle: R16=0xff > inc R16 > setzt zwar das zero-flag, aber nicht das carry-flag, wie man erwarten > könnte. AVR hat keinen ADI oder ADDI Befehl (Add immediate). So artet auch dies zu einer Falle:
1 | ldi r16, 0xFF |
2 | subi r16, -1 |
Aber folgendes:
1 | ldi r16, 0xFF |
2 | ldi r17, 0x01 |
3 | add r16, r17 |
lässt einen nicht in diese Falle tappen.
> Ja, die kleinen Hässlichkeiten, man muss manchmal höllisch aufpassen :-)
Genau.
P.S.
INC und DEC wird meistens bei loop counter oder so benutzt, da kommt
es nicht darauf an.
:
Bearbeitet durch User
Marc V. schrieb: > Theor schrieb: >> Allerdings tue ich das gedanklich nicht so, weil es sich nach den ersten >> zwei oder drei Fällen in denen man darüber anfängt nachzudenken dann >> doch irgendwie einprägt, das es auf das Resultat ankommt, auch wenn es >> nicht irgendwo gespeichert wird (denn z.B. CP führt zwar eine >> Subtraktion durch, weist aber das Ergebnis keinem Register zu). Ein > > Nein, es kommt eben nicht auf das Resultat an. Ich halte Deinen Einwand, mit Verlaub, für irrelevant. Ich will die Möglichkeit einräumen, dass eine Unklarheit, ein Mißverständnis die Ursache ist, aber insofern die nachfolgenden Sätze eine Klarstellung bewirken sollen, muss ich feststellen, dass sie nichts feststellen, was ich nicht auch schon geschrieben habe und sie daher Deinen Einwand nicht präzisieren. Für irrelevant halte ich ihn deswegen, weil sich der Teilsatz "das es auf das Resultat ankommt" als Teil eines Absatzes auf diejenigen Resultate bezieht, für die ich die Frage aufgeworfen habe und diskutiere, ob und in welcher Weise mit der Tatsache umgegangen wird, dass die wörtliche Bedeutung von BREQ und BRNE nicht in jedem Fall auf die Gleichheit bzw. Ungleichheit von Operanden abzielt. Also auf die Resultate gewisser vorhergehender Operationen (nicht wie Du nachfolgend ausführst auf alle Operationen). Aus dem Kontext und insbesondere meiner Aussage: "In der Beschreibung der Befehle siehst Du eine Liste, in der beschrieben wird, ob ein bestimmtes Flag überhaupt verändert wird und in welcher Weise das von den Operanden bzw. vom Ergebnis abhängt. Es gibt z.B. Befehle die das Z-Flag nicht beeinflussen." wird eindeutig klar, dass mir bewusst ist und ich dies dem TO auch mitteilen will, dass nicht alle Operationen das Z-Flag setzen. Daraus lässt sich unschwer schliessen, auch wenn ich das nicht ausdrücklich schreibe, das nicht alle Resultate aller Operationen mit dem setzen bzw. löschen des Z-Flags einhergehen. Der Einwand ist also insofern irrelevant, als die in Rede stehenden Resultate für den Zweck meines Diskurses ohnehin durch meine vorhergehenden Aussagen auf jene beschränkt waren, die durch Operationen erzeugt werden, die das Z-Flag beeinflussen. > Es wird einzig und allein Zeroflag geprüft. Ziemlich genau das habe ich hier: "Es wird der Status des Z-Flags geprüft" und hier: "BRNE überprüft IMMER das Z-Flag, ..." geschrieben. Nicht ganz, aber Deine Formulierung wäre aus meiner Sicht nur dann sinnvoll, wenn es nicht nur offen sondern auch fraglich geblieben wäre, ob nicht auch andere Flags oder auch andere Register geprüft würden könnten. Das aber war weder die Frage des TOs, noch ergab sich aus der Fragestellung, dass dieser Punkt, obwohl nicht ausdrücklich genannt, wichtig sein könnte. Man konnte vielmehr plausibel annehmen, dass der TO davon ausgeht, dass BRNE ausschliesslich das Z-Flag testet und da das so völlig zutreffend ist, ergab sich auch keine Notwendigkeit das ausdrücklich zu erwähnen um etwa ein Fehlverständnis zu korrigieren oder ähnliches. > Zeroflag kann aber auch > 10 Befehle vorher gesetzt bzw. zurückgesetzt worden sein. > Unter anderem beeinflussen Jump, Bit Set und Reset, Load Befehle etc. > den Zeroflag überhaupt nicht. Genau dies (mit der Einschränkung, dass ich es unterlassen habe einzelne Befehle zu nennen) habe ich hier geschrieben: "Es gibt z.B. Befehle die das Z-Flag nicht beeinflussen. Dann hat das Z-Flag denjenigen Zustand, der von dem letzten Befehl, der das Z-Flag beeinflusst hat, abhängt." > Und es gibt gerade deswegen den Befehl SEZ (Set Zero Flag) und > CLZ (Clear Zero Flag). Diesen Absatz von Dir kommentiere ich hier nicht, weil ich nicht erkennen kann, in welcher Weise er, Deinen Einwand: > Nein, es kommt eben nicht auf das Resultat an. oder eine der nachfolgenden Aussagen stützen soll. Insgesamt will ich folgendes sagen: Meine beiden Beiträge hier nahmen jeden Deiner Einwände vorweg und meine Verwendung des Ausdrucks "das es auf das Resultat ankommt" muss meiner Meinung nach in dem Kontext dieser Punkte und insgesamt der beiden Beiträge gelesen werden. Die Alternative wäre, vor jedem Satz, den man schreibt und der von der Sache handelt, hinzuzufügen, dass für das folgende aller vorher gemachten Aussagen (und Meinungen etc.) nach wie vor uneingeschränkt gelten sollen. Das aber sollte, meiner Ansicht nach, unter verständigen und vernünftigen Leuten nicht nötig sein. Es versteht sich meiner Erfahrung nach von selbst, dass hypothetische Annahmen, die nur für einen Teil der nachfolgenden Argumentation gelten sollen, als solche gekennzeichnet, bzw. an einem späteren Punkt im Text ausdrücklich aufgehoben werden. Noch kürzer: In dem Teilsatz "das es auf das Resultat ankommt" meint "Resultat" meiner Meinung nach völlig zweifelsfrei, eindeutig und klar, genau diejenigen Resultate genau und ausschliesslich jener Operationen auf die eine Diskussion über Bedeutung und Anwendung von BRNE und BREQ überhaupt anwendbar ist. Wie siehst Du das? Hälst Du meine in diesem Beitrag genannten Einwände gegen Deinen Beitrag für treffend? Und hälst Du Deinen Einwand immer noch für relevant? Wenn ja, würde mich interessieren, warum.
Ich muss gerade grinsen, denn ich muss Dir ganz offen gestehen, dass ich Dich schon längere Zeit in meinen CSS File filtere und mehr oder weniger zufällig mal wieder was von Dir lese. Um es mal so auszudrücken. Ich kann Deinen Gedankengängen so gut wie nie folgen; was bewirkt, dass ich ihnen eben so wenig etwas nützliches entnehmen kann. Das ist, zugegeben, eine etwas unverblümte Ausdrucksweise und es ist fraglich ob ich erwarten darf, dass Du ihr ebenso offen begegnen kannst. Aber jetzt, wo ich mal auf Dich eingegangen bin, interessiert mich das doch, ob ich ein wenig davon herauskriegen kann, wie Du so tickst. Falls Du willst ... Marc V. schrieb: > H.Joachim S. schrieb: >> Auch eine Falle: R16=0xff >> inc R16 >> setzt zwar das zero-flag, aber nicht das carry-flag, wie man erwarten >> könnte. > > AVR hat keinen ADI oder ADDI Befehl (Add immediate). Das verstehe ich nicht. Es hat ja niemand behauptet, dass der AVR einen ADI oder ADDI Befehl hat. Und wie verhält sich Dein Einwand zu der Tatsache, dass der AVR einen ADIW Befehl hat (die wortweise Addition eines Immediates)? > So artet auch dies zu einer Falle: >
1 | > ldi r16, 0xFF |
2 | > subi r16, -1 |
3 | >
|
Was ist daran die Falle? Geht es noch um das Carry-Flag? > Aber folgendes: >
1 | > ldi r16, 0xFF |
2 | > ldi r17, 0x01 |
3 | > add r16, r17 |
4 | >
|
> lässt einen nicht in diese Falle tappen. > > [...] > P.S. > INC und DEC wird meistens bei loop counter oder so benutzt, da kommt > es nicht darauf an. Das fasse ich genau umgekehrt auf. INC und DEC setzen gerade deswegen, damit man sie in arithmetischen Schleifen verwenden kann, nicht das Carry-Flag. Genau das ist auch bei INC und DEC in der Befehlsbeschreibung ausdrücklich beschrieben.
H.Joachim S. schrieb: > setzt zwar das zero-flag, aber nicht das carry-flag, wie man erwarten > könnte. Wobei das für INC Befehle vieler Architekturen gilt.
Leute........... statt hier seitenlang rumzudiskutieren, erwähnt doch für den armen TO einfach mal die Existenz des AVR ARM Reference Manual von Atmel. Da steht für jeden Befehl exakt beschrieben drin, was er tut, welche Flags er setzt und welche Flags er auswertet. Weder mehr noch weniger ist notwendig, um den AVR ASM zu verstehen und richtig anzuwenden.
Hi Und um die Verwirrung komplett zu machen: Beim 286er unter DOS hieß der entsprechende Befehl JZ (jump zero) bzw JNZ (jump not zero) - was ich als 'klarer' empfinde. (gabs für die anderen Flags auch, z.B. JC für Carry) Selber habe ich mir die Befehlsliste meines aktuellen Opfer ausgedruckt und um so Kleinigkeiten wie benutzbare Register ergänzt. So ist bei mir ersichtlich, daß der ATtiny45 beim Befehl CPI gerne ein Register 16-31 und einen Wert von 0-255 hätte. (Seite 202 im Manual des ATtiny25/45/85 Datasheet) Ansonsten finde ich die aufgelisteten Operationen ganz brauchbar, z.B. BREQ: if (Z=1) then PC=PC+k+1 sagt aus, daß bei gesetztem Z-Flag der PC um k erhöht wird (bei negativem k erniedrigt) (bei mir steht noch, daß k -64 bis 63 betragen darf, wird aber vom Studio angemeckert, wenn die Sprungreichweite nicht passt) MfG
Patrick J. schrieb: > (gabs für die anderen Flags auch, z.B. JC für Carry) BRCC/BRCS gibts bei AVR auch. Aber Obacht! Bei vielen Architekturen entspricht ein Sprung auf "unsigned lower" nach einem Compare einem gesetzten Carry, bei manchen aber einem gelöschten Carry. Drum fährt man mit BRLO/JLO/BLO besser als mit BRCS(AVR), JC(x86), BCC(ARM).
:
Bearbeitet durch User
Patrick J. schrieb: > Beim 286er unter DOS hieß der entsprechende Befehl JZ (jump zero) bzw > JNZ (jump not zero) Beim 8051 ebenso. Oder JC bzw. JNC (Carry) > - was ich als 'klarer' empfinde. dito. Gruß Jobst
Gilt diese Vorliebe für Jx/JNx auch für die JP/JNP Befehle von x86?
Hi P? Sagt mir akut Nix :/ Und Vorliebe ist wohl falsch. Ich habe kein Problem damit, BREQ einzugeben, wenn ich auf das Zero-Flag prüfen will. 'Sprung wenn gleich' passt ja sogar auch, wenn man sich vor Augen hält, daß bei einem Vergleich (CP) beide Werte voneinander abgezogen werden und wenn das Ergebnis 0 ist (das Zero-Flag gesetzt wurde), sind die beiden Werte gleich. Beim Quelltext lesen muß man halt mitdenken, ob hier auf Gleichheit oder auf Flag getestet wird. Hab auch schon gesehen, daß man sich 'JZ' als Makro erstellt und im Makro dann auch gleich prüft, ob der Sprung möglich ist (Entfernung <64) und wenn nein, per negierter Abfrage über einen rjmp drüber springt. Als Erklärung ein Makro von
1 | ; Makros für AVR-Assemblerprogramme |
2 | ; Dr. Michael Schramm Softwareentwicklung |
3 | ; www.schramm-software.de |
4 | ..... weitere Macros ... |
5 | .macro next_up ;(reg, endwert, label) |
6 | inc @0 |
7 | cpi @0,@1 |
8 | .if pc-@2 < 64 ;(original .if pc-@1 < 64) |
9 | brne @2 |
10 | .else |
11 | breq pc+2 |
12 | rjmp @2 |
13 | .endif |
14 | .endmacro |
15 | ..... weitere Macros ... |
Makro ist das Pendant zum 'NEXT' einer For-Next-Schleife, Ab der Zeile *.if pc-02 < 64* wird es interessant. Dort wird, wenn das Sprungziel erreichbar ist, direkt auf Ungleichheit geprüft. Ist das Sprungziel (das FOR dieser Schleife) aber weiter als 64 Wörter entfernt, wird auf Gleichheit geprüft und wenn Gleich, dann der Sprung zum FOR übersprungen. MfG
Jobst M. schrieb: > Beim 8051 ebenso. > Oder JC bzw. JNC (Carry) Wobei der Vergleich mit dem 8051 hier fehl am Platz ist: dort wird über den Sprung entschieden, wenn der ACCU gleich oder ungleich Null ist. Das Z-Flag hat keinen Einfluss! Das Z-Flag kann dort aber auch als Bedingung verwendet werden - über den JB... und JNB... Befehl.
Patrick J. schrieb: > P? Sagt mir akut Nix :/ Das Parity-Flag. JP springt also, wenn das Flag gesetzt und JNP wenn es nicht gesetzt ist. Spätestens hier werden viele auf die alternativen Mnemonics JPE/JPO ausweichen.
:
Bearbeitet durch User
Route 6. schrieb: > dort wird über > den Sprung entschieden, wenn der ACCU gleich oder ungleich Null ist. Das > Z-Flag hat keinen Einfluss! Was eigentlich keinen Unterschied macht ... Route 6. schrieb: > Das Z-Flag kann dort aber auch als Bedingung verwendet werden - über den > JB... und JNB... Befehl. Nö, der 8051 hat nämlich gar kein Z Flag. Gruß Jobst
Jobst M. schrieb: > Nö, der 8051 hat nämlich gar kein Z Flag. > > Gruß > > Jobst Richtig! Aber die bedingten Sprünge über bitadressierbare "Flags" sind dennoch ein Vorteil.
Route 6. schrieb: > Richtig! > Aber die bedingten Sprünge über bitadressierbare "Flags" sind dennoch > ein Vorteil. ... und dabei kann ein Bit ein Portpin, eine RAMzelle, ein Bit des Akkus oder ein Kontrollregister sein. Ich mag den auch! :-) Gruß Jobst
Thread beobachten
Seitenaufteilung abschaltenBitte 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.