mikrocontroller.net

Forum: Compiler & IDEs GCC: variable may be used unitialized


Autor: Walter Tarpan (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe mal wieder den Fall, wo ich nicht verstehe, wie der Compiler 
"denkt".

Ich habe die folgende Funktion:
/* Bitmap zweifarbig oder auf transparentem Hintergrund darstellen */
uint32_t tft_ili9xxx_drawBitmap(uint8_t *bitmap, Rect_t R, Colors_t Color,
    uint_fast8_t scale )
{
    uint_fast8_t bits, bit=0;

    if( R.w < 1 || R.h < 1)
    {
        return EXIT_FAILURE;
    }

    if( Color.bg == transparent || scale != 1)
    {
        // Jedes Pixel einzeln setzen. Recht ineffizient, da Schreibaufwand 13 Bytes/Pixel
        // Hochskalierte Bitmaps werden grundsaetzlich mit transparentem Hintergrund
        // dargestellt
        for( int_fast16_t iCol=0; iCol < R.w; iCol++ )
        {
            for( int_fast16_t iRow=0; iRow < R.h; iRow++ )
            {
                if( !(bit++ & 7) )
                {
                    bits = *bitmap++;
                }

                if( bits & 0x80 ) // <== warning 'bits' may be used uninitialized 
                {
                    if(scale == 1)
                    {
                        Coord2_t Tmp = (Coord2_t) {R.y+iRow, R.x+iCol};
                        tft_ili9xxx_drawPixel(Tmp, Color.fg);
                    }
                    else
                    {
                        Rect_t Rtmp = {R.x+iCol*scale, R.y+iRow*scale, scale, scale};
                        tft_ili9xxx_drawRectF(Rtmp, Color.fg);
                    }
                }
                bits <<= 1;
            }
        }
    }
    else
    {
        // Relativ effiziente Darstellung als Bitmap mit Hintergrund
        tft_ili9xxx_setAddrWindow(R);
        tft_ili9xxx_putBitmap(ili9xxx_MemoryWrite, bitmap, R.w * R.h, Color.bg, Color.fg);
    }


    return EXIT_SUCCESS;
}

Der Compiler mahnt in der markierten Zeile an: "warning: 'bits' may be 
used uninitialized in this function [-Wmaybe-uninitialized]"

Meine naive Denkweise wäre: "Mit der Initialisierung bit=0 ist die 
Bedingung "if( !(bit++ & 7) )" beim ersten Durchlauf der inneren 
Schleife grundsätzlich immer erfüllt und damit bits initialisiert. Und 
der Compiler müßte das genauso sehen."

Aber er sieht das irgendwie anders als ich? Wo ist mein Denkfehler?

Viele Grüße
W.T.

Autor: Felix U. (ubfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Die Variable "bit" ist initialisiert, "bits" aber nicht. Dass "bits" 
später konditional ein Wert zugewiesen wird, wird für Warnung nicht 
berücksichtigt. Aber deshalb heißt es ja auch nur "may be 
uninitialized". Übrigens tut man in solchen Fällen nicht nur dem 
Compiler einen Gefallen, wenn man die Variable einfach initialisiert, 
auch wenn sie anschließend noch mal überschrieben wird. Es ist einfach 
besser lesbar.

: Bearbeitet durch User
Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Walter T. schrieb:
> Meine naive Denkweise wäre:

Das AnalyseFu des Compilers ist nicht unbegrenzt, und es hängt auch vom 
Optimierungsgrad ab. Vielleicht nochmals die Doku studieren:

http://gcc.gnu.org/onlinedocs/gcc/Warning-Options....

Ansonsten kann ich mich nur Felix anschließen.

: Bearbeitet durch User
Autor: holger (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
>Meine naive Denkweise wäre: "Mit der Initialisierung bit=0 ist die
>Bedingung "if( !(bit++ & 7) )" beim ersten Durchlauf der inneren
>Schleife grundsätzlich immer erfüllt und damit bits initialisiert.

Und was kostet es dich einmal zu schreiben bits = 0;?
Compiler zufrieden. Dafür so einen Aufriss hier?
Sonst nix besseres zu tun?

Autor: Walter Tarpan (nicolas)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Hallo Felix und Johann,

danke für die Antworten.

Felix U. schrieb:
> Dass "bits"
> später konditional ein Wert zugewiesen wird, wird für Warnung nicht
> berücksichtigt.

Das ist der Punkt: Ich bin immer wieder überrascht, welche Annahmen der 
optimierende Compiler bei seinem Blick durchs Schlüsselloch treffen 
kann. Da wundert es es auf der anderen Seite schon, daß eine für den 
menschlichen Leser offensichtliche Bedingung nicht erkannt wird.

Das kann natürlich auch einfach daran liegen, daß die Warnungen in einer 
anderen Compilerstufe als die Optimierungen erzeugt werden.

Felix U. schrieb:
> [...] wenn man die Variable einfach initialisiert,
> auch wenn sie anschließend noch mal überschrieben wird. Es ist einfach
> besser lesbar.

Als Autor dieses Quelltext war meine Absicht, die bewußte 
Nicht-Initialisierung dem Quelltext-Leser (meistenteils mir) als Wink 
mit dem Zahnpfahl mitzugeben, daß ich annehme, daß die Bedingung der 
inneren Schleife im ersten Schleifendurchlauf grundsätzlich immer 
erfüllt ist.

Daß zwei fortgeschrittene Programmierer (zumindest bei einem bin ich mir 
sicher) gegenteiliger Ansicht sind, gibt mir zu denken. Vielleicht 
ergibt sich mit einer Woche Distanz zum eigenen Quelltext auch ein ander 
Blick.

Viele Grüße
W.T.

: Bearbeitet durch User
Autor: alfred (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Walter T. schrieb:
> Als Autor dieses Quelltext war meine Absicht, die bewußte
> Nicht-Initialisierung dem Quelltext-Leser (meistenteils mir) als Wink
> mit dem Zahnpfahl mitzugeben, daß ich annehme, daß die Bedingung der
> inneren Schleife im ersten Schleifendurchlauf grundsätzlich immer
> erfüllt ist.

wenn du das annimmst, warum machst du die zuweisung dann konditionell?
if( !(bit++ & 7) )
                {
                    bits = *bitmap++;
                }

                if( bits & 0x80 ) // <== warning 'bits' may be used uninitialized 

lass doch "if( !(bit++ & 7)" einfach weg und schreibe nur "bits = 
*bitmap++;"

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
alfred schrieb:
> lass doch "if( !(bit++ & 7)" einfach weg und schreibe nur "bits =
> *bitmap++;"

Und Du meinst, dass das Programm dann noch dasselbe macht?

: Bearbeitet durch Moderator
Autor: Nop (Gast)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
Walter T. schrieb:

> Als Autor dieses Quelltext war meine Absicht, die bewußte
> Nicht-Initialisierung dem Quelltext-Leser (meistenteils mir) als Wink
> mit dem Zahnpfahl mitzugeben, daß ich annehme, daß die Bedingung der
> inneren Schleife im ersten Schleifendurchlauf grundsätzlich immer
> erfüllt ist.

Das erste Unangenehme ist, daß solche Kunstwerke bei der nächsten 
Erweiterung des Quelltextes spontan zerbrechen, wenn man diese 
impliziten Abhängigkeiten nach ein paar Monaten nicht mehr exakt im Kopf 
hat. Noch fieser, wenn jemand anderes diese Erweiterungen machen soll. 
Es ist also zumindest ein Wartbarkeitsproblem.

Das Zweite ist, selbst wenn die GCC-Warnung im konkreten Fall 
unberechtigt ist, sollte man den Code trotzdem so korrigieren, daß die 
Warnung verschwindet. Ziel sollte immer sein, den Code mit 0 Warnungen 
durchlaufen zu lassen, auch wenn -Wall und -Wextra aktiviert werden. Am 
besten auch gleich -Werror, damit Warnungen garantiert nicht ignoriert 
werden.

Wenn man das nicht von Anfang an so macht, hat man irgendwann hunderte 
Warnungen, die alle unberechtigt sind - und wie soll man dann die ein 
oder zwei darin sehen, die auf einen tatsächlichen Fehler verweisen.

Autor: Felix F. (wiesel8)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Walter T. schrieb:
> Wo ist mein Denkfehler?

Dass du denkst, du musst Variablen nicht mit einem Default-Value 
initialisieren, weil es die tausend anderen Arduino-Kiddies auch nicht 
machen.

Google mal nach 'Defensive programming'

Viel schlimmer finde ich hingegen, dass du den bitmap-Pointer nicht auf 
Gültigkeit abprüfst. Du stehst wohl auf Überraschungen und Exceptions 
zur Laufzeit?

mfg

: Bearbeitet durch User
Autor: Walter Tarpan (nicolas)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Felix F. schrieb:
> Dass du denkst, du musst Variablen nicht mit einem Default-Value
> initialisieren, weil es die tausend anderen Arduino-Kiddies auch nicht
> machen.

Auch eine Sache, die mich immer wieder erstaunt: Wenn man offen zugibt, 
daß es Menschen gibt, die besser programmieren können als man selbst, 
glauben plötzlich alle anderen, auch zu dieser Gruppe zu gehören.



Nop schrieb:
> [...] Ziel sollte immer sein, den Code mit 0 Warnungen
> durchlaufen zu lassen, [...]

Wenn das nicht schon im Vornherein klar wäre - warum sollte man so eine 
Frage stellen?


Felix F. schrieb:
> Du stehst wohl auf Überraschungen und Exceptions
> zur Laufzeit?

Nein, aber ich kenne mehr vom Quelltext als nur diese eine Funktion.

Autor: Joachim B. (jar)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Felix F. schrieb:
> dass du den bitmap-Pointer nicht auf
> Gültigkeit abprüfst. Du stehst wohl auf Überraschungen und Exceptions
> zur Laufzeit?

das bläht aber den Code auf, machts noch weniger leserlich und kratzt 
u.U. schon an der flash und SRAM Größe

klar besser ist das alles immer vorher zu überprüfen, das kostet halt 
Zeit und Resourcen und verhindert schnelle Erfolge.

Ich kümmere mich lieber um Probleme wenn sie auftauchen, aber es ist nur 
Hobby (komischerweise sehen das die Profientwickler ja ähnlich, sonst 
gäbe es keine Updates oder Rückrufe)

Autor: Felix F. (wiesel8)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Joachim B. schrieb:
> Ich kümmere mich lieber um Probleme wenn sie auftauchen

Erzähl das mal den Familien der 200 Toten, weil du im Autopilot ein 
if(pointer != 0) vergessen hast ;)


Walter T. schrieb:
> Auch eine Sache, die mich immer wieder erstaunt: Wenn man offen zugibt,
> daß es Menschen gibt, die besser programmieren können als man selbst,
> glauben plötzlich alle anderen, auch zu dieser Gruppe zu gehören.

Ich halte mich nicht für einen Experten, ich versuche bloß die Standards 
einzuhalten. Wenn das schon zu viel für dich ist, ist es nicht mein 
Problem.

mfg

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Felix F. schrieb:
> Viel schlimmer finde ich hingegen, dass du den bitmap-Pointer nicht auf
> Gültigkeit abprüfst

Das geht sowieso nur sehr begrenzt, ein Pointer der kein Nullpointer ist 
kann auch ungültig sein... ein assert() wäre vermutlich angemessen.

An W.T.:
Stell dir mal vor du hast in einer Funktion einen Simulator einer Turing 
Maschine. Am Anfang wird eine Variable deklariert, aber nicht 
initialisiert. Wenn der Simulator feststellt dass das Programm der TM 
terminiert, liest er die Variable aus. Der Compiler soll also eine 
Warnung ausgeben, genau dann wenn der Algorithmus terminiert. Mit 
anderen Worten, soll der Compiler das Halteproblem lösen. Das ist 
unmöglich. Somit kann der beste Compiler der Welt diese Warnung nicht 
100% akkurat ausgeben. Deswegen steht da ja auch "may".
Ansonsten kann ich nur "Nop" absolut recht geben. Während der 
Entwicklungs Phase sollte -Werror Pflicht sein! Hab schon öfter gesehen 
dass Leute Fehler nicht gesehen haben weil die Warnung zwischen anderen 
Warnungen untergeht...

Autor: Adapter (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Walter T. schrieb:
>
> Als Autor dieses Quelltext war meine Absicht, die bewußte
> Nicht-Initialisierung dem Quelltext-Leser (meistenteils mir) als Wink
> mit dem Zahnpfahl mitzugeben, daß ich annehme, daß die Bedingung der
> inneren Schleife im ersten Schleifendurchlauf grundsätzlich immer
> erfüllt ist.
>

Für genau solche Zwecke gibt es Kommentare.

Autor: Mikro 77 (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Felix U. schrieb:
> Übrigens tut man in solchen Fällen nicht nur dem
> Compiler einen Gefallen, wenn man die Variable einfach initialisiert,
> auch wenn sie anschließend noch mal überschrieben wird. Es ist einfach
> besser lesbar.

In diesem Fall ist es tatsächlich einfach, mit dem richtigen Wert zu 
initialisieren. Bei der folgenden Abfrage zum Update von (bits) wird der 
Post- zum Prefix Increment.

"Einfach" dagegen mit einem Default initialisieren, um den Compiler 
glücklich zu machen, wäre dagegen kontraproduktiv. Ich bin kein Fan von 
vielen Kommentaren, im letzteren Fall wäre dann imho aber einer 
angebracht.

Autor: Walter Tarpan (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Stell dir mal vor du hast in einer Funktion einen Simulator einer Turing
> Maschine.

Meines Wissens nach ist die C Virtual Machine keine Turing-Maschine, das 
Problem, ob die Variable "bits" initialisiert ist, ist wohldefiniert und 
vom Halteproblem nicht betroffen.

Vom Standard her wäre es völlig legitim, wenn für jeden Aufruf der 
Funktion die kompletten Schleifen abgerollt würden. Dann gäbe es die 
erste if-Bedingung in der Schleife nicht mehr.

Es handelt sich lediglich um eine Designentscheidung der Compilerbauer, 
wie tief die Codeanalyse getrieben wird, bevor eine Warnung ausgegeben 
wird.


Adapter schrieb:
> Für genau solche Zwecke gibt es Kommentare.

Kommentare sind die zweitbeste Lösung, wenn der Quelltext für die 
übersichtliche Darstellung meiner Absichten nicht ausreicht. Hier komme 
ich nicht drum herum. Aber ich halte es trotzdem sinnvoll zu klären, ob 
es nötig ist. Das ist geschehen.

: Bearbeitet durch User
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Walter T. schrieb:
> Meines Wissens nach ist die C Virtual Machine keine Turing-Maschine,
Das spielt keine Rolle. C ist Turing Vollständig, man kann 
Turing-Maschinen simulieren.

Walter T. schrieb:
> das
> Problem, ob die Variable "bits" initialisiert ist, ist wohldefiniert und
> vom Halteproblem nicht betroffen.
Doch. Wie gesagt, wenn der Compiler für jeden beliebigen Algorithmus 
bestimmen könnte, ob eine Variable uninitialisiert benutzt wurde, könnte 
er wie oben begründet das Halte-Problem lösen. Entweder sind also 100 
Jahre Informatik falsch - oder die Annahme, dass es möglich ist, die 
Warnung akkurat zu machen.

Die Warnung ist in vielen einfachen Fällen korrekt, aber eben nicht in 
allen. Man könnte höchstens darüber diskutieren, ob der Compiler mehr 
Fälle erkennt.

Autor: Walter Tarpan (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Wie gesagt, wenn der Compiler für jeden beliebigen Algorithmus
> bestimmen könnte,

Es ist nicht jeder beliebiger Algorithmus. Er ist nicht rekursiv. Er ist 
noch nicht einmal iterativ. Es ist eine popelige Vorwärtsschleife, bei 
der die exakte Anzahl der Schleifendurchläufe schon zur Laufzeit 
feststeht. Bei genauerer statischer Codeanalyses sogar zur Compilezeit.

Bei nicht so genauer Analyse ist aber immerhin sicher, daß sie kleiner 
als INT_FAST16_MAX * INT_FAST16_MAX ist.

Autor: Felix F. (wiesel8)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Man könnte sich diese ganze Diskussion auch sparen in dem man:
1. Die Variable gleich korrekt initialisiert: uint8 bits = *bitmap++;
2. Sich somit die if-Abfrage in der Schleife spart -> Performance
3. Am Schluss der Schleife ein bits = *bitmap++; macht.
4. Die Variable komplett sparen und direkt auf bitmap zugreifen.

mfg

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Felix F. schrieb:
> 1. Die Variable gleich korrekt initialisiert: uint8 bits = *bitmap++;

Nicht sinnvoll: Der Pointer bitmap verschiebt sich dann um eine Stelle 
vor dem Eintritt in die beiden inneinander verschachtetelten Schleifen.

> 2. Sich somit die if-Abfrage in der Schleife spart -> Performance

Ohne if macht das Programm nicht mehr dasselbe: Das if prüft nämlich, ob 
die unteren drei bits in der Variablen bit gesetzt sind. Die Zuweisung
bits = *bitmap++;

wird durchgführt für bit = 0, 1, 2, 3, 4, 5, 6 und NICHT für 7, 15 usw.

> 3. Am Schluss der Schleife ein bits = *bitmap++; macht.

Und Du meinst, dass das Programm dann noch dasselbe macht?

> 4. Die Variable komplett sparen und direkt auf bitmap zugreifen.

Interessante These, schau mal nach dem Bitshift bits <<= 1 weiter unten.

Deine Änderungen bewirken lediglich, dass die Funktion letztendlich was 
ganz anderes macht.

: Bearbeitet durch Moderator
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Walter T. schrieb:
> Es ist nicht jeder beliebiger Algorithmus.
Ja, wie gesagt, für einfache Fälle kann man drüber diskutieren. Im 
Allgemeinen ist das aber unmöglich.

Walter T. schrieb:
> Er ist nicht rekursiv.
Sind Turing-Maschinen auch nicht :P

Autor: Joachim B. (jar)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Felix F. schrieb:
> Erzähl das mal den Familien der 200 Toten, weil du im Autopilot ein
> if(pointer != 0) vergessen hast ;)

ne ne ne,

mein Ex-Chef meinte mal, manchmal muss man einen Entwickler die Teile 
auch aus der Hand reissen weil die sonst nicht ausgeliefert werden.

Er ist wohl nicht alleine mit dieser Meinung

das passt irgendwie
https://www.n-tv.de/politik/Tornados-koennen-nicht...

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wenn alles nur schnell auf den Markt kommen soll, soll man sich auch 
nicht über miese Software beschweren (Windows-Updates die das OS 
zerschießen, Browser die viel RAM brauchen, Sicherheitslücken überall, 
Unbenutzbarkeit alter Hardware mit neuer Software, usw)

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Walter T. schrieb:
> Kommentare sind die zweitbeste Lösung, wenn der Quelltext für die
> übersichtliche Darstellung meiner Absichten nicht ausreicht.

Ok, den Leser erwartet ein bunter Mix aus Ratequiz und 
Reverse-Engineering — überspitzt ausgedrückt.

Wenn Wissen über den Code vorhanden ist, warum das nicht hinschreiben? 
Warum diese Wissen aus dem Code extrahieren müssen wenn es bereits 
vorhanden ist? Wenn deine Kommentare freilich lauten:

// Initialize x with 2.
x = 2;

dann taugen sie vielleicht für ein C-Tutorial, nicht aber für sinnvolle 
Darstellung dessen, warum etwas gemacht wird, warum ein bestimmter, 
womöglich (scheinbar) offensichtlicher Ansatz nicht gewählt oder 
wieder verworfen wurde, oder als Zusammenfassung der nächsten 
Arbeitsschritte.

// Just an arbitrary value, determined by fair dice roll.
// Very init will happen at gaga below.
x = 2;

Walter T. schrieb:
> Meines Wissens nach ist die C Virtual Machine keine Turing-Maschine,

C ist Turing-vollständig.

> Vom Standard her wäre es völlig legitim, wenn für jeden Aufruf der
> Funktion die kompletten Schleifen abgerollt würden. Dann gäbe es die
> erste if-Bedingung in der Schleife nicht mehr.
>
> Es handelt sich lediglich um eine Designentscheidung der Compilerbauer,
> wie tief die Codeanalyse getrieben wird, bevor eine Warnung ausgegeben
> wird.

ACK.  Und eine Design-Regel von GCC ist: Verbrauch von Host-Resourcen 
(Speicher, Zeit) ist linearistisch, d.h. in O(x^{1+eps}) mit eps > 0 
beliebig.

Wenn man nun Schleifen schält oder abrollt, bleibt die Komplexität immer 
noch lniearistisch wenn man z.B. die Schälung statisch durch 1000 nach 
oben beschränkt.  Dies ist eine Design-Entscheidung, die u.U. durch 
Schalter oder Parameter beeinflussbar ist; die Doku sagt dir mehr.

I.d.R werden Optimierungspasses auch nicht ausgeführt, um statische 
Analyse zu betreiben, sondern um den Zielcode zu optimieren.  Was auch 
bedeutet, dass das Ergebnis der Analyse etwa in Form von Warnungen 
optimierungsabhängig sein kann — das schrieb ich bereits oben.

Wenn du also die Analyse verbessern willst, kannst du versuchen: 
-funroll-loop -funroll-all-loops -fpeel-loops ...

Walter T. schrieb:
> Es ist nicht jeder beliebiger Algorithmus. Er ist nicht rekursiv.
> Er ist noch nicht einmal iterativ.

Eine simple Sicht auf den Code ist, dass er aus 3 Blöcken besteht: 
Entry-Block, Schleifenbauch B und Exit-Block X. Mit diesen 3 Ecken 
ergeben sich folgende Kanten:

E->B, B->B und B->X

Eine mögliche dynamische Entwicklung bzw. Codefluß ist dann etwa:

E->B->B->B->B->B->B->B->B->B->B->B->B->B->B->X

B wird also immer wieder ausgeführt mit unterschiedlichen Vorgängern (E 
und B), die unterschiedliche Daten enthalten. Wenn du eine Iteration 
darstellst, hat die die gleiche Gestalt. Natürlich sieht man in 
Datenanalyse nach Schälung, dass B optimiert (bei gegebenen Algorithmen 
und Value-Range Information, Scalar Evolution, etc.) — das schrieb ich 
bereits oben.

Autor: Walter Tarpan (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> // Just an arbitrary value, determined by fair dice roll.
> // Very init will happen at gaga below.
> x = 2;

Gehört da nicht 3 hin? Oder gilt XKCD nicht mehr als Referenz?




Johann L. schrieb:
> Ok, den Leser erwartet ein bunter Mix aus Ratequiz und
> Reverse-Engineering — überspitzt ausgedrückt.
>
> Wenn Wissen über den Code vorhanden ist, warum das nicht hinschreiben?
> Warum diese Wissen aus dem Code extrahieren müssen wenn es bereits
> vorhanden ist?

Unter uns: Siehst Du oben im Quelltext ein Ratequiz? Die Funktion ist 
nicht toll. Es ist ein Vorher-Stand aus einer Aufräumaktion. Es müßten 
eigentlich zwei Funktionen sein. Es müßte auch auf den Nullzeiger 
geprüft werden. Es ist auch nicht schön, daß bitlogisch auf eine dezimal 
dargestellte Variable geprüft wird, obwohl eher das Bitmuster 
interessant ist. (Prüfen auf Divisionsrest wäre sicherlich noch etwas 
sprechender). Die Namen bit <-> bits sind auch nicht toll. Ich habe 
diese Funktion hier genutzt, weil sie das  Verhalten bei den Warnings 
zeigt, was mich interessierte.

Aber ist es ein Ratequiz? Steckt da irgendeine nicht-offensichtliche 
Designentscheidung drin, die mit einem Kommentar besser verständlich 
wäre, als wenn einfach die Variablen und Konstanten passend benannt 
werden?


Johann L. schrieb:
> Wenn du also die Analyse verbessern willst, kannst du versuchen:
> -funroll-loop -funroll-all-loops -fpeel-loops ...

Danke für den Tipp. Das probiere ich gleich mal aus. Wobei ich mir für 
eine verbesserte Analyse mittlerweile ein virtuelles Linux mit 
Clang/LLVM aufgesetzt habe.

Johann L. schrieb:
> Eine mögliche dynamische Entwicklung bzw. Codefluß ist dann etwa:
>
> E->B->B->B->B->B->B->B->B->B->B->B->B->B->B->X

Den Fluß verstehe ich. Nur nicht, was Du damit ausdrücken willst.
Willst Du damit ausdrücken, daß aus Compilersicht der Unterschied 
zwischen einer Schleife mit im vornherein feststehender Anzahl an 
Durchläufen und einer iterativen Abbruchbedingung weniger Unterschied 
besteht, als es von Nutzersicht aussieht? Oder daß bei der Optimierung 
das eine in das andere überführt werden kann (in einer Richtung ist das 
klar... aber in Gegenrichtung? ) ? Oder stehe ich auf dem Schlauch?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.