Hallo, als ich mir gestern ein neues Snapshot des SDCC zog und dieses durch compilierte und installierte fiel mir bei der Kompilierung eines lauffähigen Sourcecodes für Z80 auf, dass er Dinge wie __sdcc_heap_init in der crt.s plötzlich nicht mehr kompilierte. Auch eine (volatile) (unsigned char*) Deklaration wurde plötzlich als Fehler gemeldet. __sdcc_heap_init dient im Startupo dazu den Heap Zeiger zu setzen, damit malloc Bescheid weiss. Testweise ging ich 1 Woche zurück und holte mir eine etwas ältere Versiona aber auch diese lief nicht. Erst eine Version vom 3.0.15. vom Juni lief dann wieder. Hat das sonst noch jemand bemerkt? Gruss, Christian
Bei vermuteten Compilerfehlern empfiehlt es sich, einen minimierten Testcase zu bauen, der den Fehler reproduziert. Idealerweise aus wenigen Zeilen. Es liegt auch nahe, den betreffende Code und die Fehlermeldung zu posten.
Error: Global __sdcc_heap_init not defined. Funktion kann ggf. auch entfernt worden sein im Compiler. Und bei PEEK(x) = (volatile) (unsigned char*)(x) kommt ein Illegal type cast Egal, ich benutze die ältere Version weiter, in Sachen Codegröße tut sich da sowieso nichts.
A. K. schrieb: > Bei vermuteten Compilerfehlern empfiehlt es sich, einen minimierten > Testcase zu bauen, der den Fehler reproduziert. Idealerweise aus wenigen > Zeilen. > > Es liegt auch nahe, den betreffende Code und die Fehlermeldung zu > posten. Ergänzung: Das ganze dann nicht hier posten, sondern als Bugreport bei den sdcc- Entwicklern anliefern: https://sourceforge.net/p/sdcc/bugs/new/ Open Source Software lebt vom Mitmachen. Testen und Bugreporting sind wichtige Formen der Partizipation.
Christian J. schrieb: > Und bei > > PEEK(x) = (volatile) (unsigned char*)(x) > > kommt ein > > Illegal type cast Das ist zwar vmtl. syntaktisch korrektes C, oder war es zumindest mal, aber ich würde dringend abraten, diese Abkürzung von PEEK(x) = (volatile int) (unsigned char*)(x) so wie oben zu verwenden. Missverständnisse sind vorprogrammiert. Sinn ergibt dieser Cast zu (volatile int) ohnehin keinen. Christian J. schrieb: > Auch eine (volatile) > (unsigned char*) Deklaration wurde plötzlich als Fehler gemeldet. Wenn sich hinter PEEK nicht etwas ganz seltsames verbirgt, dann ist das keine Deklaration, sondern eine Zuweisung.
PS: C99 und C11 erlauben kein (volatile). C89 hingegen schon.
Ich hatte seit einiger Zeit an einem besseren Speichermanagement gearbeitet; seit dem 9. Oktober ist es in den Snapshots. Neben den eigentlichen Änderungen wurde auch _sdcc_heap_init umbenannt nach __sdcc_heap_init; da im Assembler noch ein weiterer Unterstrich dazukommt, heißt es dort nun ___sdcc_heap_init statt __sdcc_heap_init. Philipp P.S.: Siehe auch src/device/lib/z80/crt0.s und src/device/lib/z80/heap.s.
Philipp Klaus K. schrieb: > Ich hatte seit einiger Zeit an einem besseren Speichermanagement > gearbeitet; seit dem 9. Oktober ist es in den Snapshots. Neben den > eigentlichen Änderungen wurde auch _sdcc_heap_init umbenannt nach > __sdcc_heap_init; da im Assembler noch ein weiterer Unterstrich > dazukommt, heißt es dort nun ___sdcc_heap_init statt __sdcc_heap_init. Hallo, danke für die Info. Allerdings wird auch auf C99 Einstellung der Ausdruck: #define PEEK(x) (volatile) *((unsigned char *) (x)) nicht mehr kompiliert und erzeugt eine Fehlermeldung
Christian J. schrieb: > Und bei > > PEEK(x) = (volatile) (unsigned char*)(x) > > kommt ein > > Illegal type cast Also bei mir ergibt folgender Code char x; int y; void f(void) { y = (volatile) (unsigned char*)(x); } Die Meldung error 226: no type specifier for '(cast)' wenn mit --std-c99 oder --std-c11 kompiliert wird, und warning 225: no type specifier for '(cast)' wenn mit --std-c89 kompiliert wird. Philipp
Philipp Klaus K. schrieb: > Die Meldung > > error 226: no type specifier for '(cast)' > > wenn mit --std-c99 oder --std-c11 > kompiliert wird, und Genau :-) Und das war vorher eben nicht :-(
PS: Der SDCC ist für den Z80 wie ich meine DAS Werkzeug der Wahl, da - vorausgesetzt man hat genug Zeit mit --max-allocs-per-node 1000000 - das Kompilieren + Linken dauert ca 10 Minuten für 12 Quelldateien - er einen Asm Code erzeugt, der einem Tränen der Freude in die Augen treibt. Besser könnte man es in Assembler sicher auch nicht machen. Das Riesenmanko möchte ich allerdings auch nicht verschweigen: Bindet man Code-Bibliotheken als Quelltexte ein, zb einen ganzen Satz Ausgaberoutinen wie bei Mcurses so wird jede Funktion, ob benutzt oder nicht auch in Asm abgebildet. "Dead Code", der nie aufgerufen wird. Bei komplexen Libs wird es schon schwierig heraus zu finden, welche der 100 Funktionen wirklich aufgerufen werden und welche nicht. Das ist sehr ärgerlich aber eben der Tatsache geschuldet, dass der SDCC ein 1-Pass Compiler ist.
Christian J. schrieb: > PS: > > Der SDCC ist für den Z80 wie ich meine DAS Werkzeug der Wahl, da - > vorausgesetzt man hat genug Zeit mit --max-allocs-per-node 1000000 - das > Kompilieren + Linken dauert ca 10 Minuten für 12 Quelldateien - er > einen Asm Code erzeugt, der einem Tränen der Freude in die Augen treibt. Das klingt für mich jetzt aber doch wenig benutzbar... Meine letzten Z180 Projekte bestanden aus rund 100 Quelldateien und ergaben compiliert gut 256Kb Programmcode. Benutzt hab ich Softools C, damit compiliert das in unter 1 Minute und der Assemblercode war auch nicht so übel. > Das Riesenmanko möchte ich allerdings auch nicht verschweigen: Bindet > man Code-Bibliotheken als Quelltexte ein, zb einen ganzen Satz > Ausgaberoutinen wie bei Mcurses so wird jede Funktion, ob benutzt oder > nicht auch in Asm abgebildet. "Dead Code", der nie aufgerufen wird. Dann compiliere deine Lib-Funktionen doch auch als Library und linke das lib-file in deinem Projekt. Dann sollten auch nur die verwendeten Funktionen eingebunden werden...
Thorsten S. schrieb: > Das klingt für mich jetzt aber doch wenig benutzbar... > Meine letzten Z180 Projekte bestanden aus rund 100 Quelldateien und > ergaben compiliert gut 256Kb Programmcode. Benutzt hab ich Softools C, > damit compiliert das in unter 1 Minute und der Assemblercode war auch > nicht so übel. Wärst Du so nett, bei Gelegenheit die C-Dateien aus http://colecovision.eu/stuff/testbench.tar.gz mit Softtools zu kompilieren, und das Ergebnis (Assemblerlistings, Codegröße der Funktionen) irgendwo hochzuladen? Das ist ein Benchmark aus Funktionen, bei denen SDCC vor Jahren besonders schlecht war. Philipp
Christian J. schrieb: > Das Riesenmanko möchte ich allerdings auch nicht verschweigen: Bindet > man Code-Bibliotheken als Quelltexte ein, zb einen ganzen Satz > Ausgaberoutinen wie bei Mcurses so wird jede Funktion, ob benutzt oder > nicht auch in Asm abgebildet. "Dead Code", der nie aufgerufen wird. Bei > komplexen Libs wird es schon schwierig heraus zu finden, welche der 100 > Funktionen wirklich aufgerufen werden und welche nicht. Toten Code einer Bibliothek zu eliminieren sollte auch nicht die Aufgabe des Programmiers sein. Ich habe das Verhalten auch beobachtet. Da ich Assembler benutzt habe, um Wrapperfunktionen zu realisieren, konnte ich einen Workaround nutzen: Jede Funktion kam in eine eigene Datei:
1 | conio_cgets.s conio_delline.s |
2 | conio_gotoxy.s conio_lowvideo.s |
3 | conio_textcolor.s conio_wherex.s |
1 | .globl _lowvideo |
2 | _lowvideo:: |
3 | ld hl, #COLOR |
4 | set 6, (HL) |
5 | ret |
Damit wurde beim Linken nur das verwendet, was gebraucht wurde. > das > Kompilieren + Linken dauert ca 10 Minuten für 12 Quelldateien Dito. sdcc wird schnell langsam: 90 Sekunden für 10 kByte Kompilat Dirk
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.