Title: arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: dl8mby on 28. November 2016, 11:58:06
Hallo Forum,
ich habe etwas mit den Switches des gcc Compilers gespielt
und dabei eine Liste erstellt für die einzelnen Objektfilegrößen
bei unterschiedlichen Optimierungsstufen.
Compiliert wurde mit einem arm-none-eabi-gcc in Version 5.4.1
gcc version 5.4.1 20160609 (release) [ARM/embedded-5-branch revision 237715] (openSUSE 5.4.0_20160622-3.20)
Möglicherweise kann die Tabelle pdf/xls den Experten von Euch
weiter helfen, falls nicht, war es eine kleine bash Skript-Übung.
Falls Interesse besteht, kann ich auch die verschiedenen mchf.bin
Files zum spielen hochladen.
vy73
Markus
DL8MBY
|
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: dl8mby on 28. November 2016, 12:00:38
Nachtrag,
Tabelle als xls Format.
Bitte Suffix .txt entfernen.
Musste die Forum-SW überlisten.
Markus |
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: dl8mby on 28. November 2016, 12:10:41
Tschuldigung,
musste das Pdf nochmals erzeugen, da die Blatt-
einteilung für die Tabelle ungünstig war.
Ich hoffe so kann man jetzt die Tabelle besser deuten.
Markus
DL8MBY
|
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: DF8OE on 28. November 2016, 12:11:11
Die unterschiedlichen Optimierungseinstellungen erzeugen selbstverständlich alle unterschiedliche Binaries. Je nachdem, was für Optimierungen durchgeführt werden, ist das Binary mal größer, mal kleiner, mal läuft es schneller, mal langsamer.
Wir haben den "besten Kompromiss" zwischen "kleinem Code" und "schnellem Code" gewählt :D
vy 73
Andreas |
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: dl8mby on 28. November 2016, 12:19:53
Hallo Andreas,
da ich Eure Ergebnisse diesbezüglich nicht kenne und
auch nicht mit den selben Werkzeugen hantiere, habe
ich mir die Mühe gemacht mal selber den Compiler-
Output zu betrachten.
Bei der Vielzahl der Möglichkeiten, die der GCC bietet,
ist es fast unmöglich alle Optionen durchzutesten.
Wie sind die Erfahrungen bei Inlinefunktionen, Loop-
optimierungen, Branch-Optimierungen?
An die FPU habe ich mich noch nicht mal rangetraut,
da ich bei ARM nicht so viele Erfahrung habe.
Mir ist aber sehr wohl aufgefallen, das verschiedene
Compilate z.B eine Auswirkung auf die Geschwindigkeit
der Wasserfalldarstellung haben - nur so als Beispiel.
vy73
Markus
DL8MBY
|
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: DF8OE on 28. November 2016, 12:28:03
Richtig. Und nicht nur auf die Wasserfalldarstellungen.
Es ist nun absolut müssig, für jede neue Version eine Abschätzung zu machen, welche Optimierung denn nun für diese Version die Beste ist. Das ist ABM und nur was für die "1%-Kratzer". Wir haben mit Bedacht die vorhandene Optimierungseinstellung gewählt und mussten sie noch nie ändern bzw. überdenken. Der Zeit/Nutzen-Quotient wäre verheerend...
Die alte SW von Clint hatte ein paar auswirkungsreiche Bugs, die aber erst bei Aktivierung irgendeiner Optimierung "so richtig" zugeschlagen haben. Im Ergebnis ist das einer der Hauptgründe, warum die alte SW im Vergleich zur neuen dramatisch träger ist. Natürlich würde sie jetzt ohne Optimierung auch die Grenze überschreiten, bei der man die größere MCU braucht.
Letztendlich denken wir nicht mehr über einen Vergleich oder eine Änderung des gewählten Optimierungsmodes nach.
vy 73
Andreas |
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: DB4PLE on 28. November 2016, 16:37:22
Hallo,
bei Compileroptimierung für normale Anwendungsfälle ist Pragmatismus angesagt.
-O0 -> keine Optimierung -> Das geht nicht, denn dann darf der Compiler nicht mal die simpelsten Dinge machen sondern exakt das, was die Programmiersprache vorgibt und der Programmier hinschreibt. d.h. jede Variable wird ordentlich im Haupspeicher angelegt, obwohl sie eigentlich nur mal so zwischendurch verwendet wird.
-O1 -> geht immer, der erzeugte Code ist noch recht nah am ursprünglichen Code, aber schon deutlich schneller in vielen Fällen und braucht auch weniger RAM.
-O2 -> Guter Kompromiss zwischen Performance und Speicherverbrauch (Flash aber auch RAM)
-O3 -> Recht agressiv, schneller aber auch mehr Programmcode, aber nicht viel.
Deswegen nehmen wir -O2 und gut ist.
------------- Schwafel-Mode Ein -------------
Wenn man das optimieren ernsthaft betreiben will, dann hilft eigentlich nur eine Hotspot-Analyse und das gezielte An- (und Ab-)schalten von dutzenden von Einzeloptionen, deren Auswirkung man entweder kennt oder erprobt, teilweise auch nur für bestimmte Abschnitte. Das lohnt sich nur für Ausnahmefälle.
Ohne jemanden zu nahe zu treten (und auch auf mich bezogen): Niemand der mcHF Entwickler, die aktuell an dem Code arbeiten hat da genug Zeit und Erfahrung.
Es gibt natürlich grobe Richtlinien wie performanter Code so sein sollte, die im Prinzip an den Stellen, wo es weh tut inzwischen im mcHF umgesetzt werden. Da ist sicher noch jede Menge Potential für experimentierfreudige Menschen, ausgestattet mit Profiling-Erfahrung und viel Geduld.
Wenn aber nur noch Experten verstehen, warum der Code so aussieht, wie er aussieht, macht es den meisten keinen Spass mehr reinzuschauen. Auch hier ist Pragmatismus hilfreich.
Im übrigen wird aktuell die meisten Zeit im ARM DSP Code (den wir als binäre Bibliothek einbinden, das wäre zu prüfen, ob da Selbstkompilieren was bringt) oder ggfs. in FreeDV verbracht, d.h. nicht mal in "unserem" Code. Bei den FreeDV Optimierungen, die uns jetzt die Nutzung auf dem mcHF erlauben, waren es zu 100% Veränderungen am Code, die die Performance gebracht haben (und zwar ordentlich) und zu 0% Anpassungen an den Compilerschaltern.
Der eigentliche Performanceproblem im Alltag ist nicht performant gestalteter Code und nicht der 100st. Schalter, der nochmal 0.1% rausholt.
Aber mit Open Source: jeder ist eingeladen etwas beizutragen, was er oder sie beitragen möchte.
------------- Schwafel-Mode Aus -------------
In jedem Fall ein nettes Bash-Skript, Markus! Es wäre sehr interessant, das Skript für einen anderen Zweck zu nutzen und zwar zum Monitoring über die Zeit: Wenn ein .o File plötzlich deutlich größer (oder kleiner) wird, kann man schauen, ob man sich hier ein Problem eingehandelt hat.
73
Danilo
|
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: DB4PLE on 29. November 2016, 07:31:51
Hallo Markus and alle andere Mitstreiter,
im Nachgang erscheint mir mein Posting vor diesem nicht unbedingt gelungen. Der technische Inhalt ist korrekt, aber ich bin mir nicht sicher, ob es die richtige Botschaft vermittelt.
Ich begrüße es, wenn jemand Lust zum Experimentieren hat und das und die Ergebnisse des Experiments mit uns teilen will. Genau so mache ich es auch und es macht mir Spass. Und deshalb sollte kein Posting so geschrieben sein, das es jemanden den Spaß versauen könnte. Ich denke inzwischen, das mein Posting so verstanden werden kann. So war es nicht gedacht, im Gegenteil.
Werde mich bemühen in Zukunft Anspruch und Posting enger beieinander zuhalten, aber Fehler macht man immer mal. Muss man auch zugeben können.
73
Danilo
|
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: dl8mby on 29. November 2016, 09:05:25
Hallo OM's,
hallo Andreas,
hallo Danilo,
ich sehe das nicht so eng, entweder man hat Spaß
am Pfriemeln, oder nicht.
Für meinen Fall, ist es eben interessant auszuprobieren,
ob diverse Compilerschalter noch was an Performance
herauskitzeln oder nicht.
Da ich mit meinen 429/439 MC's neben der originalen
Bestückung mit 407/409 meinen mcHF betreibe, macht
es Sinn zu sehen ob ein -Ofast was bringt, wenn der
Flash und das RAM noch nicht am Anschlag sind.
Der genannte Kompromiss von Andreas, hat wohl seine
Berechtigung, da er alle Fälle der vorhandenen HW
berücksichtigen muss.
Für mich war es mal interessant zu sehen, wie sich die
einzelnen Compilerschalter auf die Objektdateien und die
Binaries auswirken.
Ich habe natürlich noch nicht all Resultate in den mcHF
hochgeladen um den Resultat am Objekt beobachten zu
können, werde es aber mal am nächsten WE versuchen.
Bis dahin wünsch ich frohes und erfolgreiches Weiter-
entwickeln, damit wir alle gemeinsam unsere Freude
am mchf haben.
Bin schon gespannt auf die weiteren Fortschritte in den
digitalen Mod.-arten.
vy73
Markus
DL8MBY
|
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: DF8OE on 29. November 2016, 09:19:02
Hallo Markus,
genauso, wie wir immer noch händeringend "Dokumentierer" suchen (weil es eben nicht mal eben aus dem Ärmel geschüttelt werden kann sondern auch seine Zeit braucht) - genauso sind auch solche Untersuchungen sehr aufwändig.
Die Optimierung anhand von Compilerschaltern wäre ebenfalls ein Fulltime-Job.
Um hier wirklich gezielt vorzugehen und nicht irgendwelche "gemittelten Zufallsergebnisse" zu bekommen, müssten Laufzeiten von "kritischen Modulen/Funktionen" ermittelt werden. Dann kann man diese mit unterschiedlichen Schaltern optimieren. Ich nehme stark an, dass das je nach Modul unterschiedliche Schalter sein werden und diese in Präprozessoranweisungen in der jeweiligen Datei gewählt werden (müssen).
Ob das den Aufwand wert ist kann man nicht vorher sagen. Daher kann ich nur aus meiner bisherigen Erfahrung im Bereich "embedded systems" berichten, dass es den Aufwand bei einer Projektgröße wie die des mcHF bislang noch nie wert war. Keines meiner bisherigen Projekte hat auch nur annähernd den Umfang des mcHF erreicht. Und je komplexer die Aufgabenstellung, desto mehr Möglichkeiten für Optimierungen gibt es....
Du müsstest also zunächst eine Möglichkeit haben, bestimmte Abläufe quantitativ zu messen, damit Du bei Änderungen kalre Ergebnisse bekommst.
Es ist ein "Fulltime-Job" . Wer das angeht, wird nicht nebenbei Programmieren oder Dokumentieren können 8)
vy 73
Andreas |
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: dl8mby on 29. November 2016, 11:17:20
Hallo Andreas,
das war mir klar, das die unterschiedlichen Module/Objekte
unterschiedliche Optimierungen benötigen, da jedes
Modul unterschiedliche Algorithmen/Funktionen/etc. abarbeitet,
weshalb einen generelle Optimierungs-Einstellung über alle
Module auch nur ein Kompromiss ist.
Das war ja der Grund, weshalb ich alle Object-Files betrachtet
habe, um zu sehen, wie die einzelnen Switches die jeweiligen
Module/Programmteile beeinflussen.
Die Timeinganalyse wäre das nächste, was mich interessiert,
weshalb ich auch mich für die QEMU Geschichte interessiert
habe, um zu sehen, wo welche Codeteile wie lange brauchen.
Da man den bestehenden Code/Source nicht sofort ohne
lange Einarbeitung und vor allem genaues Drüberlesen ver-
stehen wird, ich zumindest, muss man erst langsam einen
Überblick über das Ganze bekommen - um überhaupt
mitreden zu können.
Deshalb meine kleinen und langsamen Versuche das Ganze
Schritt für Schritt zu begreifen und zu durchschauen.
Wird wohl noch eine Weile dauern ;-)
vy73
Markus
DL8MBY |
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: DF8OE on 29. November 2016, 11:31:52
Es ist mittlerweilen in der Tat umfangreich...
Mit diesem Zusammenhang wird auch für mich aus der Sache mit dem QEMU ein Schuh :)
Leider sehe ich keine sinnvolle Möglichkeit, mit dem QEMU hier was weiterführendes zu bewirken.
Man kann das mit dem STLINK machen, oder man kann bei zu untersuchenden Funktionen am Beginn einen GPIO einschalten und am Ende wieder aus (so zur Zeit in FreeDV mit der grünen LED geschehen). Das ist zwar umständlich, da man sich jeweils eine "spezielle" FW bauen muss - aber dafür braucht man zur Überprüfung des Ergebnisses lediglich ein Scope (oder irgendwas, womit man Pulslängen möglichst exakt messen kann)...
vy 73
Andreas |
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: dl8mby on 29. November 2016, 12:23:50
Hallo Andreas,
ST-Link lässt keine Automatisierung zu.
Mit ARM-GCC + QEMU kann man über Nacht alle Compiler-Switches,
zumindest die relevanten, durchlaufen lassen und die Laufzeit
der bin/elf-Files vom Start zum Brackpoint testen und tabellarisch
erfassen.
Danach hätte man eine Übersicht, welche Module wie viel Zeit
benötigen. Da es sich um eine relative Messung handelt,
ist die Absolute Laufzeit nicht so wichtig.
Wie und ob man das mit ST-Link macht, kann ich nicht sagen.
Den realen MC dauernd mit Binaries zu flashen ist auch
nicht optimal und zudem zeitintensive.
Man muss nur nachdenken, wie man externe Ereignisse
an ein bin-Image, das im QEMU läuft bringt, um den
Programmablauf zu steuern.
War nur so ein Gedanke von mir, den ich hier mal poste.
vy73
Markus
DL8MBY
|
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: DF8OE on 29. November 2016, 13:18:07
Das Problem bei der Sache mit der Emulation ist, dass Du das Binary ebenfalls ändern müsstest - weil viele Abläufe davon abhängen, was i/o mäßig am STM passiert. Es ist nicht möglich (denke ich...) eine Umgebung für den Emulator zu bauen, der diese Sachen in das Binary "füttert". Folglich müsstest Du verschiedene Daten "injezieren" - was den Ablauf schon wieder an empfindlicher Stelle verändert. Ich denke nur an die I2S-Abarbeitung, die dazugehörigen Puffer, die damit verbundenen Interrupts...
Ich vermute daher, dass ein automatisierter, simulierter Ablauf nicht mit den uns zur Verfügung stehenden Mitteln realisierbar ist. Gerne lasse ich mich eines Besseren überzeugen - habe aber noch nicht mal Ansätze für sowas...
vy 73
Andreas |
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: dl8mby on 29. November 2016, 14:11:29
Hallo Andreas,
ich meinet folgendes,
Loop:
Compilerlauf <Makefile mit verschiedenen Schalter-komb. aus Liste>
if (GCC == SUCCESS, oder mchf.elf exist, oder so ähnlich)
qemu-system-arm
-machine ...
-nographic -monitor null -serial null
-kernel mchf.elf -gdb
{ hier wird es etwas komplizierter ;-)
automatisch im Debugger Breakpoint setzen
run vom Image
? wieviel Zeit ist verstrichen
Ergebnis notieren in File mit Switch-Kombination.
}
end if
decrement compiler-switch-liste um aktuelle Parameter Komb.
exit loop if liste leer
Jump Loop;
Soweit meine Ablauf.
Ob das so klappt muss ich erst mal testen,
doch dazu brauche ich eine lauffähige QEMU
Installation für cortex-m4.
vy73
Markus
DL8MBY |
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: DB4PLE on 29. November 2016, 19:32:12
Hallo Markus,
da ist immer noch das Problem der fehlenden FPU Emulation für den Cortex M4 in QEMU. Solange das nicht gelöst ist, wird leider schon der Start eines "normal" erzeugten mcHF.bin nicht möglich sein, da dabei irgendwann die FPU angeschaltet wird (was dann zu einer Ausnahme führt, mangels FPU).
Oder gibt es schon einen QEMU mit FPU Emulation?
73
Danilo |
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: dl8mby on 06. December 2016, 09:48:10
Hallo OM's,
hallo Andreas,
hallo Danilo,
ich spiele mich gerade mit einem Programm (IDA)
mit dem ich einen Funktionsaufruf-Baum erstellen
kann.
Siehe Anhang.
Dieser Baum ist ist aber so riesig, dass er in einer
einfachen Graphik nicht so ohne Weiteres darstellbar
ist.
Anhang ist nur angehängt, damit Ihr Euch vorstellen könnt,
was ich meine.
Fortsetzung im nächsten Thread, da ich noch einen
Anhang hinzufügen möchte.
Markus
DL8MBY |
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: dl8mby on 06. December 2016, 09:55:30
Mit dem angehängten PNG kann man nicht viel anfangen,
das ist mir klar, aber eventuell mit der zweiten Datei.
Mir ist noch nicht das Format, der exportierten Datei
bekannt und möglicherweise ist es IDA spezifisch.
Es enthält aber die ganze Vernetzung aller Funktionen
als Baumstruktur. Falls es für sowas einen Viewer gibt,
könnte es für Euch von Interesse sein.
Möglicherweise liefert aber auch Eclipse so eine Ansicht.
Ist das etwas, was den SW-Entwicklern hilft, die verschiedenen
Modulle/Objecte/"Classen" besser zu überblicken?
@Andreas,
falls nicht, bitte den Thraed löschen.
Danke!
Markus
DL8MBY
|
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: DF8OE on 06. December 2016, 10:21:46
Hallo Markus,
wie Du schon geschrieben hast: Man kann nicht viel erkennen...
Aber meine Phantasie kann sich durchaus vorstellen, was da zu sehen ist. So ein "Netzplan" kann schon sehr hilfreich sein. Je nachdem, was man wissen/machen will, mal sehr viel, mal weniger. Daher finde ich so eine Erstellung / die Beschreibung der Umgebung etc. sehr sinnvoll!
vy 73
Andreas |
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: dl8mby on 06. December 2016, 11:14:38
Hallo Andreas,
die angehängte mchf_elf_func_tree.txt Datei beinhaltet
den ganzen Baum in einem Format, für den ich noch den
zugehörigen Viewer finden muss.
Vielleicht kennt ja jemand das Format:
graph: {
title: "Call flow of mchf.elf"
// IDA palette
colorentry 32: 0 0 0
colorentry 33: 0 0 255
colorentry 34: 0 0 255
colorentry 35: 128 128 128
colorentry 36: 128 128 128
colorentry 37: 0 0 128
colorentry 38: 0 0 128
colorentry 39: 0 0 255
colorentry 40: 0 0 255
colorentry 41: 0 0 128
colorentry 42: 0 128 0
colorentry 43: 0 255 0
colorentry 44: 0 128 0
colorentry 45: 255 128 0
colorentry 46: 0 128 0
colorentry 47: 128 128 255
colorentry 48: 255 0 0
colorentry 49: 128 128 0
colorentry 50: 1 1 1
colorentry 51: 192 192 192
colorentry 52: 0 0 255
colorentry 53: 0 0 255
colorentry 54: 0 0 255
colorentry 55: 128 128 128
colorentry 56: 128 128 255
colorentry 57: 0 128 0
colorentry 58: 0 0 128
colorentry 59: 0 0 255
colorentry 60: 128 0 128
colorentry 61: 0 128 0
colorentry 62: 0 128 0
colorentry 63: 0 128 64
colorentry 64: 0 0 128
colorentry 65: 0 0 128
colorentry 66: 255 0 255
colorentry 67: 128 128 0
colorentry 68: 0 0 128
colorentry 69: 0 0 255
colorentry 70: 0 0 128
colorentry 71: 0 0 255
colorentry 72: 0 0 0
colorentry 73: 255 255 255
colorentry 74: 192 187 175
colorentry 75: 0 255 255
colorentry 76: 0 0 0
colorentry 77: 128 0 0
colorentry 78: 128 128 128
colorentry 79: 128 128 0
colorentry 80: 255 0 255
colorentry 81: 0 0 0
colorentry 82: 0 0 255
colorentry 83: 0 0 0
node: { title: "0" label: "deregister_tm_clones" color: 76 textcolor: 73 bordercolor: black }
node: { title: "1" label: "register_tm_clones" color: 76 textcolor: 73 bordercolor: black }
node: { title: "2" label: "__do_global_dtors_aux" color: 76 textcolor: 73 bordercolor: black }
node: { title: "3" label: "frame_dummy" color: 76 textcolor: 73 bordercolor: black }
node: { title: "4" label: "NVIC_SystemReset" color: 76 textcolor: 73 bordercolor: black }
node: { title: "5" label: "CriticalError" color: 76 textcolor: 73 bordercolor: black }
node: { title: "6" label: "NMI_Handler" color: 76 textcolor: 73 bordercolor: black }
node: { title: "7" label: "HardFault_Handler" color: 76 textcolor: 73 bordercolor: black }
node: { title: "8" label: "MemManage_Handler" color: 76 textcolor: 73 bordercolor: black }
node: { title: "9" label: "UsageFault_Handler" color: 76 textcolor: 73 bordercolor: black }
node: { title: "10" label: "SVC_Handler" color: 76 textcolor: 73 bordercolor: black }
node: { title: "11" label: "DebugMon_Handler" color: 76 textcolor: 73 bordercolor: black }
node: { title: "12" label: "SysTick_Handler" color: 76 textcolor: 73 bordercolor: black }
node: { title: "13" label: "EXTI0_IRQHandler" color: 76 textcolor: 73 bordercolor: black }
node: { title: "14" label: "EXTI1_IRQHandler" color: 76 textcolor: 73 bordercolor: black }
node: { title: "15" label: "EXTI15_10_IRQHandler" color: 76 textcolor: 73 bordercolor: black }
node: { title: "16" label: "TransceiverStateInit" color: 76 textcolor: 73 bordercolor: black }
node: { title: "17" label: "main" color: 76 textcolor: 73 bordercolor: black }
node: { title: "18" label: "WWDG_IRQHandler" color: 76 textcolor: 73 bordercolor: black }
node: { title: "19" label: "Reset_Handler" color: 76 textcolor: 73 bordercolor: black }
node: { title: "20" label: "zero_loop" color: 76 textcolor: 73 bordercolor: black }
node: { title: "21" label: "zero_loop_ccm" color: 76 textcolor: 73 bordercolor: black }
node: { title: "22" label: "SystemInit" color: 76 textcolor: 73 bordercolor: black }
node: { title: "23" label: "NVIC_PriorityGroupConfig" color: 76 textcolor: 73 bordercolor: black }
node: { title: "24" label: "NVIC_Init" color: 76 textcolor: 73 bordercolor: black }
node: { title: "25" label: "SysTick_CLKSourceConfig" color: 76 textcolor: 73 bordercolor: black }
node: { title: "26" label: "ADC_Init" color: 76 textcolor: 73 bordercolor: black }
node: { title: "27" label: "ADC_StructInit" color: 76 textcolor: 73 bordercolor: black }
node: { title: "28" label: "ADC_CommonInit" color: 76 textcolor: 73 bordercolor: black }
node: { title: "29" label: "ADC_Cmd" color: 76 textcolor: 73 bordercolor: black }
node: { title: "30" label: "ADC_RegularChannelConfig" color: 76 textcolor: 73 bordercolor: black }
node: { title: "31" label: "ADC_SoftwareStartConv" color: 76 textcolor: 73 bordercolor: black }
node: { title: "32" label: "ADC_GetConversionValue" color: 76 textcolor: 73 bordercolor: black }
node: { title: "33" label: "DAC_Init" color: 76 textcolor: 73 bordercolor: black }
node: { title: "34" label: "DAC_Cmd" color: 76 textcolor: 73 bordercolor: black }
...
edge: { sourcename: "133" targetname: "124" }
// node 134
// node 135
edge: { sourcename: "135" targetname: "181" }
// node 136
edge: { sourcename: "136" targetname: "135" }
// node 137
edge: { sourcename: "137" targetname: "182" }
// node 138
// node 139
// node 140
// node 141
// node 142
// node 143
// node 144
// node 145
// node 146
// node 147
edge: { sourcename: "147" targetname: "388" }
edge: { sourcename: "147" targetname: "596" }
// node 148
edge: { sourcename: "148" targetname: "280" }
edge: { sourcename: "148" targetname: "281" }
edge: { sourcename: "148" targetname: "388" }
edge: { sourcename: "148" targetname: "596" }
// node 149
...
vy73
Markus
DL8MBY |
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: DB4PLE on 06. December 2016, 12:24:04
Hallo Markus,
schau nett aus, das Bild. Das Dateiformat kenne ich jedenfalls nicht.
Übrigens erzeugt der Aufruf von "make docs" im Verzeichnis mchf-github/mchf-eclipse ein Verzeichnis mchf-github/docs/html
Dort dann mal index.html doppelklicken.
Dort werden dann auch klickbare Call- und Caller-Graphen erzeugt. Das ist (durch die Reduktion) etwas übersichtlicher.
Dank gilt dem github Contributor, der das in mcHF eingebaut hat. Wird leider wenig genutzt (auch von mir, ich nutze die Funktionen in Eclipse, aber da gibt es keine so schönen Bilder, dafür springt man direkt in den Source-Code an die gewünschte Stelle im Editor).
Im Anhang mal das Bild der Aufrufstruktur von main() wie es von doxygen erzeugt wird. In der Docu kann man dann auf einen Funktionsnamen klicken und sieht dann noch weitere Infos zu der Funktion.
73
Danilo
|
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: dl8mby on 06. December 2016, 12:41:19
Hallo Danilo,
genau nach so was habe ich gesucht.
Dazu muss man sich halt auskennen.
War mir sicher, das irgendwo etwas in der Art schon existiert.
Man muss es halt finden oder es bereits wissen.
Danke für den nützlichen Hinweis.
vy73
Markus
DL8MBY
|
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: HB9ocq on 07. December 2016, 20:07:01
Vielleicht kennt ja jemand das Format:
|
|
Das ist DOT-Language aus dem SW-Paket Graphviz:
* <http://www.graphviz.org (http://www.graphviz.org)>
Da bin ich Fan von, und fast fluent in dieser Sprache :-)
Wie Danilo schon darauf hingewiesen hat, tut auch Doxygen davon gebrauch machen.
Im Sommer hatte ich angefangen aufgrund des Outputs von make docs die include-Hierarchie in mcHF zu vereinfachen, musste aber "mangels Ressource Zeit" das liegen lassen.
In den Diagrammen zur include-Hierarchie von mcHF ist naemlich sehr einfach zu sehen dass da vieles gewurschtelt ist (zumindest war's so im Sommer).
An sich ist es relativ einfach zu bereinigen, sodass es einfacher und geradliniger wird (zu lesen im Code, anzusehen in den Diagrammen). Dann sieht man allerdings gleichzeitig dass diverse Funktionen besser in anderen Quellfiles umzuziehen waehren.
Nicht zuletzt bin ich daran gescheitert, weil da etliche Dateien aufs mal zu modifizieren sind und ich nur kurze Zeitabschnitte am Code sein konnte: bis ich etwas bereit hatte waren schon wieder so viele (funktionale) Commits reingekommen, dass ich mit mergen nicht nachkam.
Mittlerweile scheint es ruhiger daherzugehen, mit den Commits - ich sollte wieder einen Anlauf nehmen...
Warum ist da Gewurschtel bei der Includerei? Nun, daran leiden viele C-Projekte: C hat naemlich nur einen einzigen Namespace sodass es fuer Funktionen fast egal ist, durch welches include in welcher anderen Datei sie "reinkommen", solange sie einfach "reinkommen". Das forciert nicht gerade eine saubere Auftrennung in separate Dateien. (Andere Sprachen sind da strikter - C++ nur WENN man von Namespaces gebrauch macht, ist ja nicht pflichtig...)
Besteht in einem C-Projekt nicht das Bestreben, das was nach Bibliothek riecht auch effektiv als separat vom Projekt handhabbare Bibliothek zu gestalten (sondern pragmatisch "das Projekt ist klein, Hauptsache es ist drin und tut", "Code muss funktionieren, nicht gut aussehen", usw.), so haben eben andere Quellcode-Leser solange das Nachsehen bis sie nicht einen guten, ziemlich gesamten, Ueberblick des Projektes haben.
Mit nachteiliger Quellcodestruktur (hier: Include-Gewurstel) kann ein hinzustossender Interessent u.U. nur schlecht ein einziger Aspekt im Projekt ansehen/bewerten/verbessern/klauen/usw.
Der Zweck ein make docs im Projekt zu haben ist eben selten "Doku zu haben um (ausgedruckt) abzugeben", sondern eben auch Unstimmigkeiten, welche im Code nicht direkt augenfaellig sind, anders zu visualisieren (bsp. include-Gewurstel, aber auch anderes) und genauso spaeteren Mitstreiter den Einstieg ins Projekt zu erleichtern.
Befuehrworter von GUI-IDEs haben solches (alternative Visualisierung, erleichterte Navigation) sofort und interaktiv zur Verfuegung, eben weil die GUI-IDEs "so gut zaubern koennen".
Was sie gegenueber Makefile-Fans nicht haben (oder zumindest nur mit erheblich mehr Aufwand bekommen) ist dass es mittels make docs unsaeglich einfach ist ein|mehrere fruehere|r und ein aktueller Code-Stand zu "Diagrammisieren" und so Projektevolution (hoffentlich ProjektFORTschritt, nicht RUECKschritt) gleichzeitig am Bildschirm anzuschauen resp. weiterzuzeigen (vergl. Vorher/Nacher-Darstellung).
Man merkt's wohl: ich gehoere zur Sorte "Lieber ein richtiges Makefile, als ein farbiger Editor mit zu vielen Fenster" ;-)
(sorry fuer den saftigen Theorieblock - weiter mit der Werbung... :-) |
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: dl8mby on 08. December 2016, 08:19:40
Hallo Stephan,
kannst Du bitte noch was zu make docs sagen.
Laut Makefile wird ja "nur" doxygen aufgerufen,
aber das Know-How steckt wohl im "Doxyfile",
was bedeutet, das die Anzahl der nützlichen
Informationen von dessen Güte abhängt.
Wie erstellt man dieses? Gibt es dafür Templates
je nach Programmiersprache oder ist das alles
Handarbeit?
docs:
# generate source docs as per "Doxyfile"
doxygen Doxyfile
Danke vorab für Deine Erklärung.
vy73
Markus
DL8MBY
|
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: DB4PLE on 08. December 2016, 17:19:13
Hallo Markus,
das im mcHF verwendete Doxyfile ist super dokumentiert und liefert sehr viel Information in den generierten Dateien.
Einfach mal aufrufen und das Ergebnis anschauen (dazu braucht es natürlich doxygen auf dem Rechner).
73
Danilo |
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: dl8mby on 09. December 2016, 06:10:30
Hallo Danilo,
danke für den Hinweis.
Hat bei mir soweit geklappt, wie Du an dem angehängten
Bild sehen kannst.
Hat aber eine Weile gedauert, bis ich die Dokumentation
gefunden habe, da unglücklicherweise make docs als auch
doxygen ./Doxyfile mir aus irgend einem Grund das docs
Verzeichnis nicht nach .../Afu/mchfTRX/wrk/20161208, wo
der code liegt, sondern nach .../Afu/mchfTRX/wrk/docs
geschrieben hat und ich mir einen Wolf nach den
html Dateien im .../20161208 Verzeichnis gesucht habe.
Jetzt bin ich schlauer ;-)
Somit habe ich jetzt Lektüre für die Weihnachtstage und
danach.
Danke!
vy73
Markus
|
Title: Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
Post by: dl8mby on 09. December 2016, 06:25:49
Hallo Danilo,
hallo OM's,
habe mittlerweile den Grund gefunden, lag an der Configuration.
Steht so im Doxyfile und ist somit gewollt.
vy73
Markus
DL8MBY
# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path
# into which the generated documentation will be written. If a relative path is
# entered, it will be relative to the location where doxygen was started. If
# left blank the current directory will be used.
OUTPUT_DIRECTORY = ../docs |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|