Calling Convention ARMGCC

#4734844
Lesenswert?

Hallo zusammen

Der folgende Code bietet sich eigentlich für das ABI der ARM-Architektur 
an:
1
while(...)
2
  x = func_ptr[i++](x);

Nach diesem Dokument http://caxapa.ru/thumbs/656023/IHI0042F_aapcs.pdf
sind R0-R3 auch sowohl Argument- als auch Resultregister. Daher müsste 
der Compiler nur einmal die Argumentregister befüllen und danach die 
Finger davon lassen. Allerdings bekomme ich vom Compiler andere 
Ergebnisse:

int => ok
double => ok
struct{int a;} => ok
struct{double a;} => Übergabe r2/r3; Ergebnis über Stack
struct{int a, b;} => Übergabe r1/r2; Ergebnis über Stack, nur 
komplizierter

Kompiliert wurde mit:
1
arm-none-eabi-g++.exe -S -O3 -mcpu=cortex-m4 test.cpp -mthumb -mabi=aapcs

Vielleicht kennt sich hier jemand damit aus und weiß, wo dieses 
Verhalten dokumentiert ist.
Angehängte Dateien:
#4735196
Lesenswert?

Sam .. schrieb:
> struct{int a;} => ok

Die struct ist klein genug, um in r0 zu passen und wird daher darin 
zurückgegeben.

> struct{double a;} => Übergabe r2/r3; Ergebnis über Stack

Die struct passt nicht mehr in die 4 Byte eines Registers und daher muss 
der Rückgabewert über den Stack laufen. Dazu wird in r0 die Adresse 
übergeben, an der das Ergebnis gespeichert werden soll. Der beim Aufruf 
übergebene double landet in r2/r3, weil doubles nur in den 
Registerpaaren r0/r1 oder r2/r3 übergeben werden dürfen, r1 blebt 
unbenutzt.

> struct{int a, b;} => Übergabe r1/r2; Ergebnis über Stack, nur
> komplizierter

Gleiches Prinzip wie vorher, aber da a und b nur 32-Bit-Werte sind 
können sie in r1 und r2 übergeben werden.

> Vielleicht kennt sich hier jemand damit aus und weiß, wo dieses
> Verhalten dokumentiert ist.

ARM IHI 0042F, "Procedure Call Standard for the ARM® Architecture", u.a. 
Abschnitte 5.4 (Result Return) und 5.5 (Parameter Passing)
#4735283
Lesenswert?

Ingo K. schrieb:
> ARM IHI 0042F, "Procedure Call Standard for the ARM® Architecture", u.a.
> Abschnitte 5.4 (Result Return) und 5.5 (Parameter Passing)

Ah, jetzt sehe ich es auch. Den entscheidenen Abschnitt habe ich wohl 
überlesen.
1
A Composite Type larger than 4 bytes, or whose size cannot be determined statically by both caller and 
2
callee, is stored in memory at an address passed as an extra argument when the function was called 
3
(§5.5, 
4
rule A.4)
5
.

D.h. es gibt wohl nur die Möglichkeit, einen "128
-bit containerized vector" als Rückgabewert für das gewünschte Verhalten 
zu nehmen. Darunter scheinen wohl nur die SIMD-Datentypen zu fallen, 
oder kann man da irgendwie tricksen?

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