ARM Cortex & GCC: Worauf achten für "optimalen" Code?

Ralf schrieb:

> ist. Wie ist das beim GCC & ARM? Wenn ich vier 8-Bit-Variablen (char)
> anlege, packt der GCC das automatisch in ein 32-Bit-Wort, oder verwendet
> er vier Mal ein 32-Bit-Wort?

Register: jede einzeln in ein Register. Deklaration lokaler Variablen 
mit weniger als 32 Bits ist ineffizient.

Speicher: in 8 Bits gespeichert.

> Wie kann ich das selber prüfen?

Code ansehen, Adressen von Variablen im Dump suchen oder ggf.ausgeben.

> Was ich bis jetzt in der Hilfe zum GCC rausgefunden habe, ist dass es
> beispielsweise beim Anlegen von structs nicht gepackt wird, d.h. im
> Speicher sind Lücken,

Es wird nicht gepackt, es sei denn das wird ausdrücklich gewünscht. 
Gepackt ist recht ineffizient.

> - Der Keil C51-Compiler bzw. der Linker kann funktionsinterne Variablen
> überlagern, sodass Speicherplatz gespart wird.

51er speichern lokale Daten statisch im RAM, da sie mit einem Stack für 
Daten schlecht umgehen können. ARMs verwenden einen Stack und damit löst 
sich das Problem in Luft auf.

> Ich vermute beim GCC werden die Parameter über einen Stack übergeben,

Nein, Register. Nur wenns zu viele sind, was seltten ist.

Hi zusammen,

Zum Attribut "packed" hätte ich ne Frage

struct{
uint8_t a;
uint8_t b;
uint8_t c;
uint8_t d;
} foo;

ist diese Struct ohne packed auch nur 4 Byte lang oder 16?
Also packt der GCC Variablen die in ein Dword passen zusammen rein und 
fängt erst beim Nächsten an, wenn er eine Var nicht mehr in das erste 
Dword bekommt?

MfG

Tec

Danke dachte ich brauche auch hier für packed.

HI Ralf,

so verstehe ich das auch, der uin32_t passt nicht mehr in das Dword mit 
den 3 uint8_t deshalb beginnt der Compiler ein neues Dword, so erreicht 
er ja 32bit aligned Zugriff, und muss sich die Var nicht aus 2 Blöcken 
zusammen suchen. Darauf wollte ich ja auch hinnaus, weil ich mir da nie 
sicher war.
hab das dann immer in der Form gemacht.

struct{
uint32_t bFlag:1;
uint32_t reseve:31;
} foo __attribute_((_packed_));

so ist der Compiler gezwungen. ich werde das aber noch mal ohne Packed 
probieren.

MfG

Tec

nicht Gast schrieb:

> das is so nicht richtig. Die Register sind immer 32 bit, es macht aber
> keinen unterschied, da man die Registeroperationen auch auf Bytes
> anwenden kann

Das ist so nicht richtig. Erstens kann man nur Lade/Speicheoperationen 
auf 8/16 Bits anwenden, nicht aber ALU Operationen. Zweitens stehen 
(deshalb) bestimmte Compiler-Konventionen im Weg.

1

short reg16(short a, short b)

2

{

3

    short x = a + b;

4

    return x;

5

}

6

int reg32(int a, int b)

7

{

8

    int x = a + b;

9

    return x;

10

}

wird zu

1

reg16:  add  r0, r1, r0

2

        mov  r0, r0, asl #16

3

        mov  r0, r0, asr #16

4

        bx   lr

5

reg32:  add  r0, r1, r0

6

        bx   lr

A. K. schrieb:
> 51er speichern lokale Daten statisch im RAM, da sie mit einem Stack für
> Daten schlecht umgehen können.

Nö, der 8051 kann auch mit dem Stack arbeiten.
Allerdings ist es erheblich effizienter, direkt auf den SRAM 
zuzugreifen. Es muß kein Stackframe angelegt werden und viele Befehle 
können im SRAM gemacht werden (MOV, INC, DEC, DJNZ, ANL, XRL, ..).
Außerdem wird selten ein RTOS verwendet, daher lassen sich lokale 
Variablen überlagern.

A. K. schrieb:
> ARMs verwenden einen Stack und damit löst
> sich das Problem in Luft auf.

Sie können nichts direkt im SRAM ausführen (RISC), daher ist es fast 
egal, ob aus dem SRAM laden oder PUSH/POP.


Peter

Peter Dannegger schrieb:

> Nö, der 8051 kann auch mit dem Stack arbeiten.
> Allerdings ist es erheblich effizienter, direkt auf den SRAM
> zuzugreifen.

Ich habe nichts anderes behauptet, mit schlecht=ineffizient.

Peter Dannegger schrieb:

>> ARMs verwenden einen Stack und damit löst
>> sich das Problem in Luft auf.
>
> Sie können nichts direkt im SRAM ausführen (RISC), daher ist es fast
> egal, ob aus dem SRAM laden oder PUSH/POP.

Es ging hier um die Platzfrage.

Wenn lokale Variablen statisch angelegt werden, dann ist es aus 
Platzgründen sinnvoll, dass der Compiler etwas Aufwand treibt, um solche 
Variablen von sich nicht gegenseitig aufrufenden Funktionen überlagern 
zu können.

Wenn lokale Variablen in Registern bzw. auf einem Stack angelegt werden, 
dann löst sich diese Platzfrage ohne jede Optimierung ganz von allein, 
da diese Überlagerung eine implizite Eigenschaft des Stacks ist.