GCC Übergabe-Parameter zu Assemblerfunktion

[Wolf-Ruediger Juergens (Gast)]

Moin,
Kann mir jemand sagen welche Parameter in welchen (Pseudo-)Registern
der AVR-GCC an eine Assemblerfunktion übergibt.
rP1 scheint nicht mehr zu funktionieren.

Wolf

[Wolf-Ruediger Juergens (Gast)]

Ist erledigt stand in der FAQ vom AVR-GCC
R24 und R25 beim 1. Argument.

Sorry
Wolf

[Wolf-Ruediger Juergens (Gast)]

Heute geht auch plötzlich die Definition von rP0 und rTI0 wieder. Am
Sonntag hat der gas laufend gemeckert rP0 müßte kleiner als 31 sein.
Keine Ahnung warum, ich hatte keine Änderungen gemacht.

Wolf

[mthomas (Gast)]

Sich darauf zu verlassen, dass die Parameter immer bestimmten Registern
zugewiesen werden raecht sich moeglicherweise mal wenn jemand am
Compiler rumbastelt. Nur als Vorschlag: Inline-Assembler verwenden,
damit kann man die Parameter "mit Namen ansprechen". In der
avrlibc-Dokumentation gibt es Information dazu und in der boot.h-Datei
kann man sich auch einiges abschauen.

[Wolf-Ruediger Juergens (Gast)]

Klar, wenn der Compiler das Layout verändert kann man das so nicht
portabel halten. Ich schau mir mal die boot.h an. Allerdings stammen
die ctoasm.inc und die macros.inc die ich verwendet habe ja auch aus
der avrlib.

Grüße
Wolf

[Jörg Wunsch (Gast)]

avrlib != avr-libc

ctoasm.inc und macros.inc sind kein offizieller Bestandteil der
avr-libc.

[Wolf-Ruediger Juergens (Gast)]

Jörg, das wundert mich nun aber denn die Files stammen aus der avr-libc.
Sie werden nicht mit installiert, das ist richtig.
Ich meinte natürlich die avr-libc. Sri für die Ungenauigkeit

Grüße
Wolf

[Jörg Wunsch (Gast)]

Richtig, die werden nicht mitinstalliert.  Früher wurden sie, aber mit
dem Umzug des avr-libc Codes nach savannah.nongnu.org hat sich Marek
Michalkiewicz damals entschlossen, diese Dateien nicht mehr öffentlich
zugänglich zu machen.  Sie sind noch da, weil einiger alter Code sie
intern benutzt.  Ein offizielles Interface in irgendeiner Form stellen
sie aber nicht dar.

Ich könnte mir vorstellen, daß man bestimmte Teile von macros.inc
öffentlich zur Verfügung stellt (vor allem die Dinge wie XJMP/XCALL
etc.), während ich bei ctoasm.inc eher geneigt bin zu sagen, daß diese
Makros den Code sinnlos verschleiern.  (Besonders kraß ist mir das in
die Nase gestiegen bei Debuggen von Teilen der fplib, bei der dann
fplib.inc die Dinge noch weiter undurchschaubar macht.)

Wenn Du selbst in einer Assemblerfunktion Namen für die Parameter
vergeben willst, dann mach sie gleich passend zum C-Prototypen.

/*
 * int
 * foobar(int param1, char param2);
 *
 * Calculates the foobar out of param1 and param2.
 */

#define PARAM1 24
#define PARAM2 22

#define TMPREG1 20

#define ZERO r1

#define RETVAL 24

        .text

        mov     TMPREG1, PARAM1
        mov     TMPREG1 + 1, PARAM1 + 1
        clc
        clr     ZERO
        ror     TMPREG1
        ror     TMPREG1 + 1
        add     TMPREG1, PARAM2
        adc     TMPREG1, ZERO
        movw    RETVAL, TMPREG1
        ret

[Wolf-Ruediger Juergens (Gast)]

Jörg, das Selbstdefinieren von Registern wollte ich eigentlich
vermeiden. Wenn der GCC mal das Übergabeschema ändert muß ich ja wieder
alles ändern. Oder sehe ich das völlig falsch?

Grüße
Wolf

[Jörg Wunsch (Gast)]

Ich denke nicht, daß das in den nächsten Jahren passieren wird. ;-)

Zumindest nicht ohne vorherige ausgiebige Diskussion auf der avr-libc
Entwicklerliste -- dort wäre nämlich dann einiges zu tun.

Das Schema ist im avr-gcc ein einziges Mal bislang geändert worden und
das nur, damit der CPU-Kern der ATmegas mit seinen MOVW-Befehlen
besser ausgenutzt werden kann.

Wie geschrieben: es gibt derzeit keinen besseren Weg.  Es gibt keine
offizielle Headerdatei, in der Du diese Information authoritativ
abgreifen könntest.  ctoasm.inc ist nicht offiziell, und die
Wahrscheinlichkeit, daß diese Datei mal komplett verschwindet, ist
größer als die, daß sich das Registerschema im avr-gcc ändert.

[Wolf-Ruediger Juergens (Gast)]

Ok, Jörg, die Begründung leuchtet mir ein.

Schöne Ostern
Wolf