SDCC 3.6.0 RC1

Jens schrieb:
> Welche neuen Features darf man denn bei 3.6 erwarten?
> Bei welchen Architekturen hat sich was getan?
> Irgendwie habe ich das ChangeLog nicht gefunden...
>
> Jens

Das volle Changelog gibe es in den Quellen:
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/ChangeLog
Aber das ist halt sehr lang, weil da jeder kleine Bugfix auftaucht.
Eine Übersicht der wichtigsten Änderungen seit 3.5.0 findet sich unten 
auf http://sdcc.sourceforge.net/mediawiki/index.php/SDCC_3.6.0_Release

Philipp

Ich hab jetzt ein Problem (CC2541->MCS51) beim SDCC 3.6.0 festgestellt, 
welches beim 3.5.0 nicht vorhanden war. Aus

1

while(SEMAPHORE_0==0){};

entsteht im Listing:

1

    00003E                       1144 00101$:

2

    00003E 90 61 8A         [24] 1145   mov  dptr,#_SEMAPHORE_0

3

    000041 E0               [24] 1146   movx  a,@dptr

4

    000042 E0               [24] 1147   movx  a,@dptr

5

    000043 60 F9            [24] 1148   jz  00101$

Da bei MOVX kein Flag gesetzt wird, kann das Ganze m.E. nicht richtig 
funktionieren.

Jörg

Stimmt, das ist mir in dem Moment nicht eingefallen. Das Problem scheint 
wohl eine andere Ursache zu haben und hier muss ich erst mal ein 
Testprogramm schreiben. Denn derzeit werden fast alle Unterfunktionen 
durch eine Bibliothek bereitgestellt und nur dazugelinkt.

Momentan bin ich wieder auf 3.5.0 zurück gewechselt, da habe ich das 
Problem nicht.

Jörg

Joerg W. schrieb:
> Das Problem scheint
> wohl eine andere Ursache zu haben

Weißt Du schon genaueres?

Philipp

Ich hatte es inzwischen ein bisschen aus den Augen verloren, aber heute 
früh kam mir dann die "Erleuchtung". Ich hab dazu ein kleines 
Testprogramm geschrieben. Und es liegt doch an dem doppelten "movx 
a,@dptr".

1

                                   1189 ;  src/main.c:18: while(SEMAPHORE_0 == 0);

2

      00005F                       1190 00101$:

3

      00005F 90 61 8A         [24] 1191   mov  dptr,#_SEMAPHORE_0

4

      000062 E0               [24] 1192   movx  a,@dptr

5

      000063 E0               [24] 1193   movx  a,@dptr

6

      000064 60 F9            [24] 1194   jz  00101$

Die Semaphoren gehen nach "0", wenn man sie bei "1" liest, Durch das 
doppelte Lesen geht aber die "1" vom ersten Lesen verloren und 
"while(SEMAPHORE_0 == 0);" landet immer in einer Endlosschleife. Der 
SDCC3.5.0 macht an der Stelle:

1

                                   1190 ;  src/main.c:18: while(SEMAPHORE_0 == 0);

2

      00005F                       1191 00101$:

3

      00005F 90 61 8A         [24] 1192   mov  dptr,#_SEMAPHORE_0

4

      000062 E0               [24] 1193   movx  a,@dptr

5

      000063 FF               [12] 1194   mov  r7,a

6

      000064 60 F9            [24] 1195   jz  00101$

Hier wird nur einmal gelesen was ja OK ist.

Bei anderen Registern macht das doppelte Lesen nichts aus, bei den 
Semaphoren aber schon.

Jörg

Wie ist SEMAPHORE_0 deklariert?
Hättest Du noch ein kompilierbares Minimalbeispiel, bei dem das Problem 
sichtbar ist?

Philipp

SEMAPHORE_0 ist als __xdata volatile unsigned char deklariert. Anbei das 
Beispiel, das Makefile muss halt noch an die richtige Toolchain 
angepasst werden. Die while-Schleife steht bei mir normalerweise am 
Anfang der Radio-Initialisierung.


Jörg

