|
Anzeige
|
Detected loop counting up. Recommend loops count down as detecting zeros is easier
Gast
#5062515
Der TI MSP430 Compiler sagt zu diesem Code
> Detected loop counting up. Recommend loops count down as detecting zeros is
easier
Lässt er sich beruhigen, ohne die Daten im Array umzudrehen?
Info schrieb: > Lässt er sich beruhigen, ohne die Daten im Array umzudrehen? Gegen perverse Compiler hilft vielleicht perverser Code:
Gast
#5062525
;-) Danke dir, mal sehen, ob ich irgendwie an das Resultat herankomme. Und ob ihm eine Subtraktion des Index besser schmeckt. Oder ich ignoriere ihn und konzentriere mich auf's Programm.. Die einzige Konsequenz ist, dass die Schleife pro Durchlauf einen Takt mehr benötigt. TI empfiehlt die Optimierung auf "-o2" zu setzen. http://processors.wiki.ti.com/index.php/Compiler/diagnostic_messages/MSP430/1544
Gast
#5062581
Danke für den Link.
Sorry, das ist Quark und dient nur dazu, den Hinweis abzustellen. Du sparst jeweils einen Takt, musst aber den wieder spendieren, um die Addition von *parr zu rechnen. Und verbrauchst außerdem ein Wort extra. Außerhalb von zeitkritischen ISRs kann man den Hinweis i.d.R. getrost ignorieren. Dafür sollte man sich beim Optimieren genau anschauen, was der Compiler treibt. Der TI-Compiler ist alles andere als fehlerfrei :( Max G. schrieb: > Sorry, das ist Quark und dient nur dazu, den Hinweis abzustellen. Du > sparst jeweils einen Takt, musst aber den wieder spendieren, um die > Addition von *parr zu rechnen. Und verbrauchst außerdem ein Wort extra. Wobei solche Kalkulationen auf Hochsprachenbasis nicht notwendigerweise dem entsprechen, was hinten aus dem Compiler rauskommt. Hochoptimierende Compiler wie GCC erzeugen in beiden Beispielen den gleichen Code (bei -O2). Ob also ein Index im Quelltext inkrementiert oder dekrementiert wird ist ihm egal, im erzeugten Code gibt es keinen Index, statt dessen wird in beiden Fällen ein Pointer inkrementiert und verglichen. Entspricht: uint8_t *parr = array; do { function(*parr); } while (++parr != array+14);
Gast
#5071782
Ein Compiler der sagt: "Ich weiss was Du willst, bin aber zu blöd, das in Assembler umzusetzen. Bitte hilf mir". Naja, wenigstens ehrlich, die Entwickler! Achim S. schrieb: > "Ich weiss was Du willst, bin aber zu blöd, das in Assembler umzusetzen. > Bitte hilf mir". Nö. Er sagt: "Du hast mir nicht erlaubt, wirklich zu optimieren, also tu es gefälligst selbst". Mit "-o2" macht er es.
Gast
#5072543
Darfst du denn überhaupt die Reihenfolge des Durchlaufs umdrehen? Was macht denn function(.)? Falls function(.) frei von Seiteneffekten ist und dessen Output nur von den Eingangswerten abhängt, dann gebe ihr das Attribut "pure". DANN darf der Compiler das auch selbst umdrehen. (ob er es macht, ist eine andere Frage. Da spielen noch mehr sachen mit rein). meckerziege schrieb: > Darfst du denn überhaupt die Reihenfolge des Durchlaufs umdrehen? Was > macht denn function(.)? Die Reihenfolge der Funktionsaufrufe darf er normalerweise nicht umdrehen (Ausnahmen siehe z.B. meckerziege, oder bei Inlining). Die Werteabfolge einer Zählvariablen hingegen schon, wenn das keine Auswirkung auf die Reihenfolge der Funktionsaufrufe oder anderen Code hat, weil er für das Array eine andere Lösung hat. Ebenso kann er die Zählvariable selbst komplett eliminieren. Der Code im Startbeitrag ist eine klassische Zählschleife mit Verwendung als Index. Ein guter Compiler wird darin erkennen, dass die Schleife 14x ausgeführt wird und das Array aufsteigend ab 0 indiziert wird. Wie er das dann implementiert ist allein seine Sache, da die Zählvariable nirgends sonst verwendet wird (wobei ich annehme, sie ist lokal definiert, nicht global). Daumenregel: Wenn als Ergebnis von erzeugten Code das rauskommt, was unter Anwendung der Regeln von C rauskommen darf, darf er machen was er will. Wobei mit und ohne Optimierung auch verschiedene Ergebnisse rauskommen dürfen, wenn beide in diesem Sinn zulässig sind. Antwort schreiben |
Anzeige
|
