Hallo, ich programmiere hobbymäßig schon länger in ASM (Tiny/Mega8/Mega16) und bin jetzt bei einem aktuellen Projekt mit dem Mega16 an einem Punbkt angekommen, dass die Sprungreichweite eines RCALL-Befehls zum Aufruf eines Unterprogrammes nicht mehr langt. Ich bekomme folgende Fehlermeldung beim compilieren im AVR-Studio: "Relative branch out of reach" Der Mega16 hat ja dafür extra den CALL-Befehl und mit dem würde das auch funktionieren. Aber woran unterscheiden sich die Befehle rcall/call sonst noch? Kann ich gererell alle rcall`s gegen call`s ersetzen und ich bräuchte nicht mehr auf die Sprungweite achten? Wenn es so wäre, würde es doch nur einen call-Befehl geben, oder? Für Aufklärung wäre ich dankbar :-)
@ Daniel (Gast) >Aber woran unterscheiden sich die Befehle rcall/call sonst noch? Mal ins Befehlsverzeichnis geschaut? rcall, relativer Sprung zum aktuellen Programm coutner, +/-2048 Worte, 2 Takte Ausführungszeit call, absoluter Spung, 64kWorte, 3 Takte Ausführungszeit >Kann >ich gererell alle rcall`s gegen call`s ersetzen und ich bräuchte nicht >mehr auf die Sprungweite achten? Ja. >Wenn es so wäre, würde es doch nur einen call-Befehl geben, oder? Nö. AVRs mit bis zu 8kB Flash haben nur Rcall, weil sie nicht mehr brauchen.
Daniel schrieb: > Aber woran unterscheiden sich die Befehle rcall/call sonst noch? Kann > ich gererell alle rcall`s gegen call`s ersetzen und ich bräuchte nicht > mehr auf die Sprungweite achten? > Wenn es so wäre, würde es doch nur einen call-Befehl geben, oder? > > Für Aufklärung wäre ich dankbar :-) Schau dir in der Hilfe die Beschreibung von RCALL und CALL an. AChte darauf * wie groß (in Bytes/Words) der jeweilige Befehl ist * wieviele Taktzyklen er zur Ausführung braucht.
Danke für eure Antworten! Dass call ein Takt mehr braucht ist mir bewusst. Mir gings nur um die allgemeine Funktion. Also dann benutze ich in Zukunft bei den größeren Controllern generell die call-funktion. Der eine Takt mehr ist für mich nicht entscheidend und ich muss dann nicht mehr auf die Sprungweite achten
@ Daniel (Gast) >allgemeine Funktion. Also dann benutze ich in Zukunft bei den größeren >Controllern generell die call-funktion. Ich würde C oder eine andere Hochspache nutzen ;-)
Ein CALL belegt allerdings auch doppelt so viel Speicher, wie ein RCALL im FLASH. Falk Brunner schrieb: > Ich würde C oder eine andere Hochspache nutzen ;-) Mach doch ... Gruß Jobst
Daniel schrieb: > Dass call ein Takt mehr braucht ist mir bewusst. Dann is ja gut. > Also dann benutze ich in Zukunft bei den größeren > Controllern generell die call-funktion. Das hingegen ist Schwachsinn. Call ist ja nicht nur ein Takt langsamer, sondern auch noch doppelt so groß. Man benutzt deshalb call genau dann (und nur dann), wenn es nicht anders geht. Wenn dir Codegröße und Laufzeit Wurscht sind, benutzt du am Besten gleich eine Hochsprache oder auch C. Dann nimmt dir der Compiler solche Arbeiten ab. Deren Ergebnis ist zwar in aller Regel deutlich schlechter als das eines guten Assemblerprogrammierers, aber andererseits wiederum sicher auch weit besser als das eines schlechten Assemblerprogrammierers, wie du offensichtlich einer bist.
@ c-hater (Gast) >Wenn dir Codegröße und Laufzeit Wurscht sind, benutzt du am Besten >gleich eine Hochsprache oder auch C. Jaja. > Dann nimmt dir der Compiler solche >Arbeiten ab. Das ist sein Job. Und er macht in deutlich besser als jeder Programmierer. >Deren Ergebnis ist zwar in aller Regel deutlich schlechter als das eines >guten Assemblerprogrammierers, Klar, dass DU das sagen musst ;-) >aber andererseits wiederum sicher auch >weit besser als das eines schlechten Assemblerprogrammierers, wie du >offensichtlich einer bist. Jo. Aber egal. 90% der Rechenzeit werden in 10% des Codes verbraucht. Diese muss man finden und optimieren, der Rest muss nur normal und logisch korrekt sein.
Ich würde nichts ändern. Benütze auch weiterhin den rcall- bzw. rjmp-Befehl. Es gibt einen sehr sicheren Meckerer wenn die Entfernung zu groß wird und dann kannst Du ja immer noch den Befehl tauschen. Die Hauptunterschiede sind: 1. Mehr Platz 2. Mehr Zeit Insbesondere bei häufig durchlaufenen Schleifen macht das einiges aus. Auch würde sich der Prozessor freuen, wenn die Unterbrechung nicht so lange dauert.
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.