Mit SDCC 3.6.0 konnte ich das Problem reproduzieren.
Ich meine mich erinnern, das so etwas ähnliches vor ein paar Monaten 
schon 'mal irgendwo (eine der SDCC-Mailinglisten?) auftauchte, und 
behoben wurde.
In aktuellen Entwicklerversionen (3.6.4 #9802 und 3.6.4 #9811 die ich 
eh' gerade da hatte), ist der generierte Code zwar auch nicht unbedingt 
schön, aber immerhin korrekt.
Damit wird das Problem wohl auch in SDCC 3.7.0 nicht wieder auftauchen.

Philipp

Nop schrieb:
> Christian J. schrieb:
>
>> sag mll Philipp, wieso habt ihr die Datentypen bei putchar und getchar
>> jetzt auf int gesetzt?
>
> Vermutlich, weil das mit der C-Standardlibrary dann auch übereinstimmt.
> Die hat dort deswegen int und nicht char, weil man dann auch Sachen wie
> EOF oder sonstige Fehler zurückbekommen kann. Mit char ginge das nicht,
> weil alle Werte von 0-255 ja gültige Datenwerte sind.

So ist es. Oder wie ich für die Release Notes geschrieben habe: "Changed 
putchar() prototype from void putchar(char) to int putchar(int) to 
improve standard-compliance and allow error reporting." 
(http://sdcc.sourceforge.net/mediawiki/index.php/SDCC_3.7.0_Release).

> es ist halt ärgerlich wenn bei jeder neuen Version immer wieder neue
> Komplierfehler auftauchen, die vorher nicht da waren.

> gruss,
> Christian

Die alte Situation, in der die Kompilierfehler bei standardkonformem 
Code auftraten war aber noch unschöner.

Philipp

Christian J. schrieb:
> @Philipp:
>
> Hast Du evtl noch eine Version vom sdcc von 2015 ? Wo alles noch so war
> wie als ich das Projekt angefangen habe? Also Also void putchar (char)
> und nur 1 Unterstrich bei Heap Global?
>
> Ich glaube damit werde ich glücklicher, es funktionierte ja schliesslich
> auch.
> Aktuell ärger ich mch nur herum 4 ganze Projekte irgendwie wieder ans
> Laufen zu bekommen. Habe leider keine in den snapshots mehr gefunden,
> die sind alle neu.
>
> Gruss,
> Christian

3.5.0 ist von 2015.

Als Quellen hier:

https://sourceforge.net/projects/sdcc/files/sdcc/3.5.0/

Binärdateien für diverse Systeme mit ein paar weiteren Klicks von:

https://sourceforge.net/projects/sdcc/files/

Philipp

Christian J. schrieb:
> Philiiiiiiip........
>
> habt ihr schon wieder am sdcc rumgespielt? Naa...... ?
>
> Aslink Warning-Undefined Global ::sdcc_heap_init referened by module
> crt0

Das war aber schon im  Oktober 2015. Aus den Release Notes von 3.6.0:
"New memory management with lower overhead".

Um die Größe des Heap für z80 auf etwas anderes als 1KB zu ändern: 
heap.s anpassen und dazulinken. In der crt0 findet sich nun nichts mehr 
zum Heap.

Philipp

Christian J. schrieb:
> Hier steht was davon, dass der GCC für Z80 portiert werden soll,

Die Chance, dass der gcc jemals ein Z80-Backend bekommen wird, schätze 
ich als äußerst gering ein. Für den LLVM stehen die Chancen ein wenig 
besser, siehe z.B. 
https://olduino.wordpress.com/2014/12/30/llvm-for-the-z80-another-source-of-inspiration/

Aber ob diese Backends jemals die Reife vom SDCC erreichen, hängt davon 
ab, ob die Retro-Welle lange genug anhält. ;-)

Christian J. schrieb:
> Wäre es programmtechnisch möglich, dass der SDCC auch mehrere Cores
> nutzt, so wie der GCC auch?

Das ist nicht so einfach, wie du dir das vorstellst... und davon 
abgesehen für die meisten Anwendungsfälle sinnfrei.

Mir wäre es neu, dass der gcc mehrere Kerne nutzt. Üblicherweise besteht 
ein Projekt nämlich aus mehreren Dateien, und "make" ist in der Lage, 
automatisch mehrere Compilerinstanzen parallel laufen zu lassen.

Aber dazu müsste man sich ja in die verwendete Technologie einarbeiten, 
was du ja gerne und lautstark vermeidest.

Christian J. schrieb:
> Wäre es programmtechnisch möglich, [… dass …] ihr es irgendwie
> hinkriegt, dass er nicht benutzten Code auch eliminiert?

Da sind 3 Fälle zu unterscheiden:

1) Ungenutzer Code in Funktionen, wo sich ohne Kenntnis der anderen 
Funktionen erkennen lässt, dass der Code ungenutzt ist. Das ist die 
klassische Dead Code Elimination, die der SDCC beherrscht (aber 
natürlich ließe sich die noch effektiver machen, z.B. durch bessere 
Zeigeranalyse oder durch Intervallanalyse).

