Pages: 1 [2] 
|
 |
|
|
Author
|
Topic: arm-none-eabi-gcc Code Optimierung mittels Compiler (Read 4506 times)
|
|
DB4PLE
positron
Urgestein
 Offline
Posts: 1278
|
 |
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #15 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
|
|
 Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #16 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
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #17 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
|
|
|
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #19 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
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #20 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
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #21 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
|
|
Logged
|
|
|
|
HB9ocq
Neuling
Offline
Posts: 46
OSS: free bugs'n'fixes!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #22 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>
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... :-)
|
|
Logged
|
73 de Stephan HB9ocq
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #23 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
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #24 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
|
|
Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #25 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
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #26 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
|
|
Logged
|
|
|
|
Pages: 1 [2] 
|
|
|
|
|
|
|
mchf_elf_func_tree.txt
Online
