sdcc uebersetzt nicht

[Steffen Loley]

Hallo,

der SDCC Version 2.3 übersetzt so weit ganz gut, allerdings scheint der
Linker nicht richtig zu funktionieren. "bit"-Variablen ändern ihren
Wert, das Programm läuft auf einmal nicht mehr, wenn Variablen
hinzugefügt werden...
Ich vermute, dass Variablen an falschen Adressen abgelegt werden und
dann von den Register oder anderen Variablen überschrieben werden, bin
dem aber noch nicht näher nachgegangen.

Statt dessen habe ich den SDCC in der Version 2.4 ausprobiert. Der will
meinen Code aber erst gar nicht übersetzen.
Der komplette Code wird in der Konsole wieder ausgegeben und es wird
eine leere .asm-Datei erzeugt, die lediglich ein paar Kommentare
enthält, an welcher Stelle welche Deklarationen beginnen.
Es stehen aber nur die Kommentare, keine Deklarationen drin.

Weiß jemand was da falsch läuft?

Kennt jemand eine alternative? Kennt jemand einen anderen kostenlosen
C-Compiler für 8051 CPUs, der auch kommerziell eingesetzt werden darf?

Danke!

 

[Gernot Fink]

In article <c7ef63$i8r$1@ngspool-d02.news.aol.com>,
Steffen Loley <no-spam-wanted@gmx.net> writes:

Hallo,

der SDCC Version 2.3 übersetzt so weit ganz gut, allerdings scheint der
Linker nicht richtig zu funktionieren. "bit"-Variablen ändern ihren
Wert, das Programm läuft auf einmal nicht mehr, wenn Variablen
hinzugefügt werden...

Schau mal in das .rst file ob sich bereiche von data und bitvariablen
überschreiben. Eventuell wächst auch der Stack in den Variablenbereich.
Probleme bekommst du vor allem wenn du bitvariablen festen Addressen
zuweist. Diese werden von der automatiscen Speicherbelegung nicht beachtet.

Ich benutze momentan noch 2.3.5 und habe eigendlich kaum Probleme damit.

--
MFG Gernot

 

[Peter Heitzer]

Gernot Fink <G.Fink@gmx.net> wrote:
:>
:> der SDCC Version 2.3 übersetzt so weit ganz gut, allerdings scheint der
:> Linker nicht richtig zu funktionieren. "bit"-Variablen ändern ihren
:> Wert, das Programm läuft auf einmal nicht mehr, wenn Variablen
:> hinzugefügt werden...

: Schau mal in das .rst file ob sich bereiche von data und bitvariablen
: überschreiben. Eventuell wächst auch der Stack in den Variablenbereich.
: Probleme bekommst du vor allem wenn du bitvariablen festen Addressen
: zuweist. Diese werden von der automatiscen Speicherbelegung nicht beachtet.
Du kannst beim Compiler auch einstellen, ob sich die Speicherbereiche
überlappen oder der interne Speicher für deine Daten ausreicht.
Die Voreinstellung ist AFAIK, daß keine Überprüfung stattfindet.
128 Bytes sind nicht gerade üppig, wenn man reichlich lokale Variablen
und Eingangspuffer für den UART verwendet.
Darüberhinaus würde ich dir empfehlen, den Simulator für den 8051 zu
verwenden, sofern du das nicht eh schon machst.

 

[Steffen Loley]

Hallo.

:> der SDCC Version 2.3 übersetzt so weit ganz gut, allerdings scheint der
:> Linker nicht richtig zu funktionieren. "bit"-Variablen ändern ihren
:> Wert, das Programm läuft auf einmal nicht mehr, wenn Variablen
:> hinzugefügt werden...

: Schau mal in das .rst file ob sich bereiche von data und bitvariablen
: überschreiben. Eventuell wächst auch der Stack in den Variablenbereich.
: Probleme bekommst du vor allem wenn du bitvariablen festen Addressen
: zuweist. Diese werden von der automatiscen Speicherbelegung nicht beachtet.

Jupp, der DATA-Bereich ist voll, da sind for allem viele Parameter, die
Platzbeanspruchen... Ich packe also ein paar Parameter auf den Stack und
weiche auf die ober 128 Byte und den (langsameren) externen Speicher aus.
Das sollte dann wieder laufen...

Du kannst beim Compiler auch einstellen, ob sich die Speicherbereiche
überlappen oder der interne Speicher für deine Daten ausreicht.
Die Voreinstellung ist AFAIK, daß keine Überprüfung stattfindet.

Die Bit Variablen stehen laut .rst-Datei ab Adresse 0000. Ich bin mir
nicht sicher, ob Bit-Adressen anders interpretiert werden müssen, aber
wenn nicht werden damit meine Register überschrieben - und umgekehrt.
Das wäre blöd...
Leider ist der Parameter für die Platzierung der Bit-Adressen laut Doku
noch nicht implementiert... Die in der Doku gennante alternative, der
Parameter für den Linker, funktioniert leider auch nicht.

