Forum: Compiler & IDEs AVR-gcc mehrere Source-Dateien


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von John L (Gast)


Lesenswert?

Hallo! Ich hab ein C-Projekt, wo ich die UART-Funktionen in eine 
separate Source-Datei (uart.c/uart.h) ausgelagert habe. IDE ist 
Microchip Studio 7.

Das ganze klappt aber nur, wenn ich die meisten Include-Dateien aus der 
main.c nochmals in der uart.c inkludiere. Selbst für die Header-Datei 
mit den Prototypen muss die <inttypes.h> nochmals eingebunden werden, 
damit ein Funktions-Prototyp mit (u)intXY_t-Datentypen wie z.B.
1
void uart_puti(int16_t value);
ohne Error kompiliert.

Da stellt sich mir die Frage, ob das nicht auch den Maschinencode 
aufbläht durch doppelt/dreifach eingebundene Includes?

Weitere Frage: sollte man ISRs mit mehreren "volatile extern"-Variablen 
auch auslagern oder ist das bad practice?

: Verschoben durch Moderator
von Rolf M. (rmagnus)


Lesenswert?

John L schrieb:
> Hallo! Ich hab ein C-Projekt, wo ich die UART-Funktionen in eine
> separate Source-Datei (uart.c/uart.h) ausgelagert habe. IDE ist
> Microchip Studio 7.
>
> Das ganze klappt aber nur, wenn ich die meisten Include-Dateien aus der
> main.c nochmals in der uart.c inkludiere. Selbst für die Header-Datei
> mit den Prototypen muss die <inttypes.h> nochmals eingebunden werden,
> damit ein Funktions-Prototyp mit (u)intXY_t-Datentypen wie z.B.void
> uart_puti(int16_t value);
> ohne Error kompiliert.

Ja. Deswegen gibt es ja Header-Dateien.

> Da stellt sich mir die Frage, ob das nicht auch den Maschinencode
> aufbläht durch doppelt/dreifach eingebundene Includes?

Nein. In den Headern stehen ja normalerweise nur Informationen für den 
Compiler, die später im Programm gar nicht drin sind.

> Weitere Frage: sollte man ISRs mit mehreren "volatile extern"-Variablen
> auch auslagern oder ist das bad practice?

Ich würde die ISR in das File stecken, in dem auch die dazugehörige 
Hardware behandelt wird.

von John L (Gast)


Lesenswert?

Danke!
Noch ne Frage, ich habe einige GPIO-Funktionen (Nur Register 
Lese/Schreib-Operationen) zuvor in der main.c mit [i]inline[/i] 
deklariert, um nicht immer Rücksprünge etc. im Programmablauf zu 
erzeugen und effizienteren Code zu haben.
Inwieweit lassen sich diese Funktionen in eine andere Source-Datei 
auslagern, sodass der Funktionsinhalt trotzdem inline in den 
Maschinencode kommt?

von Le X. (lex_91)


Lesenswert?

Wird schwierig.
Mit LTO (Link-time-optimization) könnte das klappen, aber nur wenn die 
zu schreibenden Register/Werte zur Compilezeit bekannt sind.
Dann kann der Compiler/Linker auch Sourcefile-übergreifend optimieren.

Ansätze, GPIO-Zugriffe in Funktionen zu kapseln gibt es viele.
Leider sind sie in der Regel ineffizienter als direkt die Register mit 
Bitmanipulation zu beschreiben.
Aber wie gesagt, in bestimmten Konstellationen ist es möglich dass der 
resultierende Code genauso effizient ist.

Du musst auf jeden Fall den generierten asm-Code überprüfen.

von Oliver S. (oliverso)


Lesenswert?

gcc ignoriert das Keyword inline sowieso, und inlined nur, was er selber 
für richtig hält. Zwingen müsstest du ihn schon per 
__attribute__((always_inline)).

Dein Problem löst -flto.

Damit kennt der Compiler zur Compilezeit alle Sourcen, und kann alles 
inlinen, egal, wo es steht.

Oliver

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Oliver S. schrieb:
> Damit kennt der Compiler zur Compilezeit alle Sourcen, und kann alles
> inlinen, egal, wo es steht.

Nicht ganz.

Zur Compilezeit alle Quellen würde gehen, wenn man sie alle auf einmal 
auf der Kommandozeile angibt und dann -fwhole-program benutzt.

-flto compiliert und linkt erst einmal normal, schickt danach aber noch 
einmal den Compiler über das Ergebnis mit dem Ziel, Dinge zu 
vereinfachen, die sich beim getrennten Compilieren so nicht erkennen 
ließen.

von Oliver S. (oliverso)


Lesenswert?

Jörg W. schrieb:
> -flto compiliert und linkt erst einmal normal,

Jein. Der erste Schritt auf Sourcedateiebene erzeugt GIMPLE-Code, und 
der wird dann final über alle Dateien wirklich compiliert.

Oliver

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.