Zeit die vergeht für diese Schleife???

Fall 1: s ist long

Soll heissen, dass jeder Compiler, der etwas auf sich hält,
diese Schleife komplett rausschmeist und durch die Zuweisung
  s = 65536;
ersetzt

Fall 2: s ist int

Dann gibt es eine Warnung da 65535 nicht mehr in einen int passt


(*) In allen Fällen ist natürlich angenommen, dass s nicht
volatile ist.

Nein, aber der Compiler wird sowas vermutlich wegoptimieren ;)

@Karl-Heinz:

Zu deinem dritten Fall: Die Schleife bricht schon bei s = 65535 ab. Das 
passt aber in einen unsigned int.

Simon Küppers wrote:
> Nein, aber der Compiler wird sowas vermutlich wegoptimieren ;)
>
> @Karl-Heinz:
>
> Zu deinem dritten Fall: Die Schleife bricht schon bei s = 65535 ab. Das
> passt aber in einen unsigned int.

Habs gemerkt :-)
Du hast aber schneller geantwortet als ich das Posting
berichtigen konnte.

Er hat ja  <65535, das geht im Falle unsigned int.

Immer noch das gleiche Problem:
Ein normaler Optimierer wird diese Schleife rauswerfen,
da sie nichts tut, ausser Zeit zu verbraten. Aufgabe eines
Optimierers ist es nun mal ein Programm soweit zu optimieren,
dass möglichst wenig Zeit verbraten wird. Die obige Schleife
ist ein gefundenes Fressen für jeden Optimierer.

Was willst du eigentlich bezwecken?

Wenn es dir nur darum geht eine (kurze) Zeitspanne
zu warten, dann benutze die Funktionen in delay.h:
_delay_ms()
_delay_us()

Lies aber unbedingt die Doku dazu durch (in delay.h).
Es gibt Grenzen für die zu wartenden Zeitspannen.

stampfkern wrote:

> In AVR Studio läuft die Schleife braucht aber sehr lang bis wieder etwas
> anders getan wird. (der AVR soll mit 20 MHz laufen)

Das kann viele Ursachen haben.

Wie bereits gesagt:
Für ein halbwegs genaues Timing und kurze Wartezeiten kann
man die Funktionen aus delay.h benutzen.

Oder aber man geht gleich auf einen Timer. Die meisten Programme
bauen sowieso rund um einen Timer für den Basistakt des Programmes
auf.

stampfkern wrote:
> die delay.h hatte ich auch schon verbraucht aber mehr Speicher als wenn
> ich mein ganzes Progrämmchen unoptimiert kompiliere.

Das kann nicht sein.
Wenn der Optimizer eingeschaltet ist, dann sind da ein paar
bytes mehr drinn. Nichts dramatisches. Wenn du mit den delay.h
Funktionen einen enormen Speicherverbrauch feststellst, dann hast
du ganz einfach keinen Optimizer eingeschaltet.

Der Grund dafür: In der Berechnung der Schleifenzahl in den
delay Funktionen kommen Floating Point Ausdrücke vor. Bei
eingeschaltetem Optimizer werden die vom Optimizer wegoptimiert.
Nur wenn der Optimizer ausgeschaltet ist, dann bleiben die
übrig und sorgen dafür, dass auch gleich noch die halbe Floating
Point Library mit ins Boot kommt. Ganz abgesehen davon, dass dann
auch die Zeiten nicht stimmen :-)

delay.h -> Optimizer einschalten.

stampfkern wrote:
> okay werde es nochmal mit delay.h versuchen.
>
> Trotzdem würde ich gerne wissen wieviele Taktzyklen die For Schleife pro
> Durchlauf braucht wenn s eine uint16_t ist.
>
> for (s = 0; s<1; s++)
>   {
>     ;
>   }

Es gibt nur eine Möglichkeit das herauszufinden:
Du lässt dir ein Assembler Listing vom Compiler
erzeugen und zählst die Takte nach.

* Bei jedem Compilerupdate
* Bei unterschiedlichen Optimizereinstellungen

kann und wird sich diese Anzahl aber verändern.

Rolf Magnus wrote:
> Den Satz zu parsen hat bei mir wegen des fehlenden Kommas etwas
> gedauert.
>
> Da war Karl Heinz wohl wieder mal schneller...

Ich benutze einen heuristischen Parser :-)