Compilerfehler?

[Falk B. (falk)]

Jaja ich weiß, die meisten "Compilerfehler" sitzen vor der Tastatur ;-) 
Der hier scheint echt zu sein.

Mit eingeschalteter Optimierung (-O1 oder -Os) wird die Berechnung von 
bandwidth in sdram_speed_test() nicht ausgeführt, ohne Optimierung geht 
es.

    time = TCD0.CNT;
    PRINT("DMA transfer time is %u timer clocks.\r\n", time);
    bandwidth = size * 1024L / (2*time);
    PRINT("Bandwidth is %u kB/s.\r\n", bandwidth );

Die sehr ähnliche Funktion sdram_speed_test_dma()hat diesen Fehler 
nicht! Siehe Anhang.

Ich arbeite mit Atmelstudio 6.2 und dem darin enthaltenen avr gcc 4.8.1 
(Atmel Toolchain), das Ziel ist ein ATXmega128A1 (ohne U).

[Peter II (Gast)]

Falk B. schrieb:
> Mit eingeschalteter Optimierung (-O1 oder -Os) wird die Berechnung von
> bandwidth in sdram_speed_test() nicht ausgeführt

was bekommt du für ausgaben bei dem print?

[The D. (thedaz)]

Ich würde darauf tippen, dass weil size immer 0 ist, diese Berechnung 
von bandwidth nicht stattfinden muss sondern ebenfalls immer 0 ergibt.

[Falk B. (falk)]

@ Peter II (Gast)

>was bekommt du für ausgaben bei dem print?

Es wird immer 0 ausgegeben, auch wenn ich bandwidth auf einen konstanten 
Wert setze.

[Falk B. (falk)]

@ The Daz (thedaz)

>Ich würde darauf tippen, dass weil size immer 0 ist, diese Berechnung
>von bandwidth nicht stattfinden muss sondern ebenfalls immer 0 ergibt.

Das geht nicht, denn es ist eine Funktion. Wenn man ins .lss File 
(Ausschnitt) sieht, dann fehlt die Berechung von bandwidth vollständig!

[Bill (Gast)]

>  ... 1024L ...

Warum steht hinter der 1024 das L?

[chris (Gast)]

Nach

for (; size; start_adr++, size--) {
        __far_mem_read(start_adr);
    }

ist size IMMER 0,

damit ist dann auch

bandwidth = size * 1024L / (2*time);

immer 0 und muss daher auch nie berechnet werden

[Mark B. (markbrandis)]

Falk B. schrieb:
> Das geht nicht, denn es ist eine Funktion.

Sagt wer? ;-)

[The D. (thedaz)]

Falk B. schrieb:
> @ The Daz (thedaz)
>
>>Ich würde darauf tippen, dass weil size immer 0 ist, diese Berechnung
>>von bandwidth nicht stattfinden muss sondern ebenfalls immer 0 ergibt.
>
> Das geht nicht, denn es ist eine Funktion. Wenn man ins .lss File
> (Ausschnitt) sieht, dann fehlt die Berechung von bandwidth vollständig!

Ich glaube, du unterschätzt die Compiler-Optimierung gewaltig.

[Yalu X. (yalu) (Moderator)]

Falk B. schrieb:
> Mit eingeschalteter Optimierung (-O1 oder -Os) wird die Berechnung von
> bandwidth in sdram_speed_test() nicht ausgeführt, ohne Optimierung geht
> es.

Die 0 sollte auch bei abgeschalteter Optimierung ausgegeben werden, nur
dass sie dann eben aufwendig berechnet wird. Bei eingeschalteter
Optimierung hingegen kennt der Compiler das Ergebnis dieser Berechnung
schon zur Compilezeit, weswegen er die Berechung im kompilierten Code
komplett weglässt und stattdessen das Ergebnis (die 0) direkt
hineinschreibt.

Ersetze einfach die Zeile

    for (; size; start_adr++, size--) {

durch

    for (uint16_t i=size; i; start_adr++, i--) {

und alles wird gut :)

[Falk B. (falk)]

@ chris (Gast)

>for (; size; start_adr++, size--) {
>        __far_mem_read(start_adr);
>    }

>ist size IMMER 0,

AHHHHHHH!!!! Tomaten auf den Augen!

DANKE!!

(und mal wieder das alte Vorurteil über Compilerfehler bestätigt) 8-)

[Falk B. (falk)]

@ Bill (Gast)

>>  ... 1024L ...

>Warum steht hinter der 1024 das L?

1024L heißt, dass 1024 als 32 Bit Integer betrachtet werden soll, damit 
die Berechung in 32 Bit ausgeführt wird, um interne Überläufe zu 
vermeiden. Denn 1024 * size ist > 65535.

[Bernd K. (prof7bit)]

Bill schrieb:
>>  ... 1024L ...
>
> Warum steht hinter der 1024 das L?

Damit es ein long ist und er damit  gezwungen ist die ganze Berechnung 
mit Long durchzuführen und nicht standardmäßig mit int. Auf dem avr ist 
int nämlich nur 16 bit breit und das reicht hier nicht.