avr-gcc: den Zugriff auf register variablen optimieren?

Chris schrieb:
> Wie kann ich den Compiler dazu bringen ein 'subi r17' oder 'dec' zu
> generieren?

Gar nicht. Wenn du wirklich was optimieren möchtest, schreib Funktionen 
direkt in ASM und linke sie mit dem übrigen Programm zusammen. Dazu 
gibt's ein Kapitel in der avr-libc Doku inkl. Beispiel.

Welchen Code generiert der Compiler für i-- ?
Wie wirken sich die Optimierungen aus (-O2 oder -Os)?

Chris schrieb:
> Der Compiler scheint register variablen wie Ram zu behandeln:
> laden, dekrementieren, speichern.

In welchem Kontext passiert das? Hast du ein kleines, kompilierbares
Testprogramm, wo man das Problem sehen kann?

Unabhängig davon ist es aber immer etwas gefährlich, C-Variablen feste
Register zuzuweisen und bringt oft mehr Nachteile als Vorteile.

Nicht ganz alte AVRs haben ein GPIOR0 (ATtiny auch GPIOR1,2), welches im 
bitadressierbaren IO-Bereich liegt.


Peter

Wenn du r17 als Registervariable verwendest fliegt dir der Code um die 
Ohren, wenn das Register zur Parametrübergabe verwendet wird. Du kannst 
nicht einfach eine Registervariable verwenden und erwarten daß ein 
Compiler eine dynamische ABI-Anpassung vornimmt.

Und überhaupt: Ist die Registervariable lokal oder global?

Wenn du Code sparen willst, dann:

Fass Variablen, die zueinander gehören, zu Strukturen zusammen und 
greife indirekt darauf zu. Das spart dann pro Zugriff 2 Bytes. Um das 
sinnvoll nutzen zu können, braucht das Programm aber eine gewisse 
Grundstruktur, weil der Code ansonsten nur Pointervariablen am 
Rumschaufeln ist (wegen der mageren Ausstattung der AVRs mit 
Adressregistern).

> So, hat jemand eine Idee wie man dem Compiler helfen kann ?

Indem man ihm nicht sein Haupt-Arbeits-Register klaut. R24 ist eine noch 
viel beschissenere Wahl als r17. Beschränke dich auf die Register 2 bis 
7, oder lass es ganz bleiben.

Chris schrieb:
> Eine Registervariable bringt mir  schon ca 100 Bytes weniger,

Chris schrieb:
> Leider kann der Optimierer -O3 das nicht mehr richten

Wenn es dir um die Codegröße geht, dann benutze -Os, nicht -O3.

BTW:

Oliver schrieb:
> "volatile
> register" kann der gcc schon gar nicht, was u.a. daran liegt, daß das
> gar keinen Sinn ergibt.

Was ergibt daran keinen Sinn?
In Bezug auf Sinn und Zweck von volatile sehe ich da keinen Unterschied 
zur "normalen" Variable.

Chris schrieb:
> @Oliver:
>>> "volatile register" kann der gcc schon gar nicht,
>>Je nun, was wollte ich dir mit meinen Worten wohl sagen?
> Das weiss ich leider nicht was Du mir sagen willst.

volatile bezieht sich auf Objekte in der Speicherklasse static storage, 
und da liegt eine explizite Registervariable nun mal nicht. Die liegt 
eben in der Speicherklasse register, wie angeordnet.

Von daher dient ein "volatile register ...asm" bestenfalls der eigenen 
Verwirrung; stätestens wenn das Register in einer ISR und im 
Normalo-Code verwendet wird, ist eine Bauchlandung vorprogrammiert (etwa 
Poll-Schleife auf so eine Variable).

avr-gcc-3.4.x:

1

warning: volatile register variables don't work as you might wish

avr-gcc-4.5.x:

1

warning: optimization may eliminate reads and/or writes to register variables

2

warning: call-clobbered register used for global register variable

Aber bekanntlich ignoriert man Warnungen am besten... sind ja keine 
Fehler ;-)

Chris schrieb:
> Vielleicht wenn man das Programm mit --complete (oder wie heisst die
> option?) compiliert kann der Compiler das besser optimieren. (hat da
> jemand Erfahrung?)

--combine

Ja, ich benutze es gerne.
Es macht eine sehr effiziente Optimierung und findet fast jedes 
vergessene "volatile".
D.h. wenns danach nicht mehr geht, hat er Dir was wegoptimiert, was 
volatile sein muß.

Es müssen alle C-Files in einem Rutsch compiliert werden. Das geht am 
besten auf der Kommandozeile, *.c expandiert zu allen C-Files im 
aktuellen Verzeichnis.

Hier ein Beispiel (a.bat):

Beitrag "mehrere MC seriell über Datenbus verbinden (1Draht)"


Peter

Hier mal ein kleines Beispiel:

1

register char state asm ("r2");

2

3

void bar (void);

4

5

void foo (void) 

6

{

7

   state = 100;

8

9

   while (1)

10

   {

11

        do 

12

        {

13

            bar();

14

        } while (state);

15

   }

16

}

avr-gcc 4.5 (ditto avr-gcc 3.4) macht daraus:

1

foo:

2

  ldi r24,lo8(100)   ;  20  *reload_inqi  [length = 2]

3

  mov r2,r24

4

.L2:

5

  call bar   ;  8  call_insn/3  [length = 2]

6

  rjmp .L2   ;  21  jump  [length = 1]

Und der Code ist so auch ok.

Chris schrieb:

> Formaljuristisch ist er ok. Aber es soll natürlich die Abfrage auf
> state==0 nicht wegoptimiert werden. Bei einer statischen Variable macht
> man das mit volatile. Und was macht man bei einer Registervariablen ???

Selbst der Klassiker

1

asm volatile ("":"+r"(state));

bleibt wirkungslos... (avr-gcc 3.4, 4.3, 4.5), ebenso ein Verändern von 
state in der Schleife. Was willst da machen?

Verwende andere, robuste Techniken, um die Codegröße zu optimieren. Da 
ist zudem mehr zu holen. Auf den L-Regs sind eh kaum Operationen 
möglich. Wahrscheinlich wird dein Code mit der Registervariablen nur 
deshalb so klein, weil die hälfte in der Tonne landet...

Chris schrieb:

> Compiliere bitte mit  GCC 4.3.4 und natürlich mit -ffixed-r24

Ich hab hier net jede jemals veröffentliche avr-gcc Version ;-)

-ffixed-n änder nix am ABI. Es nimmt die Variable dem Registerallokator, 
wenn er Pseudoregister zuordnen will. Aber -ffixed verhindert nicht das 
Erzeugen von r24 per se, zB durch Funktionsaufrufe wie a = b / c zur 
libgcc.

Bestenfalls Register, die nicht vom ABI belegt werden (wie oben schon 
geschrieben r2-r7) sind für sowas zu gebrauchen.

In einer Anwendung mit avr-gcc 3.4 verwende ich globale 
Registervariablen, weil das 200000 Speicherzugriffe pro Sekunde spart. 
Im Endeffekt bringt's nicht sooo viel, auch nicht für die Codegröße (die 
übrigens kleiner ist als mit jeder 4-er Version, die ich je angetestet 
habe). Aber nun ist's in Code eben mal drinne... An Codegröße macht das 
einen Unterschied von -0.5%, also lächerlich. Aber da ich in der ISR 
jeden Tick brauche, bleibt's eben drin.