Optimierung: Löst gcc oder AVR struct- Adressen auf

[GerdS (Gast)]

Hi zusammen,
kurze Frage:

Wenn ich im Programm mit statischen structs arbeite und ich auf die 
struct- Elemente ohne Pointer zugreifen will, wer löst die Adressen der 
Elemente auf?

Kann das der avr-gcc  schon beim Compilieren oder muss der uC dies zur 
Laufzeit berechnen ?

Gruß und Dank
Gerd

[Jörg W. (dl8dtl) (Moderator)]

Der Compiler versucht zu entscheiden, was günstiger ist im jeweiligen
Fall.  Wenn du in einer Funktion nur einmal auf ein solches Element
zugreifst, wird er ganz sicher direkt die Adresse benutzen.  Greifst
du kreuz und quer auf die struct members zu, hat es mehr Sinn, die
Basisadresse in ein Zeigerregister zu laden und dann nur noch mit den
Offsets zu arbeiten.

Offset-indirekte Adressierung beherrscht jeder ordentliche Prozessor,
das konnte sogar schon der Z80 (dort war's aber teuer, da es in den
i8080 opcode space nachträglich reingeflanscht war und dadurch mit
Präfixbytes arbeiten musste).

[(prx) A. K. (prx)]

Jörg Wunsch schrieb:

> Offset-indirekte Adressierung beherrscht jeder ordentliche Prozessor,

Schon mal mit einem Intel IA64 (Itanium) programmiert? Der kann das 
nicht, nur indirekt (vgl. ehedem AMD 29000). Aber man kann beim einem 
vorigen Lade/Speicher-Befehl nebenbei was auf den verwendeten Pointer 
anschliessend draufaddieren um für den nächsten Zugriff gewappnet zu 
sein. Operation-Scheduling zum anfassen.

Die 8051er können auch nur direkt und notfalls indirekt adressieren, 
nicht aber mit Offset - weiss nicht, ob du die als "ordentlich" ansiehst 
(die 14-Bit PICs lasse ich deshalb mal weg ;-).

Eine Daumenregel, was effizienter ist, gibt es also nicht. 8-Bitter 
kommen meist ganz gut mit direkter Adressierung zurecht, auch wenn das 
nicht immer der kürzeste Weg sein muss (AVR), grössere Dinger bevorzugen 
die Adressierung über einen Pointer.

[Jörg W. (dl8dtl) (Moderator)]

A. K. schrieb:
> Schon mal mit einem Intel IA64 (Itanium) programmiert?

Nö, ist mir erspart geblieben.

> Der kann das
> nicht, nur indirekt (vgl. ehedem AMD 29000).

Nun, dann fällt er halt nicht in meine Definition von "ordentlichem
Prozessor". :-)