Seit dem 3.6.0-Release hat sich insbesondere bei der Geschwindigkeit des erzeugten Codes für Ganzzahlberechnungen einiges getan. SDCC3.6.0 lag bei Whetstone-, Dhrystone- und Coremark-Scores weit hinter den anderen Compilern (Cosmic, Raisonance, IAR): http://colecovision.eu/stm8/compilers.shtml Die aktuelle Entwicklerversion (3.6.2 #9667) erreicht nun höhere Dhrystone- und Coremark-Scores als die anderen Compiler. Philipp
Angehängte Dateien:
-
scores-9667.png
11 KB
Hallo, lange nichts mehr mit gemacht, Sommer ist bei mir keine Bastelzeit aber im Herbst wieder. Gilt das auch für den Z80? Und was ist mit der so wichtigen Funktion "dead code" zu eliminieren, d.h. unbenutzte Funktionen nicht in das Kompilat zu übernehmen? Man benutzt ja oft Source Libs - zb ich die mcurses von Frank M. (ukw) - aber davon eben nur einen Teil. Gruss, Christian
Wer schon lange nichts mehr mit SDCC gemacht hast, wird wohl einige Verbesserungen vorfinden, unabhängig von der Zielarchitektur. Zu den Verbesserungen seit 3.6.0: Es gab ein paar Bugfixes für Z80. Die besseren Scores in Dhrystone und Coremark wurden durch zweierlei erreicht: 1) Zielarchitektur-spezifische Optimierungen, 2) allgemeine Optimierungen. 1) Bringt für den Z80 erstmal nichts (aber es wurde etwas Infrastruktur geschaffen, die es ermöglicht manche der Verbesserungen später entsprechend auch für Z80 umzusetzen). 2) Wirkt auch für den Z80. Allerdings beziehen sich diese Optimierungen hauptsächlich auf Multiplikationen. Philipp
Hallo, danke! Und was ist mit der Dead Code Eleminierung? Wird ein Aufruferbaum während der Kompilierung erstellt? Gruss, Christian
Christian schrieb: > Hallo, > > danke! Und was ist mit der Dead Code Eleminierung? Wird ein Aufruferbaum > während der Kompilierung erstellt? > > > Gruss, > Christian Der Compiler eliminiert nur Dead Code innerhalb von Funktionen. Ganze Funktionen werden vom Compiler nicht entfernt. Allerdings kann der Linker ungenutzte Module aus Bibliotheken weglassen. Das wird beispielsweise verwendet, um aus der Standardbibliothek nur die benötigten Funktionen in die Binärdateien zu übernehmen. Wenn man also eine Bibliothek mit einem Modul pro Funktion hat (d.h. üblicherweise eine Quelldatei pro Funktion), werden alle nicht verwendeten Funktionen aus der Bibliothek weggelassen. Philipp
Philipp Klaus K. schrieb: > Der Compiler eliminiert nur Dead Code innerhalb von Funktionen. Ganze > Funktionen werden vom Compiler nicht entfernt. Vielleicht denkt ihr da ja mal drüber nach. Die Praxis sieht ja so aus, dass kaum jemand mehr Libs verwendet, die er selbst gemacht hat. Ich habe es in 25 Jahren nie gemacht. Das liegt alles als Source vor und wird jedesmal mit kompiliert. Ich binde immer die gleichen "Libs" ein, zb mcurses und die Bedienung der UART und picke mir raus, was ich grad brauche. Im Kompilat ist aber alles mit drin und das ist bei 48kb nunmal ein Platz Killer. Ich könnte mir aber vorstellen, dass der Umbau eines 1 Pass Compilers auf 2 Pass erheblich ist. Aber ausgehend von main kan man sich ja rekursiv durchhangeln was alles aufgerufen wird Und nochwas: Der Code wird ja immer kleiner, je höher man diese bestimmte Zahl in der Command Line setzt (fällt mir grad nicht ein), dabei erhöht sich auch die Compilierdauer ganz erheblich, bei mir sind es 10 Minuten für rund 15 Sourcen. Glaube 100.000 habe ich da eingetragen. Möglich sind auch 500.000 aber das bringt nur noch wenig. Gibt es da eine sinnvolle Grenze?
Christian J. schrieb: > Und nochwas: Der Code wird ja immer kleiner, je höher man diese > bestimmte Zahl in der Command Line setzt (fällt mir grad nicht ein), > dabei erhöht sich auch die Compilierdauer ganz erheblich, bei mir sind > es 10 Minuten für rund 15 Sourcen. Glaube 100.000 habe ich da > eingetragen. Möglich sind auch 500.000 aber das bringt nur noch wenig. > Gibt es da eine sinnvolle Grenze? Wenn weiteres erhöhen des Parameters von --max-allocs-per-node beweisbar nichts mehr bringt, steigt auch die Compilierdauer nicht weiter an. Aber bei welchem Wert das ist, hängt von der kompilierten Funktion ab. Philipp
Christian J. schrieb: > Philipp Klaus K. schrieb: >> Der Compiler eliminiert nur Dead Code innerhalb von Funktionen. Ganze >> Funktionen werden vom Compiler nicht entfernt. > > Vielleicht denkt ihr da ja mal drüber nach. Die Praxis sieht ja so aus, > dass kaum jemand mehr Libs verwendet, die er selbst gemacht hat. Ich > habe es in 25 Jahren nie gemacht. Das liegt alles als Source vor und > wird jedesmal mit kompiliert. Ich binde immer die gleichen "Libs" ein, > zb mcurses und die Bedienung der UART und picke mir raus, was ich grad > brauche. Im Kompilat ist aber alles mit drin und das ist bei 48kb nunmal > ein Platz Killer. > > Ich könnte mir aber vorstellen, dass der Umbau eines 1 Pass Compilers > auf 2 Pass erheblich ist. Aber ausgehend von main kan man sich ja > rekursiv durchhangeln was alles aufgerufen wird Deutlich einfacher dürfte sich die Optimierung im Linker imlementieren lassen. Aber SDCC hat halt nicht so viele Entwickler, und die SDCC-Entwickler haben halt auch nicht unbegrenzt Zeit. Bisher sieht es aus, als wird die nächste SDCC-Version hauptsächlich Standardkompabilität and die Geschwindigkeit des erzeugten Codes verbessern: http://sdcc.sourceforge.net/mediawiki/index.php/SDCC_3.7.0_Release (siehe Feature List ganz unten). Philipp
Hallo Philipp, ich finds schon stark, was ihr da fabriziert, allerdings wende ich den SDCC auch nur auf Hobby Niveau an, weil ich gern programmiere. Und solange da keine kommerziellen Interessen hinter steht kriegt der eben auch keinen Turbo aufgeschnallt :-) Wird ja bald Winter, dann gehts wieder los mit Z80 und STM32... Gruss, Christian
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.