warum wegoptimiert

Lässt sich auf Basis dieses Schnipsels nicht beantworten.

Wodurch erfahren?

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

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;
    }
  }
}

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!

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.

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.

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;

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"