Warum Keil (oder andere unfreie Compiler) statt SDCC?

Zu den Gründen könnte gehören, daß mehr als nur ein Compiler benötigt 
wird, sondern auch eine Debugunterstützung. PICs beispielsweise kann man 
mit dem Microchip Studio beglücken, und da funktionieren PicKit, Mplab 
Snap etc. als Programmier- und Debuginterfaces.

Und wenn so eine Entwicklungsumgebung eines Herstellers eh' schon 
verwendet wird, und nur eine neue Architektur hinzukommt, muss der 
Nutzer sich nicht umstellen. Microchip Studio (um beim Beispiel zu 
bleiben) kann eben als Nachfolger des Atmel Studio nicht nur AVRs, 
sondern auch PICs und Atmel-ARM (SAMDirgendwas) programmieren.

Für AVRs steckt da ein avrgcc drin, aber es gibt auch den 
microchipeigenen XC8 als Compiler (der ohne zusätzliche Lizenz nur 
eingeschränkt, d.h. ohne Optimierung verwendbar ist).

In manchen Entwicklungsszenarien ist eine Zertifizierung nach 
irgendwelchen Richtlinien erforderlich (MISRA, kann wohl von IAR geboten 
werden).

Es gibt also eine ganze Latte von Gründen-

DerEgon schrieb:
> In manchen Entwicklungsszenarien ist eine Zertifizierung nach
> irgendwelchen Richtlinien erforderlich (MISRA, kann wohl von IAR geboten
> werden).

Das dürfte in der Industrie ein Hauptgrund sein. Gegenüber den 
Personalkosten spielen die Lizenzkosten keine ernsthafte Rolle. Ein 
Compiler bzw. eine Ganze IDE mit "Stempel drauf" und integrierten Checks 
schon.
Wir haben mal für den AVR den gcc Assebmler-Output gegenüber IAR AVR 
verglichen, und uns dann ganz schnell für den IAR entschieden (okay 
schon eine Weile her, das war 2012).
Entscheidend dürfte für die meisten professionellen Benutzer sein, ob 
der Compiler/IDE-Hersteller einen "Guten Draht" zum 
µC-Hersteller/Designer hat, und so möglichst schnell und gut die 
Fähigkeiten oder Beschränkungen eines µC´s (oder einer Architektur) 
auszunutzen.

Gruß

SDCC:
Schon die Dokumentation der Installation ist lückenhaft.
Er erfordert viele zu setzende Umgebungsvariable.
Die muss man "raten" und den Inhalt auch.
Welche Teile des Compilers und der Binuteils wohin gehören
ist das nächste Ratespiel.

Ich musste vor vielen Jahren MSC5 von Hand installieren,
weil der Installer mit der speziellen Grafikkarte nicht konnte.
Selbst das ging wesentlich einfacher.

Philipp Klaus K. schrieb:
> die vom Small Device C Compiler (SDCC) unterstützt werden

Wir hatten doch hier mal über die fehlende Eclipse Integration 
gesprochen.

FTDI hatte ja einen Versuch gemacht, das Ergebnis war aber nicht 
optimal, und inzwischen haben die ja aufgegeben:

https://www.ftdichip.com/old2020/Products/ICs/FT51.html

Silabs hat ja die Vereinbarung mit ARM/Keil für die kostenfreie Nutzung, 
dennoch gab es einen Versuch mit Eclipse/Simplicity Studio und sdcc, 
läuft aber bis Stand heute nicht:

https://community.silabs.com/s/question/0D51M00007xeGALSA2/add-the-sdcc-compiler-to-simplicity-studio

sdcc mag besser sein als Keil, aber wenn man dafür nicht aus 
Eclipse/Simplicity Studio flashen/debuggen kann, und mit HEX Datei und 
Bootloader anrücken muss ...

Philipp Klaus K. schrieb:
> Meiner Meinung nach ist nun mittelfristig der aussichtsreichste Weg,
> SDCC konkurrenzfähiger gegenüber nichtfreien Compilern zu machen:

So, nun ist deine Katze aus dem Sack. Hättes es auch gleich sagen 
können.

Man kann das auch kürzer sagen: der SDCC müßte in allen Punkten besser 
werden, um mitspielen zu können.

Ich hatte sowas ähnliches vor Jahren mit dem GCC bei der Lernbetty 
gemerkt. Im Vergleich zum Keil ist der GCC weitaus hakeliger in der 
Benutzung, kann weniger, ist stellenweise inkompatibel zum Standard 
(__irq und keine Pragmas Arm<-->Thumb) ist unverschämt (kürzt Schleifen, 
die ICH geschrieben habe einfach weg), ist teilweise buggy (Problem 
.thumb versus .thumbfunc) und machte dennoch einen umfänglicheren und 
zugleich langsameren Maschinencode. Der einzige Pluspunkt ist der 
fehlende Preis, was eigentlich nur für private Bastler wichtig ist. Er 
hat dennoch seine Berechtigung, denn es heißt "besser schlecht gefahren 
als gut gelaufen". So ähnlich sehe ich das auch beim SDCC.

W.S.

W.S. schrieb:
> ist unverschämt (kürzt Schleifen,
> die ICH geschrieben habe einfach weg)

Das liegt an Deinen bekanntermaßen dürftigen C-Kenntnissen - nicht am 
Compiler.

Nop schrieb:
> Das liegt an Deinen bekanntermaßen dürftigen C-Kenntnissen - nicht am
> Compiler.

Und du meinst, ein Compiler darf meine Kenntnisse über irgend etwas 
abfragen und wenn es ihm nicht paßt, mir einfach mein Geschriebenes 
wegstreichen? Nö, sowas akzeptiere ich nicht. Der Keil macht solche 
Faxen übrigens nicht. Und der FCC911 übrigens auch nicht. Das ist der 
für die Fujitsus. Seltsam, gelle? Ich sehe auch dieses Detail anders als 
du, nämlich daß du und viele andere zu sehr an den GCC gewöhnt sind und 
nun alles andere für Geisterfahrer halten. So herum.

W.S.

W.S. schrieb:

> Und du meinst, ein Compiler darf meine Kenntnisse über irgend etwas
> abfragen und wenn es ihm nicht paßt, mir einfach mein Geschriebenes
> wegstreichen?

Ein C-Compiler darf (nicht: muß!) Dinge unter der as-if-Regel streichen, 
wie das im C-Standard vorgesehen ist. Wenn Du den C-Standard nicht 
kennst, d.h. Du kannst kein C, ist das Dein Problem und nicht das des 
Compilers.

Er fragt keine Kenntnisse ab, sonder setzt das Verhalten um, was ihm in 
der Programmiersprache beschrieben wurde. Da es kein C–Keyword für 
„Warte mal kurz“ gibt, stellt er fest das die Schleife keine Änderung am 
Programmzustand hervorruft und genau das übersetzt er dann dann in ein 
„don‘t execute anything“. Und das so schnell wie irgend möglich.

Es gibt in C auch die Möglichkeit zu erklären, das da was passiert, was 
der Compiler nicht sieht (volatile) und dann respektiert er das. Nur 
hinschreiben muß es der Programmierer.

Philipp Klaus K. schrieb:
> nichtfreie Compiler ... einsetzen.

Ist das nicht die gleiche Frage wie Linux/Windows, Libre/MS, Gimp/PS 
etc?

Also Total_Cost_of_Ownership, Killerfeatures, Ausfallrisiko, 
Integration, Kundenanforderungen, Gewohnheit, Schmiergeld (Seminare 
etc.), ... nicht unbedingt in der Reihenfolge.

Gcc schrieb:
> Er fragt keine Kenntnisse ab, sonder

Gcc schrieb:
> Er fragt keine Kenntnisse ab, sonder...

Das ist mir klar, diese Bemerkung war auch nur zum Zwecke der 
Vedeutlichung.
Um es mal klar zu sagen: von einem Compiler erwarte ich, daß er das, was 
ich haben will, optimal von der Sprache der Notation in entsprechenden 
Maschinencode übersetzt, aber NICHT, daß er an meinem Geschriebenen 
herum mäkelt und nur dann, wenn es im Sinne seiner Programmierer ist, 
das Zeug übersetzt.

Wenn das nicht gegeben ist, dann ist so ein Compiler nicht geeignet für 
alle Firmware, die in irgend einer Weise mit Hardware zu tun hat. Und 
ein Standard, der derartige Eigenmächtigkeiten sanktioniert, taugt nur 
für die Tonne.

Aber zurück zum Thema, was man besser "warum nehmen die Leute nicht NUR 
den SDCC?" hätte nennen können. Der Philipp schrieb:
> 0) Verbesserte maschinenunabhängige Optimierungen
> 1) Verbesserte maschinenabhängige Optimierungen für mcs51
> 2) Bessere Debugunterstützung und Integration
> 3) Finden und Beheben von Bugs.

Tja, ist das nicht alles, wenn die Rede ist von einem Compiler?
Also, was denn sonst noch - außer Pillepalle?

W.S.

W.S. schrieb:
> Um es mal klar zu sagen: von einem Compiler erwarte ich, daß er das, was
> ich haben will, optimal von der Sprache der Notation in entsprechenden
> Maschinencode übersetzt,

Soweit, so schön. Das macht annähernd jeder Compiler so, sofern er 
nicht irgendwas zusammengefrickeles aus dem 1. Semester der 
Informatik-Vorlesung ist.

> aber NICHT, daß er an meinem Geschriebenen herum mäkelt

Dann schalte halt alle Warnungen aus, wenn Du zu blöd bist, C 
programmieren lernen zu wollen. Leb' dann aber auch mit den Ergebnissen, 
ohne rumzuheulen.

> und nur dann, wenn es im Sinne seiner Programmierer ist,
> das Zeug übersetzt.

Das ist drollig: Ein standardkonformer C-Compiler, der den Code (oder 
Kot?) des Lernbetty-Großmeisters nicht so übersetzen will, wie es der 
Herr Großmeister will, wird abgelehnt.

Wielange dauert es eigentlich noch, bis Du a) entweder C programmieren 
lernst oder b) Dich anderen Dingen zuwendest?

Jörg W. schrieb:
> W.S. schrieb:
>> Um es mal klar zu sagen: von einem Compiler erwarte ich, daß er das, was
>> ich haben will, optimal von der Sprache der Notation in entsprechenden
>> Maschinencode übersetzt
>
> Genau das macht ein Compiler übrigens, wenn er
> 1  for (int i = 0; i < 10000; i++)
> 2  { /* nothing */ }
>
> zu nichts übersetzt,
Der Compiler meint, daß es nichts sein soll. Man könnte so etwas als 
eine Art Verzögerung einsetzen, da jeder Befehl eine bestimmte Anzahl 
von Taktzyklen benötigt. Ob das am Ende guter Programmierstil ist sei 
mal dahin gestellt, aber es würde vom Prinzip her funktionieren.

Vielleicht könnte der W.S. einfach mal ein Beispiel bringen.

Wer C programmieren kann, wüsste, wozu "volatile" verwendet werden kann.

Wer sich hingegen weigert, dem hilft auch keine "Lernbetty".

S. R. schrieb:
> Der W.S. könnte auch einfach in C programmieren anstatt in einer
> Programmiersprache, die nur so aussieht wie C. Das ist nämlich das
> eigentliche Problem.
Wenn Du meinst.

Betty hilft auch hier nicht weiter schrieb:
> Wer C programmieren kann, wüsste, wozu "volatile" verwendet werden kann.
>
> Wer sich hingegen weigert, dem hilft auch keine "Lernbetty".
Man muß ja mit W.S. nicht immer einer Meinung sein und in manchen Dingen 
ist er sicher auch etwas speziell. Dennoch kann man sich ja auch das was 
er z.B. mit der Lernbetty verbrochen hat ansehen. Ich habe das vor ein 
paar Jahren mal getan und mir das ganze Betty Geraffel herunter geladen. 
Es hat so funktioniert wie er es beschrieben hat - völlig problemlos vom 
Compilieren der Quellen, Übertragen des Compilats auf die Betty und die 
Funktion selbst. Also für einen der kein C kann nicht ganz schlecht. Die 
Dokumentation zu seinem Projekt ist auch nicht schlecht gemacht, die 
Mehrzahl solcher Projektdokumentationen, wenn es denn überhaupt welche 
gibt, ist deutlich schlechter.

Ansonsten stell doch mal selbst ein solches Projekt auf die Beine und 
beweise wie man es besser macht. Deine 2 Post in diesem Thread sind 
bisher nur unqualifiziertes Geblöke ohne jegliche Substanz.

Jörg W. schrieb:
> Es gibt aber in C keinen "Befehl", und es gibt auch keine
> vorgeschriebenen Mindestausführungszeiten. Das würde letztlich der
> Forderung nach möglichst optimaler Umsetzung des aufgeschriebenen Codes
> zuwider laufen.
Ach Jörg, jetzt hör mal mit dieser Erbsenzählerei auf, Du bist 
intelligent genug um zu wissen worauf ich hinaus wollte. Ob man das nun 
Befehl, Anweisung oder wie auch immer benennt ist am Ende doch völlig 
Rille. Schlußendendlich macht der Compiler am Ende daraus eine Folge von 
Instruktionen für die CPU die entsprechend umgesetzt werden. Für ein i++ 
sind nun mal eine bestimmte Anzahl von Taktschritten erforderlich um 
dies umzusetzen, am Ende wird die weitere Befehlsausführung um genau die 
Zeit die für die Ausführung erforderlich ist verzögert. Es könnte also 
durchaus sein, das sich der Programmierer was dabei gedacht hat und 
insofern wäre es schon wünschenswert, wenn der Compiler das umsetzt was 
man hinschreibt, zumindest solange es sich um erlaubte Codesequenzen 
handelt. Der Compiler kann ja in solch einem Fall eine Warnung ausgeben 
und es dem Programmierer überlassen ob er es denn so stehen lassen will.

Zeno schrieb:
> Für ein i++
> sind nun mal eine bestimmte Anzahl von Taktschritten erforderlich

So funktioniert C ganz grundsätzlich nicht. Deswegen kann man das von 
einem C-Compiler auch nicht erwarten.

> Es könnte also
> durchaus sein, das sich der Programmierer was dabei gedacht hat

Dann hätte er "volatile" hinschreiben sollen. Wenn er das so wie W.S. 
nicht weiß, hätte er vorher C lernen sollen.

> insofern wäre es schon wünschenswert, wenn der Compiler das umsetzt was
> man hinschreibt

Nein. Nochmal, so funktioniert C nicht.

Jörg W. schrieb:
> Wie Philipp schon schreibt: oft genug hat der Programmierer das nicht so
> direkt hingeschrieben, sondern es versteckt sich innerhalb von irgendwas
> anderem. Wenn du 'i = i * 2' schreibst, erwartest du ja auch nicht, dass
> dann der (bei Fehlen von Multiplikationsbefehlen in der CPU in einer
> Bibliothek sitzende) Code für eine Multiplikation mit 2 ausgeführt wird,
> wenn der Compiler eigentlich auch feststellen kann, dass er stattdessen
> viel einfacher nur ein Bit nach links schieben muss.
Jörg ich habe den Eindruck Du willst micht nicht verstehen und Dein 
Vergleich hinkt auch.
Mir ist es völlig wurscht wie der Compiler 'i = i * 2' umsetzt. Ob er 
dafür eine in der CPU evtl. vorhandene Multiplikationsinstruktion 
benutzt oder einfach nur ein Bit nach links schiebt ist mir in diesem 
Zusammenhang völlig egal. Ich erwarte schlichtweg das er den von mir 
hingeschriebenen Quelltext, solange er gültigen Code darstellt, in 
ausführbare Instruktionen für die CPU umsetzt, aber nicht entscheidet 
das der hingeschriebene Code eigentlich, nach seiner Ansicht, 
überflüssig ist und ihn deswegen einfach weg läßt. Der richtige Weg 
wäre, daß er mir in so einem Fall mitteilt das ich diese Codesequenz 
nochmals überdenken solle.
Compiler für andere Sprachen handhaben das anders und akzeptieren das 
was der Programmierer hin schreibt.
Ich merke aber schon, das ich hier gegen Windmühlen kämpfe und die 
Fangemeinde dieses Verhalten toll findet und lieber volatile 
hinschreibt, um dem Compiler zu sage, mache es so wie ich es 
hingeschrieben habe. So wird halt jeder auf seine Art glücklich. Mich 
piept so etwas an und genau deshalb meide ich C wo es nur geht, aber 
leider führt bei µC oftmals kein Weg daran vorbei.

Εrnst B. schrieb:
> Die Warnung kannst du ja ganz leicht nachrüsten.
> Einfach im Build-System zweimal kompilieren lassen, einmal mit -O0,
> einmal mit -Os,-O2,-O3...
> Dann die ausgeworfen Binaries vergleichen. Falls unterschiedlich:
> "Warnung: Compiler hat optimiert!"
Du hast ja nun mal gar nicht verstanden worum es mir geht - macht aber 
nichts.

Nop schrieb:
> So funktioniert C ganz grundsätzlich nicht. Deswegen kann man das von
> einem C-Compiler auch nicht erwarten.
> ...
Ja und genau deswegen fallen viele Anfänger erst mal so richtig auf die 
Fresse.

Εrnst B. schrieb:
> Ich hab mich nur darüber Lustig gemacht.
Also wieder mal die typische Arroganz der eingefleischten 
C-Programmierer, die brauchen das ganz offensichtlich.

Zeno schrieb:

> Ja und genau deswegen fallen viele Anfänger erst mal so richtig auf die
> Fresse.

Oh. Eine Programmiersprache muß man tatsächlich lernen. Unglaublich, das 
ist ja fast wie im richtigen Leben.

Zeno schrieb:

> Ich merke aber schon, das ich hier gegen Windmühlen kämpfe und die
> Fangemeinde dieses Verhalten toll findet und lieber volatile
> hinschreibt