2) Nicht aufgerufene Funktionen, die static oder inline (aber nicht 
inline und extern zugleich) sind. Das erfordert zwar deutliche 
Änderungen im Compiler, ist aber vorgesehen (aber erst für irgendwann 
nach SDCC 3.7.0). Siehe auch den Thread "Keeping functions (and maybe 
other things) 'to be emitted later'? Multiple passes?" auf sdcc-devel.

3) Andere nicht aufgerufene Funktionen. Das erfordert Änderungen an 
Compiler und Linker. Das ist etwas, das wir zwar gern hätten, allerdings 
gibt es erstmal zuviel wichtigeres zu tun, so dass es wohl länger dauern 
wird.
Es gibt hier allerdings einen Workaround: Wenn alle Funktionen in 
einer.rel nicht aufgerufen werden, und die .rel zuerst in eine 
Bibliothek eingebunden wird, und dann die Bibliothek zum Rest des 
Programms gelinkt wird, funktioniert es schon. Wenn man also die 
Fuktione sinnvoll gruppert auf C-Dateien aufteilt, lässt sich das 
Gewünschte erzielen. Di Standardbibliothek ist z.B. so aufgeteilt, und 
somit werden nur die wirklich benötigten Teile der Standardbibliothek 
eingebunden.

Philipp

Christian J. schrieb:

> Mir ist zb aufgefallen, dass keine Elimination ganz kleiner Funktionen
> stattfindet, sondern dass wirklich stur jede Funktion mit Call und
> Registersicherung abgearbeitet wird, auch wenn sie nur 3 Befehle
> enthält.

Zu entscheiden, dass in solchen Fällen die durch inline-Ersetzung 
wegoptimiert werden, wäre Aufgabe der inlining-Heuristik. Die von GCC 
würde das machen.
Und auch für den SDCC ist es vorgeshen, so etwas (also eine 
inlining-Heuristik, die inline-Ersetzung beim Aufruf sehr kleiner 
Funktionen vornimmt) nach 3.7.0 zu implementieren. Auch dafür werden die 
in "Keeping functions (and maybe
other things) 'to be emitted later'? Multiple passes?" besprochenen 
Änderungen gebraucht.

Zur Zeit berücksichtigt die inlining-Heuristik in SDCC die Größe der 
aufgerufenen Funktionen nicht:

inline-Ersetzung von Funktionsaufrufen in SDCC findet genau dann statt, 
wenn der Funktionsaufruf nicht über Funktionszeiger erfolgt, die 
Funktion eine feste Anzahl an Argumenten hat, und die Funktion mit dem 
Schlüsselwort inline definiert ist.

Philipp

Christian J. schrieb:
> Hallo,
>
> ist das normal, dass so eine Funktion vom Compiler nicht eleminiert
> wird? Im Asm Code finde ich trotz maximaler Optimierung ständig Aufrufe
> der "eingepackten" Funktion. Dabei wäre es doch einfach die umgebenden
> Verpackung komplett weg zu lassen. Die ist nur aus Gründen der
> Übersichtlichkeit da.
>
> static void mcurses_putc (uint8_t ch)
> {
>     putchar (ch);
> }
>
>  4E42                     104 _mcurses_putc:
>                             105 ;mcurses.c:70: putchar (ch);
>    4E42 21 02 00      [10]  106   ld  hl, #2+0
>    4E45 39            [11]  107   add  hl, sp
>    4E46 7E            [ 7]  108   ld  a, (hl)
>    4E47 F5            [11]  109   push  af
>    4E48 33            [ 6]  110   inc  sp
>    4E49 CD 7A 43      [17]  111   call  _putchar
>    4E4C 33            [ 6]  112   inc  sp
>    4E4D C9            [10]  113   ret

Irgendwann nach 3.7.0 soll das automatisch optimiert werden. Zur Zeit 
klappt es nur, wenn da (statt oder zusätzlich zu "static") auch "inline" 
steht.

Philipp

Christian J. schrieb:
> Hi,
>
> ok. Kann ich also im Startup alles weglassen was den Heap betrifft und
> er ist dann 1kg gross?

Das sollte gehen; der Heap wäre dann 1 KB groß.

Philipp