AVR-ASM: rcall / call

Gast #3215043
Lesenswert?

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 :-)
#3215050
Lesenswert?

@ 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.
#3215051
Lesenswert?

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.
Gast #3215057
Lesenswert?

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
Gast #3215255
Lesenswert?

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.
#3215275
Lesenswert?

@ 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.
Gast #3215318
Lesenswert?

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren