order of volatile access undefined

[Warnung (Gast)]

Hi, ich bekommen von meinem Compiler dauernd folgende Warnung:

>Warning[Pa082]: undefined behavior: the order of volatile accesses is >undefined 
in this statement

Das Programm besteht sinngemäß aus folgendem:

volatile uint16_t Var_1;
volatile uint16_t Var_2;
  .
  .
  .
Var_1 = (Var_1 + Var_2)/2;



Wenn ich zusätzliche Zeilen einfüge und lokale Kopien von den Variablen 
verwende, dann gibt es die Warnung nicht mehr, ...aber ich sehe an 
dieser Stelle beim besten Willen kein Problem an der 
Verarbeitungsreihenfolge, oder gelten für volatile andere Gesetze?


Warum also gibt mir der Compiler dennoch solche (sinnfreien?) Warnungen 
aus?


mfg

[Krapao (Gast)]

Die Warnung ist nicht sinnfrei. Du musst überlegen, ob dein Projekt das 
angewarnte Problem betreffen kann. Bei volatile Variablen kann es sehr 
wohl eine Rolle spielen, welche der Variablen in einem Ausdruck zuerst 
abgefragt wird.

Wenn du lokale Kopien verwenden kannst, legst du dadurch die Reihenfolge 
der Zugriffe fest. Eine andere Methode wäre, die Zugriffe auf Var_1 und 
Var_2 atomar zu machen, also z.B. Interrupts zu sperren, die Var_1 und 
Var_2 ändern. A propos atomar - ist ein uint16_t Zugriff auf deinem 
Target atomar?

[Warnung (Gast)]

aah, ok, danke.

gibt es noch weitere Fälle außer einem möglichen Interrupt, der auf das 
Ergebnis Einfluss ausüben könnte?


auf was möchtest du mit der Frage hinweisen, ob die uint16_t atomar 
sind?

welche Konsequenzen bringt diese Eigenschaft für meinen Programmablauf 
mit sich?

mfg

[Thomas E. (thomase)]

Warnung schrieb:
> volatile uint16_t Var_1;
> volatile uint16_t Var_2;
>   .
>   .
>   .
> Var_1 = (Var_1 + Var_2)/2;

Warnung schrieb:
> Warum also gibt mir der Compiler dennoch solche (sinnfreien?) Warnungen
> aus?
Warum stellst du hier einen völlig sinnfreien Codefetzen rein?

mfg.

[Krapao (Gast)]

> auf was möchtest du mit der Frage hinweisen, ob die uint16_t atomar
> sind?

Ob du dir schon Gedanken dazu gemacht hast, als du die Zeile oben so 
schrieben hast.

Bei einem 8-Bit AVR, den ich von den µCs am häufigsten programmiere, 
sind uint16_t Zugriffe nicht atomar und bei den daraus möglichen Bugs 
kann man sich tot suchen z. B. wenn entweder das MSB oder das LSB eines 
uint16_t Werts zwischen "dem Lesezugriff" (= mehrere Zugriffe auf 
ASM-Ebene) aktualisiert wurde. In deinem Fall betrifft das sogar zwei 
Variablen.

[Uli (Gast)]

Eigentlich muesste es genügen, die Variablen direkt im Statement nach 
uint16 zu casten, um die Warnungen loszuwerden. (zumindestr eine davon)
etwa in der Art

> Var_1 = (((uint16_t)Var_1) + Var_2)/2;

Und ansonsten wäre ich auch echt vorsichiig mit der Annahme "sinnfrei", 
speziell im Umfeld "volatile".

beste Grüße