Hier im Forum treten immer wieder Fragen zu sdcc auf, oft von Leuten, die gerade anfangen, sdcc zu verwenden, oder die im Betracht ziehen, sdcc zu verwenden. Da ich mich etwas mit sdcc auskenne, aber wohl nicht dauerhaft im Forum aktiv sein werden, möchte ich etwas dazu schreiben, was den sdcc nutzenden C-Programmierer zu Zeit (sdcc 3.4.0) so erwartet. Vieles davon hängt vom Port ab, aber zuerst das allgemeine: sdcc ist ein C-Compiler, der versucht, sich weitgehend an die Standards (ISO C90, ISO C99, ISO C11) zu halten. Innerhalb der Spielräume, die der Standard läßt, wird gelegentlich anders als bei gcc vorgegangen. Üblicherweise dürfte man im C99-Modus (Kommandozeilenoption --std-c99) arbeiten wollen. sdcc ist auf 8-Bit-Architekturen ausgelegt, und kann oft halbwegs effizienten Code für diese erzeugen. Mittels --opt-code-size bzw. --opt-code-speed läßt sich das Optimierungsziel wählen. Leider fehlen noch ein paar Features aus den Standards, allerdings hauptsächlich solche, die auf 8-Bit Microcontrollern eher selten verwednet werden. Details siehe: http://sdcc.sourceforge.net/mediawiki/index.php/Standard_compliance sdcc ist ausgereifte Software, es gibt selten schwere Bugs. Nächtlich laufen regression tests auf verschiedenen Plattformen, d.h. es werden kleine C-Programme mit sdcc auf verschiedenen Architekturen und Betriebssystemen für verschiedene Zielarchitekturen kompiliert, und dann im Simulator ausgeführt, um zu testen, ob sie sich korrekt verhalten. Ein paar der tests wurden bei der Implementierung von Features in sdcc geschrieben. Aber die meisten stammen aus Bug reports: Wenn ein Bug in sdcc behoben wird, wird ein regression test geschrieben, um sicherzustellen, das dieser Bug nicht wieder auftreten kann. Außerdem ahben wir viele regression tests von gcc übernommen.
mcs51 und ds390 sind relativ alte Ports. Soweit ich weiß, sind sie recht stabil, aber es gibt hie und da ein paar fehlende Features, die in anderen Ports drin sind. An manchen Ecken wurde zugunsten von Speicherplatzeffizienz gegen Standardkompatiblität entschieden (bool als bit impementiert).
Auch hc08 und s08 sind etablierte, stabile ports. Da der s08 port aus dem hc08 port entwickelt wurde, mag es hie und da noch ungenutzes Optimierungspotential geben. Wie auch beim mcs51 und ds390, sind Funktionen nicht reeentrant, falls nicht explizit anders angegeben (per Schlüsselwort oder Kommandozeilenoption). Der erzeugte Code ist recht gut, aber üblicheweise etwas größer als bei den nichtfreien Compilern. Diese Ports verwenden den neuen Registerallokator (dazu später mehr). Philipp
Mach doch bitte aus Deinem Beitrag hier einen Beitrag im Wiki. Da ist so etwas besser aufgehoben.
Kommen wir zum z80-Port und den verwandten (z180, gbz80, r2k, r3ka, tlcs90). Der Z80-Port ist recht alt, hat aber im Laufe der Zeit bedeutende Verbesserungen erfahren. Die anderen Ports sind daraus entwickelt worden. Der tlcs90-Port hat keinen Simulator, und wird daher von den regression tests nicht erfasst. Recht effizienter Code wird generiert für z80, z180, r2k. Bei den anderen gibt es noch etwas mehr ungenutzes Potential. Im Vergleich zu den nicht-freien Compilern erzeugt sdcc üblicherweise besseren Code als CROSS-C und HITECH-C, aber etwas schlechteren als IAR. Manche dieser Prozessoren haben ein paar komplexe Instruktionen, wie z.B. ldir. Für einen Compiler ist es nicht einfach, zu erkennen, wann z.B. eine Schleife mit Hilfe ldir effizienter implementiert werden könnte. Die Befehle werden aber in den Bibliotheksfunktionen (z.B. memmove()) genutzt. Und für manche Bibliotheksfunktionen (memcpy(), strcpy(), strncpy(), strchr(), memset()) wird, wo möglich, auch kein Funktionsaufruf erzeugt, sondern direkt Code generiert. Da der Z80 nur ein Prozessor, kein ganzes System ist, gibt es ein paar Dinge, die der Programmierer erledigen muß (z.B. Speicherinitialisierung), die ihm bei anderen Ports von sdcc abgenommen werden. Dazu dient die crt0. Auch diese Ports verwenden den neuen Registerallokator. Philipp
Die pic-ports hinken den anderen Ports weit hinterher. Etwas die Hälfte der offenen Bugreports in sdcc bezieht sich auf pics. Es gibt den pic14-port für die pics mit 14-bit Instruktionen (z.B. 16Fxxx, 12Fxxx) und den pic16 für die pics mit 16-bit Instruktionen (z.B. PIC18Fxxx). Wobei der pic16-port sich deutlich besser schlägt als der pci14 port. Der pic16 port ist kurz davor, in die nächtlichen regression tests aufgenommen zu werden. Der pic14-port ist weit davon entfernt. In beide ports müßte noch viel Arbeit reingesteckt werden. Philipp
Ich wiederhole mich: > Mach doch bitte aus Deinem Beitrag hier einen Beitrag im Wiki. Da ist so > etwas besser aufgehoben.
Ich habe die bisherigen Beiträge jetzt 'mal nach http://www.colecovision.eu/sdcc.shtml kopiert, und werde sie dort im Laufe des Tages vervollständigen (z.B. stm8 port) und überarbeiten. Falls es Fragen zu sdcc gibt, hoffe ich, diese beantworten zu können, und würe je nachdem, die Antworten auch dort einarbeiten. Philipp -- link repariert -rufus
:
Bearbeitet durch User
Danke für die Infos. Ich habe vor kurzem angefangen den cc1111 mit dem sdcc zu programmieren und habe mich gewundert dass Funktionen Standardmäßig nicht reentrant sind. Wenn man das aber per compilerschalter aktiviert, funktionieren die Standard libs nicht mehr richtig. Ansonsten lief das ganze echt problemlos. Da ich von der avr und stm32 Seite kam habe ich erst nicht so ganz durchgeblickt bei den verschiedenen Speichermodellen, aber das scheint generell eine 8051 Sache zu sein.
Philipp Klaus Krause schrieb: > Ich habe die bisherigen Beiträge jetzt 'mal nach > > http://www.colecovision.eu/sdcc.shtml Das wäre nicht nötig gewesen -- hier gibt es ein für derartige Informationssammelungen vorzüglich geeignetes Wiki: http://www.mikrocontroller.net/articles/Hauptseite
:
Bearbeitet durch User
Harald Nagy schrieb: > Die Seite gibt es nicht mal.... Was magst Du meinen? Ich habe ja nicht auf http://www.mikrocontroller.net/articles/Sdcc verlinkt ...
:
Bearbeitet durch User
Rufus Τ. Firefly schrieb: > Was magst Du meinen? Den fehlerhaften Link von Philipp. Da ist das http:// doppelt
Ah. Den hab' ich jetzt repariert.
Rufus Τ. Firefly schrieb: > Ah. Den hab' ich jetzt repariert. Ja exakt das. Hatte ich am Smartphone nicht bemerkt. Danke.
Hi, ich schätze die Frage passt hier ganz gut rein. Ich versuche mit dem sdcc FUZIX zu kompilieren (https://github.com/EtchedPixels/FUZIX) doch mit der 3.4.0er Version funktioniert das nicht. Unter anderem wegen dem long long bug. In der Readme für den FUZIX-Kernel steht, ich solle den 3.4.2 benutzen, aber ich finde den auf sf nicht. Nur den 3.4.0 oder den 3.4.4 im trunk. Ich habe den im trunk zwar mal ausprobiert, aber wie zu erwarten hat der natürlich nicht wirklich funktioniert. Ist auch nicht weiter verwunderlich ;) Aber offensichtlich gibt es noch 3 Versionen nach dem 3.4.0 von dem sdcc im Umlauf, die scheinbar stable sind? Wo kann man sich den Code dazu runterladen? MfG Tobias
tobias schrieb: > Wo kann man sich den Code dazu runterladen? Ich verstehe die Frage nicht. Hier sind alle offiziellen Versionen verfügbar: http://sourceforge.net/projects/sdcc/files/sdcc/ Und wenn Du schon den 'trunk' hast, kannst Du mit
1 | svn checkout --revision $VERSIONSNUMMER |
die gewünschte Version ins Verzeichnis holen. Jens
In dem Readme steht eine explizite Version von dem sdcc ab wann sich die Quellen kompilieren lassen, weil die vorherigen Versionen eben den long long Bug besitzen. Diese Version (3.4.2) ist jedoch wohl keine offizielle Releaseversion (die letzte Releaseversion ist 3.4.0), daher finde ich sie dort auch nicht. Eine bestimmte Revision auschecken ist auch eine Möglichkeit, jedoch müsste ich dazu wissen, welche Revision denn nun eine stabile Version ist ;) MfG Tobias
tobias schrieb: > Eine bestimmte Revision auschecken ist auch eine Möglichkeit, jedoch > müsste ich dazu wissen, welche Revision denn nun eine stabile Version > ist ;) Ab welcher SVN-Revision die Versionsnr. 3.4.2 vergeben wurde, ist mit "svn log .version" leicht herauszufinden. (Und dann "svn update --revision 9143")
:
Bearbeitet durch User
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.