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.
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