Gibt es eigentlich einen Parameter, der einem nach der Überstetzung ein
paar Zahlen zur Speichernutzung auf den Bildschirm zaubert?

 

[Steffen Loley]

Hallo.

Statt dessen habe ich den SDCC in der Version 2.4 ausprobiert. Der will
meinen Code aber erst gar nicht übersetzen.
Der komplette Code wird in der Konsole wieder ausgegeben und es wird
eine leere .asm-Datei erzeugt, die lediglich ein paar Kommentare
enthält, an welcher Stelle welche Deklarationen beginnen.
Es stehen aber nur die Kommentare, keine Deklarationen drin.

Ich habe nun raus gefunden, dass der sdcc unter WinXP auf meinem Laptop
einwandfrei läuft, die gleiche Version auf meinem PC und Win98 aber
Probleme macht.

Irgendeine Ahnung?

 

[Steffen Loley]

Hallo.

Ich benutze momentan noch 2.3.5 und habe eigendlich kaum Probleme damit.

Wo gibt es den?
Im Netz finde ich nur 2.3.0 und 2.4.0.

 

[Gernot Fink]

In article <c7fofn$kjj$2@ngspool-d02.news.aol.com>,
Steffen Loley <no-spam-wanted@gmx.net> writes:

Hallo.

Ich benutze momentan noch 2.3.5 und habe eigendlich kaum Probleme damit.

Wo gibt es den?
Im Netz finde ich nur 2.3.0 und 2.4.0.

Die haben ganz schön aufgeräumt. Ich find ihn ausch nicht mehr.
Hier hab inch nur die linuxversion.

--
MFG Gernot

 

[Gernot Fink]

In article <c7fo3b$k3k$1@ngspool-d02.news.aol.com>,
Steffen Loley <no-spam-wanted@gmx.net> writes:

Hallo.

Jupp, der DATA-Bereich ist voll, da sind for allem viele Parameter, die
Platzbeanspruchen... Ich packe also ein paar Parameter auf den Stack und
weiche auf die ober 128 Byte und den (langsameren) externen Speicher aus.
Das sollte dann wieder laufen...

Du kannst beim Compiler auch einstellen, ob sich die Speicherbereiche
überlappen oder der interne Speicher für deine Daten ausreicht.
Die Voreinstellung ist AFAIK, daß keine Überprüfung stattfindet.

Die Bit Variablen stehen laut .rst-Datei ab Adresse 0000. Ich bin mir
nicht sicher, ob Bit-Adressen anders interpretiert werden müssen, aber
wenn nicht werden damit meine Register überschrieben - und umgekehrt.
Das wäre blöd...

Das ist richtig. Beim 8051 beginnt bit 0 bei Ramaddresse 0x20.
Die 4 Registerbänke liegen von 0x00 bis 0x1f, also kein Problen.

Die Daten dürfen erst danach beginnen.
Bei 9 bitvariablen darf der Datenbereich also erst bei 0x22 beginnen.

2.3.5 macht das automatisch. Bei 2.3.0 bin ich mir nicht sicher.

Die lücke die dadurch entsteht falls du nicht alle 4 Registerbänke
benutzt, kannst du notfalls direkt Addressieren.

Der Stack darf erst nach den als idata deklarierten Variablen beginnen
falls nach data kein platz ist.

Leider ist der Parameter für die Platzierung der Bit-Adressen laut Doku
noch nicht implementiert... Die in der Doku gennante alternative, der
Parameter für den Linker, funktioniert leider auch nicht

Die startaddresse kannst du mit --data-loc festlegen.

Gibt es eigentlich einen Parameter, der einem nach der Überstetzung ein
paar Zahlen zur Speichernutzung auf den Bildschirm zaubert?

Das steht sehr ausführlich ind cryptsch in *.map und *.mem

Bei 2.3.0 bin ich mir aber dabei auch nicht sicher

Bei 2.3.5 sieht das so aus:
Direct Internal RAM:
Name Start End Size Max
---------------- -------- -------- -------- --------
REG_BANK_0 0x00 0x07 8 8
REG_BANK_1 0x08 0x0f 8 8
REG_BANK_2 0x10 0 8
REG_BANK_3 0x18 0 8
BSEG_BYTES 0x20 0x23 4 16
DATA 0x24 0x54 49 128
---------------- -------- -------- -------- --------
TOTAL: 0x00 0x54 69 128

Stack starts at: 0x55 (sp set to 0x54) with 43 bytes available

Other memory:
Name Start End Size Max
---------------- -------- -------- -------- --------
INDIRECT RAM 0x80 0xae 47 128
EXTERNAL RAM 0x0000 0 65536
ROM/EPROM/FLASH 0x0000 0x0ca7 3240 65536


--
MFG Gernot

 

[Steffen Loley]

Hallo.

Der Stack darf erst nach den als idata deklarierten Variablen beginnen
falls nach data kein platz ist.

Der war vorher bei Adresse 0x07. Ich habe ihn nun ans Ende gepackt und
es läuft jetzt.
Danke!