warum wegoptimiert

[Ain A. (ain)]

Wenn man bei folgendem Code die Compiler Optimierung Stufe 1 ausgewählt 
hat, wird die Variablen Zuweisung übersprungen.
Hat irgendjemand eine Idee warum das so ist.

void striche_in_grad_array_schreiben(signed char strich_anfang,signed 
char strich_laenge)
{
  unsigned char strich_ende;
  strich_ende=strich_anfang+strich_laenge;

Compiler ist der aktuelle bei avr studio 5 intigrierte.

[(prx) A. K. (prx)]

Lässt sich auf Basis dieses Schnipsels nicht beantworten.

[Martin (Gast)]

ain ain101 schrieb:
> Wenn man bei folgendem Code die Compiler Optimierung Stufe 1 ausgewählt
> hat, wird die Variablen Zuweisung übersprungen.
> Hat irgendjemand eine Idee warum das so ist.

Weil.

> void striche_in_grad_array_schreiben(signed char strich_anfang,signed
> char strich_laenge)
> {
>   unsigned char strich_ende;
>   strich_ende=strich_anfang+strich_laenge;

Schau, der interessante Teil ist der, den du weggeschnitten hast.

Wo wird strich_ende auf welche Weise nochmal verwendet?

Vermutlich gar nicht. Und deswegen wird es wegoptimiert.

[(prx) A. K. (prx)]

Wodurch erfahren?

Optimierter Code benimmt sich im Debugger mitunter etwas merkwürdig, 
weil der Maschinencode nicht notwendigerweise in der Reihenfolge des 
Quellcodes erzeugt wird.

[Ain A. (ain)]

Hier die ganze Funktion:

void striche_in_grad_array_schreiben(signed char strich_anfang,signed 
char strich_laenge)
{
  unsigned char strich_ende;
  strich_ende=strich_anfang+strich_laenge;


  strich_anfang=grad_vereinfachen(strich_anfang);
  strich_ende=grad_vereinfachen(strich_ende);
  //grad_anfang--;
  strich_ende--;


  if(strich_anfang>strich_ende)
  {
    strich_anfang-=TEILER;
    for (signed char i=strich_ende; i>=strich_anfang; i--)
    {
      grad_array[grad_vereinfachen(i)]=1;
    }
  }
  else
  {
    for (unsigned char i=strich_anfang; i<=strich_ende; i++)
    {
    grad_array[i]=1;
    }
  }
}

[Rolf Magnus (Gast)]

Welches Problem versuchst du denn zu lösen? Wird grad_vereinfachen() mit 
dem falschen Wert aufgerufen?

Mal so nebenbei bemerkt: Du mischst kunterbunt vorzeichenlose und 
vorzeichenbehaftete Werte. Gibt's dafür einen bestimmten Grund? 
Eigentlich sollte man sowas vermeiden.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

ain ain101 schrieb:
> Hier die ganze Funktion:
Gut, soweit...
Aber, was macht das hier:
> grad_vereinfachen(strich_ende);

BTW: mit den Tokens [/c] und [c] (in umgekehrter Reihenfolge) um den 
C-Code herum wirst du ein Syntax-Highlighting-Wunder erleben...

BTW2: dein Code ist wegen_der_vielen_Unterstriche extrem_blöd_zu lesen. 
Man sieht wegen des Pseudo-Leerzeichens NICHT, was zusammengehört!

[Thomas K. (agentdata)]

Ich kenne mich speziell mit dem AVR Compiler nicht aus - aber eine 
typische Compileroptimierung für den von dir geposteten Code wäre das 
komplette ersetzen deiner Variable strich_ende.

Du initialisierst die Variable mit
strich_ende = strich_anfang + strich_laenge;

Die Variable strich_laenge ist ein argument zu deiner Funktion und 
existiert damit so oder so - verwendet wird sie aber nur zum 
initialisieren von strich_ende und dann nie wieder.

Lange Rede kurzer Sinn - der Compiler optimiert strich_ende = 
strich_anfang + strich_laenge weg und ersetzt es mit strich_laenge += 
strich_anfang. Danach verwendet er im Code statt deiner Variable 
strich_ende einfach die so oder so existierende Variable strich_laenge.

[GeraldB (Gast)]

ain ain101 schrieb:
>   strich_ende=strich_anfang+strich_laenge;
>   strich_anfang=grad_vereinfachen(strich_anfang);
>   strich_ende=grad_vereinfachen(strich_ende);

Weil du das Ergebis nicht verwendest und zwei Zeilen später der Variable 
einen neuen Wert zuweist.

[Ain A. (ain)]

Ich habe jetzt für strich_anfang und strich_laenge kleinere Werte 
verwendet (zufor beidemale 60)und es funktioniert.
A. K. hatte recht. Der Code ging auch ohne optimierung nicht am uc. Die 
zuweisung wurde jedoch beim debugen im Simulator (ohne Optimierung) 
durchgeführt.

Habe mich sofort auf die Optimierung gestürtzt, da sie beim Umstieg von 
AVR-Studio 4 auf 5 vor 10 minuten nicht eingeschaltet war und der Code 
zu langsam lief.

[Rolf Magnus (Gast)]

Lothar Miller schrieb:
> BTW2: dein Code ist wegen_der_vielen_Unterstriche extrem_blöd_zu lesen.
> Man sieht wegen des Pseudo-Leerzeichens NICHT, was zusammengehört!

Das ist Ansichtssache. Viele finden das 
besserAlsBandWurmWoerterMitGrossBuchStabenMittenDrin.

[tenk (Gast)]

Pseudo_Leer_Zeichen trennt
bandWurm zeigt, dass es sich um eine Variable handelt.

[(prx) A. K. (prx)]

Unterstriche in Namen mögen eine Sache des individuellen Geschmacks 
sein. Aber zum Problem wird es, wenn man dann um die Namen drumrum 
systematisch keine Leerzeichen schreibt. Wie in
  a_b_c+d_e_f;
weil sich das optisch fast als
  a b c+d e f;
liest. Also bitte
  a_b_c + d_e_f;

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

tenk schrieb:
> Pseudo_Leer_Zeichen trennt
Und die Hardwarebeschreibungssprache VHDL macht sich das zu Nutze, damit 
lange Zahlen/Vektoren einfacher lesbar sind:
123234345              --> 123_234_345
x"123423be3ad334"      --> x"12_34_23_be_3a_d3_34"
"10010110010011001101" --> "1001_0110_0100_1100_1101"