Ja, natürlich. Die Freiheit, die der Compiler ganz absichtlich hat, 
erlaubt ihm nämlich überhaupt erst etliche Optimierungen. Ob er die 
Variable im Register hält oder auf dem Stack etwa - und beides wird die 
Zeit so oder so erheblich beeinflussen. Genau dafür ist die as-if-Regel 
da. Ganz einfach.

Das hat nichts mit "lieber volatile hinschreiben" zu tun, sondern damit, 
daß auch Du auf einem ganz grundlegenden Level nicht verstehst, was C 
überhaupt ist.

Jörg W. schrieb:

> Dann darfst du ihn halt nicht optimieren lassen, -O0 als Option.

Das ist allerdings Compiler-spezifisch, der C-Standard selber sieht 
derlei nicht vor. Prinzipiell dürfte ein C-Compiler also auch bei 
abgeschalteten Optimierungen solche Leerschleifen rauswerfen. Wenn der 
Code mit Optimierungen kaputt ist, dann ist es es nämlich auch ohne 
Optimierungen immer noch.

Jörg W. schrieb:
> aber ist dir schon mal ein Compiler über den Weg
> gelaufen, der keine Möglichkeit hat, die Optimierungen abzuschalten?

Nee, das nicht, aber wenn ich schon die Wahl habe, ob ich nach 
C-Standard programmiere oder mich auf ein bestimmtes Verhalten eines 
bestimmten Compilers verlasse, wähle ich Ersteres, weil Letzteres gerne 
später zu Problemen führt.

Etwa mit Portabilität oder auch nur einem schnöden Compiler-Update. Ich 
erinnere nur an die Story, wo GCC irgendwo bei 4.9 strict-aliasing zum 
Default gemacht hat und Torvalds sich aufgeregt hat, weil das Kernel 
Team erstens mit Pointer-Aliasing gearbeitet hatte sowie zweitens bei 
der Build-Chain geschlampt und das nicht explizit angewiesen hatte. Dann 
funktionierte es auf einmal nicht mehr.

Oder ganz typisch bei embedded: Mist, der Code paßt mit den neuen 
Features nicht mehr ins Flash, laß mal mit -Os die Größe reduzieren. 
Ooops, der auch vorher schon kaputte Code geht jetzt nicht mehr.

Jörg W. schrieb:

> Naja, wer im Embedded-Bereich nicht genau das von vornherein so macht,
> der tut mir leid.

Soviel also zum Thema "Optimierungen abschalten".

Also ich versteh den Zeno schon irgendwie. Es gibt Optimierungen, für 
die man zumindest selber keine sinnvolle Anwendung sieht. Eine Schleife 
wegzuoptimieren würde für mich dazu gehören. Aber es kann natürlich 
sein, dass es die Anwendung doch gibt, Makros wurden hier ja schon 
angedeutet, auch Konstanten könnten in einer Schleife verrechnet werden, 
das dann der Compiler schon vollständig erledigen kann. Auch dass solche 
grenzwertigen Spezialfälle vom Compiler als solche erkannt werden 
müssten, was ein zusätzlicher Entwicklungsaufwand wäre, ist für mich ein 
nachvollziehbares Argument.

Philipp Klaus K. schrieb:
> An SDCC wird häufig kritisiert, dass es jede
> Funktion, die in einer Quellcodedatei steht, auch in die Binärdatei
> kompiliert [...], selbst wenn die betreffende
> Funktion gar nicht aufgerufen wird. Da geht es also nicht mal um ein
> einzelnes ++ oder eine leere Schleife, sondern um ganze Funktionen, von
> denen die Programmierer erwarten, dass der Compiler diese wegoptimiert!

Das versteh ich gut. Man versucht ja wiederverwendbaren Code zu 
schreiben bzw. versucht Code wiederzuverwenden und dazu gehört halt, 
dass man auch Funktionen hat, die man im aktuellen Projekt gerade nicht 
benötigt. Für Bibliotheken gilt das sowieso, auch wenn sie als Quellcode 
vorliegen.

Jörg W. schrieb:

> Naja, du warst doch derjenige, der unbedingt eine 1:1-Umsetzung haben
> will.

Äh, nein? Das waren Zeno und W.S., während ich derjenige war, der sich 
lieber an den C-Standard hält. Und Dein Vorschlag war es doch, mit -O0 
die Optimierungen auszuschalten:

> Dann darfst du ihn halt nicht optimieren lassen, -O0 als Option.

Aber wenn man sich nicht an den C-Standard hält, meckert man, daß die 
Optimierungen den Code kaputtmachen, obwohl er selbstverständlich schon 
vorher kaputt war. Wenn man daher ohne Optimierungen arbeitet, anstatt 
den Code zu fixen, dann rennt man später im Projekt u.U. genau in die 
von mir beschriebene Situation: Code ist zu groß, und mit -Os geht er 
nicht mehr.

Jörg W. schrieb:

> GCC hatte früher für diesen Konstrukt tatsächlich eine "Sonderlocke"
> implementiert, aber das war zusätzlicher Aufwand, just diese Situation
> ("toter Code, der stehen bleiben soll") zu erkennen, und irgendwann
> haben sie halt diese Sonderlocke abgeschafft.

Tja, aber in der typisch inkonsequenten Weise der C-"Logik" natürlich 
nicht sehr konsequent.

Denn, in:

1

int main(void) {

2

3

  while (1) {

4

    //nothing

5

  }

6

}

wird die Schleife trotz ihrer offensichtlichen Nutzlosigkeit NICHT 
wegoptimiert. Nach der von dir beschriebenen "superlogischen Logik", die 
so typisch für dieses unsäglich erbärmliche C-Gefrickel ist, hätte sie 
aber wegoptimiert werden müssen! Denn klarerweise geschieht im Body 
nichts nützliches, d.h.: auch die diesen Body umfassende 
Kontrollstruktur ist unnütz, denn eine Schleife, die unendlich garnix 
macht, macht am Ende garnix.

Tja, so ist das mit der Logik...

c-hater schrieb:
> hätte sie aber wegoptimiert werden müssen!

Nope. Ohne Endlosschleife gibt's nämlich einen beobachtbaren externen 
Effekt: Das Programm endet. Bei den Delay-Schleifen gibt's so einen 
Unterschied nicht. Erst denken, dann ranten.

Nop schrieb:

> Nope. Ohne Endlosschleife gibt's nämlich einen beobachtbaren externen
> Effekt: Das Programm endet. Bei den Delay-Schleifen gibt's so einen
> Unterschied nicht. Erst denken, dann ranten.

Nur ist das Problem: an jeder anderen Stelle im Programm wird EXAKT 
dieselbe Schleife wegoptimiert.

Was ist denn das für ein Sprachstandard? Einmal hüh, einmal hott bei 
EXAKT demselben Sprachkonstrukt?

Das ist lächerlich für einen Sprachstandard!

Jörg W. schrieb:
> Naja, du warst doch derjenige, der unbedingt eine 1:1-Umsetzung haben
> will.
>
> Die geht, wenn man die Optimierung ausschaltet.

Moin,

bist Du sicher, dass der von Dir verwendete Compiler bei -O0 wirklich 
den kompletten Code 1:1 übersetzt?

z.B. der C/C++ Development Guide zum IAR Compiler für Arm v9.30.1 sagt 
auf Seite 250 zu den Optimierungen:

1

None (Best debug support)

2

- Variables live through their entire scope

3

- Dead code elimination

4

- Redundant label elimination

5

- Redundant branch elimination

Also wird bereits bei "Optimization = none" bis zu einem gewissen Punkt 
nur das übersetzt, was am Ende auch Sinn macht und nach meinem 
Verständnis sollte das vom C Standard (z.B. C99 - 5.1.2.3) abgedeckt 
sein.

z.B. wird für das Incrementieren von foo kein Code mehr erzeugt, da die 
Instruktion "unreachable" ist (aber es wird zumindest eine entsprechende 
Warnung angezeigt):

1

int main(void)

2

{

3

   int foo = 123;

4

5

   while (1){};

6

7

   foo++;

8

}

@ Philipp:
Wie handhabt das denn der SDCC?

Gruß,
Michael

Joerg W. schrieb:

> seit wann das?

Keine Ahnung.

> Alles was nach
>

1

> while(1){};

2

>

> kommt, kann natürlich wegoptimiert werden (non-reachable code).

Ja, das ist ja auch logisch und somit sinnvoll. Keine Einwände 
meinerseits.

Ich meine sowas (absichtlich eingebauter "trap"):

1

if (errordetected) {

2

  while (true) {

3

    //nothing here: endless loop is INTENDED (as trap)

4

  }

5

} else {

6

  //perform the normal behaviour

7

}

Was tatsächlich rauskommt, ist aber, dass die gewollte Endlosschleife 
ersatzlos rausoptimiert wird und statt dessen unmittelbar der Code 
hinter dem Else-Zweig der Verzweigung ausgeführt wird.

Ist allerdings errordetected != true, wird erwartungsgemäß der "normal 
behavior" durchlaufen (und macht auch, was er soll) und erst dann der 
Code hinter der Verzweigung.

Εrnst B. schrieb:
> Irgendwann, wenn die KI-Basierten Codegeneratoren ein Bewusstsein
> entwickelt haben und brauchbare Ergebnisse liefern, kann auch er seinen
> gedankenlesenden Do-What-I-Want Compiler haben.
Wieso muß der Compiler GEdanken lesen? Der soll nur machen was ich ihm 
auf den "Einkaufszettel" schreibe.
Im Übrigen gibt es einen solchen Compiler schon seit ca. 1971. Der tut 
das was ich ihm hin schreibe - ist halt kein C.

Jörg W. schrieb:
> Warum sollte jemand, der sich "c-hater" nennt, sich mit C auskennen
> (geschweige denn mit dessen Standard)?
Ich befürchte mal das sich der c-heater mit C besser auskennt als Du 
denkst und nur durch die Besonderheiten diese Sprache zum c-hater 
geworden ist.

Michael F. schrieb:
> z.B. wird für das Incrementieren von foo kein Code mehr erzeugt, da die
> Instruktion "unreachable" ist (aber es wird zumindest eine entsprechende
> Warnung angezeigt):
So wäre das ja auch für mich in Ordnung - mit der Warnung, weil dann 
entscheide ich ob an dieser Stelle "optimiert" wird oder nicht.

c-hater schrieb:

> Was tatsächlich rauskommt, ist aber, dass die gewollte Endlosschleife
> ersatzlos rausoptimiert wird und statt dessen unmittelbar der Code
> hinter dem Else-Zweig der Verzweigung ausgeführt wird.

Ist das so? Gerade mal auf Godbolt geguckt für ARM-GCC 12.1 mit -O3. 
Dieser Codeschnipsel hier...

1

volatile int dummy;

2

3

void func(int errordetected)

4

{

5

    if (errordetected) {

6

        while (true) {

7

            //nothing here: endless loop is INTENDED (as trap)

8

        }

9

    } else {

10

        dummy++;

11

    }

12

}

... wird compiliert zu:

1

func(int):

2

        cbnz    r0, .L3

3

        movw    r3, #:lower16:.LANCHOR0

4

        movt    r3, #:upper16:.LANCHOR0

5

        ldr     r2, [r3]

6

        adds    r2, r2, #1

7

        str     r2, [r3]

8

        bx      lr

9

.L3:

10

        b       .L3

11

dummy:

Es wird also die Endlosschleife ausgeführt, wenn errordetected ungleich 
0 ist, und sonst die Dummy-Variable erhöht.

Ich vermute daher, daß in was auch immer Dein Beispiel ursprünglich 
getan hat, der Fall des errordetected deswegen gar nicht auftreten kann, 
weil Du dann undefined behaviour eingebaut hättest und der Compiler das 
erkannt hat. Dann darf der Compiler diesen Fall behandeln, wie immer er 
das möchte.

Das ist ein Fehler im Code, wenngleich C99 knapp 200 Fälle von undefined 
behaviour hat und man das zurecht kritisieren kann, insbesondere weil 
man nicht immer eine Warnung dazu bekommt. In dieser Hinsicht macht Rust 
es besser.

c-hater schrieb:
> Was ist denn das für ein Sprachstandard? Einmal hüh, einmal hott bei
> EXAKT demselben Sprachkonstrukt?
Naja für die main() braucht man halt ab und an mal ne Endlosschleife um 
goto zu vermeiden. Obwohl dafür gäbe es ja auch for(;;){} - ist genau so 
hirnrissig.

Zeno schrieb:
> Obwohl dafür gäbe es ja auch for(;;){} - ist genau so hirnrissig.

Nein, ist es nicht. Es ist deswegen die von K&R propagierte und die 
einzige von Lint akzeptierte Form, weil man bei einer while-Schleife die 
Schleifenbedingung aus Versehen auf endlos stellen kann, besonders im 
Zusammenspiel mit Macro-Defines. Bei der Form mit for(;;){} gibt's 
dieses Risiko nicht.

Jörg W. schrieb:
> Diesen Eindruck hat er bei mir im Laufe der Zeit keineswegs
> hinterlassen.
Der Eindruck kann manchmal auch täuschen.

Nop schrieb:
> Zeno schrieb:
>> Obwohl dafür gäbe es ja auch for(;;){} - ist genau so hirnrissig.
>
> Nein, ist es nicht. Es ist deswegen die von K&R propagierte und die
> einzige von Lint akzeptierte Form, weil man bei einer while-Schleife die
> Schleifenbedingung aus Versehen auf endlos stellen kann, besonders im
> Zusammenspiel mit Macro-Defines. Bei der Form mit for(;;){} gibt's
> dieses Risiko nicht.
Ja logo finden die Fans der Sprache C so was geil, weil so etwas ohne 
jegliche Logik ist, man muß es halt auswendig lernen.
Man kann jede Schleife zu einer Endlosschleife machen, wenn man die 
Abbruchbedingung entsprechend setzt. Ob das wissentlich, versehentlich 
oder gar gewollt gemacht wird ist dabei völlig Rille.

So ein Compiler kann schon unterscheiden zwischen einer Endlosschleife 
und einer Schleife die nur eine (vermutlich danach nicht mehr 
verwendete) Variable hochzählt. Ersteres soll nie enden, das letztere 
soll so schnell wie möglich ausgeführt werden, als am besten mit 0 
Takten. Und es gibt eine (indirekte) Möglichkeit dem Compiler zu sagen, 
daß man den Zählvorgang doch haben will, vermutlich weil man Zeit 
verbrennen will.
Wo ist also das Problem. Wer diese Sprache nicht mag, der soll es 
einfach lassen. So wie ich die Sprache Baujahr 1971 nicht (mehr) 
benutze, das aber normalerweise jedem verheimliche. Auch Fe2O3 brauch 
ich nicht, aber auch das will ich niemandem erklären.

Gcc schrieb:
> Wo ist also das Problem. Wer diese Sprache nicht mag, der soll es
> einfach lassen. So wie ich die Sprache Baujahr 1971 nicht (mehr)
> benutze
Genauso ist es, jeder soll auf seine Art glücklich werden.

Gcc schrieb:
> das aber normalerweise jedem verheimliche
Warum das? Muß man sich rechtfertigen wenn man diese Sprache nicht mag?

Jörg W. schrieb:
> Hier geht es ausschließlich darum, 1) welche Gepflogenheiten es (aus was
> auch immer für Gründen) schon gibt und 2) was entsprechende
> Syntaxchecker vorzugsweise erwarten. (Beides hängt natürlich zusammen.)
> Das ist halt die "for (;;)"-Form, da sie praktisch nie versehentlich
> "entstehen" kann.

Nun ja, Gepflogenheiten sind etwas, das nicht aus rationaler Überlegung 
entsteht, sondern eben nur aus 'das mache ich nach'. So wie bei 
Hobby-Tischlern, daß sie ihren Hobel NIE gerade auf ihren Basteltisch 
stellen, sondern immer nur auf die Seite legen. Irrational? Ja. Eben wie 
alle Gepflogenheiten. Aber herzlich egal.

Allerdings sieht das bei solchen Konstrukten wie for(;;) aus logischer 
Sicht anders aus, als du es darstellst. Von einem Sprachkonstrukt 
erwartet man eigentlich, daß es zu einem bestimmten Zweck existiert. So 
ist der eigentliche Zweck von 'for' eben, eine abgezählte Schleife zu 
machen und der von 'while' eine unabgezählte Schleife, aber mit einer 
Abbruchbedingung. So etwas zu korrumpieren, indem man die Abzählung oder 
die Abbruchbedingung hintertreibt, wird in C zwar nicht als 
Programmierfehler gewertet, führt aber dennoch zu einer entarteten 
Schleife, der ein wesentlicher Teil fehlt. Es ist unlogisch, ein 
Sprachkonstrukt zu verwenden, dessen Zweck man garnicht bezweckt. Da 
können K&R dazu sagen, was sie wollen. Was da bleibt ist eben nur die 
Gepflogenheit. Und die ist irrational. Genauso wie der Streit darum, an 
welchem Ende man das Ei aufschlägt.

W.S.

Zeno schrieb:
> Gcc schrieb:
>> das aber normalerweise jedem verheimliche
> Warum das? Muß man sich rechtfertigen wenn man diese Sprache nicht mag?

Was hat das mit Rechtfertigung zu tun, wenn man nicht jedem seine 
eigenen Vorlieben andienen will.

Martin H. schrieb:
> Besser so?

Sehe ich auch so. Besser.

Martin H. schrieb:
> for (ptr = obj->start; ptr && *ptr; ptr = ptr->next)

Nicht eher so?

for (ptr = obj->start; ptr; ptr = ptr->next)

Wobei, ich habe auch schon diese Variante gesehen:

1

for (ptr = &obj->start; *ptr; ptr = &(*ptr)->next)

2

  if(*ptr == needle)

3

    break;

4

if(*ptr){

5

  void* x=*ptr;

6

  *ptr = x->next;

7

  free(x);

8

}