HI Ich bin schon seit längerem am Schreiben von Assemblercode und ärgere mich immer wieder, dass man bei Bedingungen immer mit bedingten Sprüngen immer so um die Ecke denken muss. Gibt es nicht irgendwie einen Befehl oder eine Möglichkeit,wie man bedingte calls regeln könnte?
@ Michael D. (michael1988) >Ich bin schon seit längerem am Schreiben von Assemblercode Mit welchem Prozessor? >und ärgere >mich immer wieder, dass man bei Bedingungen immer mit bedingten Sprüngen >immer so um die Ecke denken muss. ??? Wieso das? Man kann schön auf Gleichheit, Ungleicheit, grösser/kleiner vergleichen und springen. > Gibt es nicht irgendwie einen Befehl >oder eine Möglichkeit,wie man bedingte calls regeln könnte? Das sind aber Funktionsaufrufe, keine Sprünge! MFG Falk
Gast
#697003
Hallo Michael, ich muss ja zugeben, das ich mir da auch manchmal den Intellekt verbiege. Das hat meistens damit zu tun, das ich mir über die eigentliche Fallunterscheidung nicht klar bin und das erst beim schreiben "erarbeite". Was sind denn Deine konkreten Probleme? Hilfreich könnte eine Tabelle in dem Atmel-Dokument zum Befehlssatz sein. Dort gibt es eine Tabelle, in derm an sich nach der zu testenden Bedingung den Befehl heraussuchen kann. Gruß Oops
Michael D. wrote: > HI > Ich bin schon seit längerem am Schreiben von Assemblercode und ärgere > mich immer wieder, dass man bei Bedingungen immer mit bedingten Sprüngen > immer so um die Ecke denken muss. Gibt es nicht irgendwie einen Befehl > oder eine Möglichkeit,wie man bedingte calls regeln könnte?
1 | |
2 | |
3 | |
Peter
Oops wrote: > Das hat meistens damit zu tun, das ich mir über die eigentliche > Fallunterscheidung nicht klar bin und das erst beim schreiben > "erarbeite". Endlich mal einer, der es zugibt. Das Problem ist nämlich, daß man sich vorher keinen Ablaufplan gemacht hat und das Programm einfach wachsen läßt. Die Zeit die man vorher beim Nichterarbeiten des Plans gespart hat, legt man dann bei Schreiben (und Debuggen) des Programms mindestens 10-fach wieder zu. Peter
Gast
#697048
@Peter: >>Das Problem ist nämlich, daß man sich vorher keinen Ablaufplan gemacht >>hat und das Programm einfach wachsen läßt. Das Problem ist noch gar nicht klar. Michael D. hat noch nicht geschrieben was er für ein konkretes Problem hat und was er verbessern möchte. Gruss Oops.
@ Oops (Gast) >Das Problem ist noch gar nicht klar. Michael D. hat noch nicht >geschrieben was er für ein konkretes Problem hat und was er verbessern >möchte. Also die Standardlösung. 42 MfG Falk
Oops wrote: > @Peter: > > >>>Das Problem ist nämlich, daß man sich vorher keinen Ablaufplan gemacht >>>hat und das Programm einfach wachsen läßt. > > Das Problem ist noch gar nicht klar. Na ja. Mann muss kein Hellseher sein um die obige Behauptung aufstellen zu können :-) > Michael D. hat noch nicht > geschrieben was er für ein konkretes Problem hat und was er verbessern > möchte. Sein konkretes Problem ist, dass es keinen 'call if zero', 'call if carry', etc... gibt, und er daher immer die Bedingung umdrehen muss um mit einem bedingtem Sprung rund um den call herumzuspringen. Mit Assembler Makros müsste sich doch da was machen lassen. PeDa!!!
@ Karl heinz Buchegger (kbuchegg) >Sein konkretes Problem ist, dass es keinen 'call if zero', >'call if carry', etc... gibt, Stimmt nicht. Beim Picoblaze gibts sowas, recht praktisch. http://www.xilinx.com/bvdocs/appnotes/xapp213.pdf Seite 8 MFG Falk
Gast
#697079
@ Falk Brunner >>Also die Standardlösung. >>42 :-) Gruss Oops.
Gast
#697082
Hallo, auch der ARM-Prozessor kann bedingte Unterprogrammaufrufe. Fast alle Befehle haben dort 4 Bits für die bedingte Ausführung eingebaut, auch der BL-Befehl, der dem CALL entspricht. Gruß, Martin Cibulski
Der Z80 hatte sowas auch, aber ich glaube mich zu erinnern, dass man es am Ende doch eher selten benutzt hat. Meist muss man außer dem eigentlichen CALL doch noch irgendwelche Dinge davor oder danach erledigen, da führt dann um den Sprung kein Weg herum.
Kann man wunderbar mit Makros regeln. Wie hängt allerdings vom Assembler ab, notfalls kann man auch den cpp (c präprozessor) drauf loslassen. Damit kann man dann automatisch die entsprechenden Labels erzeugen lassen.
@ I_ H. (i_h) >Kann man wunderbar mit Makros regeln. Na dann zeig das mal für den AVR und seinen Assembler (AVR-Studio). MfG Falk
Gast
#697181
>>Na dann zeig das mal für den AVR und seinen Assembler (AVR-Studio). Vielleicht so ähnlich wie: MACRO CALLNE %1 .byte XXX CALL %1 ENDMAC (ich habe AVR-Studio nicht hier, kann die Syntax daher nicht prüfen) CALLNE soll das Programm aufrufen, wenn NOT EQUAL erfüllt ist. Für XXX müsste man den Opcode für einen BEQ-Befehl einsetzen, der genau einen Befehl überspringt. Gruß, Martin Cibulski
1 | |
2 | |
3 | |
4 | |
Jörg Wunsch wrote: > Der Z80 hatte sowas auch, aber ich glaube mich zu erinnern, dass man > es am Ende doch eher selten benutzt hat. Meist muss man außer dem > eigentlichen CALL doch noch irgendwelche Dinge davor oder danach > erledigen, da führt dann um den Sprung kein Weg herum. Ich hab auch mit dem Z80 (U880) angefangen. Die bedingten Calls fand ich ganz lustig, aber in der Praxis hat man sie eigentlich nie benutzt (aus den von Dir genannten Gründen). Daher habe ich sie dann später beim 8051 überhaupt nicht vermißt. Peter
>Na dann zeig das mal für den AVR und seinen Assembler
Beim GNU-Assembler würde sowas gehen:
1 | |
2 | |
3 | |
4 | |
5 | |
Der Atmel-Assembler ist ja sowieso eher ein mageres Teil.
Wie gesagt, hängt stark vom Assembler und dessen Makrofähigkeiten ab. Das Konzept ist aber immer das selbe, nimm eine Makrovariable die du bei jeder Instanziierung vom Makro hochzählst, und dann erzeugst du einfach 'n Label abc_[nummer] und springst dahin. Oder die Leute, die des Assembler geschrieben haben, haben mitgedacht und nehmen dir die Nummerierung von Makrolabels ab. Findest du bei OpenSource Sachen zB. oft, weil die Leute üblicherweise selber damit arbeiten ;). Dem GPASM hab ich irgendwann mal If Blöcke, While Schleifen, Variablentypen und so'n Zeugs beigebracht. Aber das ist dann nicht mehr so ganz trivial.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.