---

Hej,

Der er vist noget jeg ikke ved om "volatile"

volatile int a, b
<cut>
if (a+b > 100)
giver:
Warning[Pa082]: undefined behavior: the order of volatile accesses is
undefined in this statement.

Jeg trode at volatile bare betød at optimizeren skulle holde snitterne væk.
Især fra at optimere en skrivning væk pga en dead assignment (nyttig ifb med
debugging).

Er det en warning som IAR har fundet på, eller har det én eller anden
forankring i standarder?

tpt

---

"Troels Thomsen" <nej tak ...> wrote in message
news:4575b562$0$20234$edfadb0f@dread16.news.tele.dk...

[8<8<8<]
> Jeg trode at volatile bare betød at optimizeren skulle holde snitterne
> væk. Især fra at optimere en skrivning væk pga en dead assignment (nyttig
> ifb med debugging).

volatile betyder at variablens værdi kan ændre sig uden at compileren har
mulighed for at vide noget om det - f.eks. i en interupt-rutine.
Derfor må compileren ikke optimere læsninger væk.

>
> Er det en warning som IAR har fundet på, eller har det én eller anden
> forankring i standarder?

Umiddelbart forstår jeg ikke den warning.

Venlig hilsen

Mogens Hansen

---

Troels Thomsen wrote:
> volatile int a, b
> <cut>
> if (a+b > 100)
> giver:
> Warning[Pa082]: undefined behavior: the order of volatile accesses is
> undefined in this statement.

Ordene "undefined behaviour" er noget sludder her. Men advarslen er
fornuftigt nok: Du har ikke nogen garanti for at læsningen af a og b
sker i nogen bestemt rækkefølge, eller overhovedet at de bliver læst
sekventielt. Tilfældige omstændigheder, såsom ændringer i
optimeringsindstillinger, kan komme til at bytte om på rækkefølgen, da
der ikke er noget sequence point mellem de to læsninger.

Hvis det skrives om til
int a_ = a;
if (a_+b > 100)
så er der et sequence point ved semikolonet, og det er garanteret at a
læses før b.

mvh. Anders

---

> Men advarslen er
> fornuftigt nok:

Jeg forstår godt hvad du og de mener....men.... det gælder jo også
c = func1() + func2()
?

Dette eksempel giver ingen warnings.

Det er godt nok grim kode, hvis rækkefølgen betyder noget, men det gælder
vel også for eksemplet med to volatile objekter så?

mvh Troels

---

Troels Thomsen wrote:
> Det er godt nok grim kode, hvis rækkefølgen betyder noget, men det gælder
> vel også for eksemplet med to volatile objekter så?

Grunden er sikkert at volatile ofte bruges ved tilgang til hardware og
registre i processoren og i sådan en situation kan rækkefølgen have
betydning. Jeg har dog aldrig selv set sådan en warning før. Men
"undefines" skulle nok erstattes af "unspecified".

Ivan Johansen

---

>
> Grunden er sikkert at volatile ofte bruges ved tilgang til hardware og
> registre i processoren og i sådan en situation kan rækkefølgen have
> betydning. Jeg har dog aldrig selv set sådan en warning før. Men
> "undefines" skulle nok erstattes af "unspecified".
>

Jeg kan komme i tanke om et uart-register på en processor hvor
errorflag-registeret cleares autmatisk når man _læser_ data-registeret. Men
jeg synes sq det er sjældent.

tpt

---

Troels Thomsen wrote:
>> Men advarslen er
>> fornuftigt nok:
>
> Jeg forstår godt hvad du og de mener....men.... det gælder jo også
> c = func1() + func2()
> ?
>
> Dette eksempel giver ingen warnings.

Nej men det kunne det i princippet godt. For det er ikke givet om func1
eller func2 udføres først, så hvis begge funktioner har observerbare
sideeffekter, så er det usikkert i hvilken rækkefølge de bliver udført.

Det ville bare give en forfærdelig masse falske positive hvis compileren
gav en warning hver eneste gang der er to funktionskald i samme udtryk,
så det gør den ikke. Men når du højt og klart har erklæret at
rækkefølgen er særligt interessant for netop de her to variabler, ved at
erklære dem volatile, så lytter compileren naturligvis efter.

mvh. Anders

---

> Men når du højt og klart har erklæret at rækkefølgen er særligt
> interessant for netop de her to variabler, ved at erklære dem volatile, så
> lytter compileren naturligvis efter.

Jeg mener ikke at man kan finde NOGEN hints i C99 standarden til at volatile
skulle betyde dette.

Alene fraværet af posts fra nogle af gruppens hårde gutter i denne retning,
er et vægtigt indicie herfor
Jeg har også selv søgt efter volatile i standarden, og ikke fundet noget i
denne retning.

Jeg har dog fået det bedre og bedre med denne tilføjelse. Hvis man ser lidt
pragmatisk på det, så er det vist bare en god ide !
Min oprindelige anke var at de har en speciel opfattelse af hvad volatile
betyder, men det gør egentlig ikke så meget idet man kun kan "komme til" at
skrive bedre kode pga denne warning. Koden vil aldrig virke forkert hvis det
kompileres med en anden compiler, etc etc.
Der er andre ting der også har lidt anderledes betydning på embeddede
systemer, eksempelvis "const".


tpt

---

Den Sat, 9 Dec 2006 14:32:59 +0100 skrev Troels Thomsen:
>
>
>> Men når du højt og klart har erklæret at rækkefølgen er særligt
>> interessant for netop de her to variabler, ved at erklære dem volatile, så
>> lytter compileren naturligvis efter.
>
> Jeg mener ikke at man kan finde NOGEN hints i C99 standarden til at volatile
> skulle betyde dette.

Som jeg har lært det (uden dog ar have læse standarden) betyder volatile
at værdien kan ændre sig uden compileren ved det, og derfor ikke må
gemmes i et register, men skal læses hver gang den bruges.

Der er kun to muligheder for hvordan en værdi kan ændre sig uden
compileren ved det - software (threads) eller hardware-registre. Og
rækkefølgen kan netop være vigtig ved hardware-regstre. Så selvom det
ikke måske direkte står i standarden, så er det underforstået, i og
med at der hvor man har brug for volatile kan det være relevant. Men
det er hardwaren der afgør om rækkefølgen har nogen betydning eller
ej, ikke C-standarden.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

> Så selvom det
> ikke måske direkte står i standarden, så er det underforstået

IAR er så vidt vides de eneste der laver denne warning, ud af de tusinder af
C compilere der er blevet lavet i tidens løb. Så at det ligefrem skulle være
underforstået synes jeg er at stramme den lidt.

At det så er en god ide alligevel, synes jeg er en anden sag.

tpt

---

Den Sat, 9 Dec 2006 21:14:57 +0100 skrev Troels Thomsen:
>
>> Så selvom det
>> ikke måske direkte står i standarden, så er det underforstået
>
> IAR er så vidt vides de eneste der laver denne warning, ud af de tusinder af
> C compilere der er blevet lavet i tidens løb. Så at det ligefrem skulle være
> underforstået synes jeg er at stramme den lidt.

Det er underforstået at rækkefølgen kan være vigtig. Om compileren så
laver en warning om det, er op til dem der laver compileren.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

"Kent Friis" <nospam@nospam.invalid> wrote in message
news:457b208e$0$49203$14726298@news.sunsite.dk...

[8<8<8<]
> Det er underforstået at rækkefølgen kan være vigtig.

volatile betyder at variablens værdi kan ændre sig uden at det er
specificeret af programmet.
Derfor skal compileren afstå fra at optimere læsninger væk.

Om rækkefølgen af at læse flere uafhængige volatile variable er
betydningsfuldt eller ej kan man ikke sige noget generelt om.
Man vil kunne finde eksempler hvor det er betydningsfuldt og eksempler hvor
det er ligegyldigt.

Venlig hilsen

Mogens Hansen

---

Den Sun, 10 Dec 2006 16:29:12 +0100 skrev Mogens Hansen:
>
> "Kent Friis" <nospam@nospam.invalid> wrote in message
> news:457b208e$0$49203$14726298@news.sunsite.dk...
>
> [8<8<8<]
>> Det er underforstået at rækkefølgen kan være vigtig.
>
> volatile betyder at variablens værdi kan ændre sig uden at det er
> specificeret af programmet.
> Derfor skal compileren afstå fra at optimere læsninger væk.
>
> Om rækkefølgen af at læse flere uafhængige volatile variable er
> betydningsfuldt eller ej kan man ikke sige noget generelt om.
> Man vil kunne finde eksempler hvor det er betydningsfuldt og eksempler hvor
> det er ligegyldigt.

Og dermed *kan* det være vigtigt. Compileren har ingen mulighed for
at vide hvornår det er vigtigt og hvornår det ikke er. Så dem der
laver compileren har to muligheder: Give en warning, eller ignorere
problemet.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Troels Thomsen wrote:
>> Men når du højt og klart har erklæret at rækkefølgen er særligt
>> interessant for netop de her to variabler, ved at erklære dem volatile, så
>> lytter compileren naturligvis efter.
>
> Jeg mener ikke at man kan finde NOGEN hints i C99 standarden til at volatile
> skulle betyde dette.

Jeg ved ikke hvordan C99 udtrykker det, men i ISO/IEC 14882:1998(E)
1.9/7 står der:

"Accessing an object designated by a volatile lvalue [med mere] are all
side effects [...]. At certain specified points in the execution
sequence called sequence points, all side effects of previous
evaluations shall be complete and no side effects of subsequent
evaluations shall have taken place."

Det er det helt præcise rækkefølgekrav, og det er præcis, hvad IAR
compileren leverer. (Det eneste, der kunne være åbent for fortolkning,
er hvad der udgør en "access", men i praksis er det klart nok.)

> Alene fraværet af posts fra nogle af gruppens hårde gutter i denne retning,
> er et vægtigt indicie herfor

Hårde gutter poster ikke me-too-indlæg.

mvh. Anders

---

Den Sun, 10 Dec 2006 18:28:53 +0100 skrev Anders J. Munch:
>
> Jeg ved ikke hvordan C99 udtrykker det, men i ISO/IEC 14882:1998(E)
> 1.9/7 står der:
>
> "Accessing an object designated by a volatile lvalue [med mere] are all
> side effects [...].

Så er det jo ikke engang underforstået at rækkefølgen kan være relevant,
det fremgår af ordet "side effect", så meget som det nu kan uden at
beskrive den fysiske hardware direkte i standarden.

Et eksempel på side effects: printf() returnerer antallet af tegn
der bliver skrevet. Som sideeffekt bliver disse tegn skrevet på
skærmen.

Der er vel ingen der er i tvivl om at rækkefølgen af sideeffekter
kan være vigtig - hvis man kalder printf to gange, og compileren bytter
om på den, kommer der til at stå noget helt andet.

Og så kunne jeg da egentlig godt tænke mig at vide om compileren også
må bytte om på to funktionskald hvis der står + imellem? Hvis jeg fx
skriver a=printf("hello ")+printf("world "); må den så skrive
"world hello "? Eller er funktionskald specielle i denne sammenhæng?

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis wrote:
>
> Og så kunne jeg da egentlig godt tænke mig at vide om compileren også
> må bytte om på to funktionskald hvis der står + imellem? Hvis jeg fx
> skriver a=printf("hello ")+printf("world "); må den så skrive
> "world hello "? Eller er funktionskald specielle i denne sammenhæng?

Ja, den må godt skrive "world hello ". Der hvor det sædvanligvis bider
folk er ved funktionsargumenter - dvs. når de skriver:

f(printf("hello "), printf("world "));

Der er ikke sequence points mellem argumenter, så det kan skrive både
det ene og det andet. Og hvad værre er, ikke bare har det lov til at
skrive "world hello ", men det sker faktisk ofte i praksis, fordi der er
kald-konventionener der foreskriver at argumenterne stakkes fra højre
mod venstre.

Bare så folk ikke skal tro, at det hele flyder, må jeg lige skynde mig
at nævne at der udover mellem sætninger er sequence points ved starten
og slutningen af funktionskald, og ved &&, || og ?:, af hvad jeg lige
kan huske. Så det er ikke _helt_ tilfældigt hvad der foregår

mvh. Anders

---

Den Mon, 11 Dec 2006 19:01:00 +0100 skrev Anders J. Munch:
> Kent Friis wrote:
>>
>> Og så kunne jeg da egentlig godt tænke mig at vide om compileren også
>> må bytte om på to funktionskald hvis der står + imellem? Hvis jeg fx
>> skriver a=printf("hello ")+printf("world "); må den så skrive
>> "world hello "? Eller er funktionskald specielle i denne sammenhæng?
>
> Ja, den må godt skrive "world hello ".

Jeg havde nok en mistanke...

> Der hvor det sædvanligvis bider
> folk er ved funktionsargumenter - dvs. når de skriver:
>
> f(printf("hello "), printf("world "));
>
> Der er ikke sequence points mellem argumenter, så det kan skrive både
> det ene og det andet. Og hvad værre er, ikke bare har det lov til at
> skrive "world hello ", men det sker faktisk ofte i praksis, fordi der er
> kald-konventionener der foreskriver at argumenterne stakkes fra højre
> mod venstre.
>
> Bare så folk ikke skal tro, at det hele flyder, må jeg lige skynde mig
> at nævne at der udover mellem sætninger er sequence points ved starten
> og slutningen af funktionskald,

Altså for de ting der står inde i funktionen? Ovenstående er jo netop
funktionskald (printf).

> og ved &&, || og ?:,

Det er jo nødvendigt at evaluere dem i den rigtige rækkefølge, når
resultatet af den ene side bestemmer hvorvidt den anden side skal
evalueres.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

Kent Friis wrote:
> Den Mon, 11 Dec 2006 19:01:00 +0100 skrev Anders J. Munch:
>>
>> f(printf("hello "), printf("world "));
[...]
>> Bare så folk ikke skal tro, at det hele flyder, må jeg lige skynde mig
>> at nævne at der udover mellem sætninger er sequence points ved starten
>> og slutningen af funktionskald,
>
> Altså for de ting der står inde i funktionen? Ovenstående er jo netop
> funktionskald (printf).

Ja. Sagt med andre ord, hvert funktionskald udføres i isolation, så
ovenstående må ikke udskrive "hwellrlo d " eller sådan noget.

- Anders

---

>
>> og ved &&, || og ?:,
>
> Det er jo nødvendigt at evaluere dem i den rigtige rækkefølge, når
> resultatet af den ene side bestemmer hvorvidt den anden side skal
> evalueres.
>

Mener du at det er forbudt for compileren at evaluere begge sider, og så
and'e resultaterne til sidst ?

Hvis blot sideefekterne af den ene side er afsluttet, må den ifølge citatet
gerne evaluere den anden side også !

tpt

---

Den Mon, 11 Dec 2006 19:34:17 +0100 skrev Troels Thomsen:
>>
>>> og ved &&, || og ?:,
>>
>> Det er jo nødvendigt at evaluere dem i den rigtige rækkefølge, når
>> resultatet af den ene side bestemmer hvorvidt den anden side skal
>> evalueres.
>>
>
> Mener du at det er forbudt for compileren at evaluere begge sider, og så
> and'e resultaterne til sidst ?

Ja.

if(x && *x) printf("%s\n",x);

> Hvis blot sideefekterne af den ene side er afsluttet, må den ifølge citatet
> gerne evaluere den anden side også !

x == NULL /* false */
*x == segmentation fault, core dumped.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

> if(x && *x) printf("%s\n",x);
>

Ok,
Andet eksempel på det samme, checket på samme IAR compiler.

if ( func1() && 0 )
Func1 bliver kaldt, optimizeren er slået helt fra iøvrigt.

if ( 0 && func1() )
Func1 bliver ikke kaldt

tpt

---

>
> Og så kunne jeg da egentlig godt tænke mig at vide om compileren også
> må bytte om på to funktionskald hvis der står + imellem?
>

Man kunne også spørge, om compileren virkelig er tvunget til at generere
funktionskald fra venstre mod højre hvis der står + imellem. Det betyder det
samme, men har omvendt bias.

Ja det har jeg altid gået ud fra, og der var ingen der modsagde mig i posten
fra 5/12.
Men nu er min forståelse af sequence points jo til review i en anden post
fra d.d.

tpt

---

Den Mon, 11 Dec 2006 19:16:30 +0100 skrev Troels Thomsen:
>>
>> Og så kunne jeg da egentlig godt tænke mig at vide om compileren også
>> må bytte om på to funktionskald hvis der står + imellem?
>>
>
> Man kunne også spørge, om compileren virkelig er tvunget til at generere
> funktionskald fra venstre mod højre hvis der står + imellem. Det betyder det
> samme, men har omvendt bias.

Min formulering af spørgsmålet indikerede ikke (bevidst) nogen bias. Din
formulering opfatter jeg derimod som om at det logiske er at compileren
har frit valg, men at noget i standarden indikerer at det ikke skulle være
tilfældet.

Før jeg læste citatet fra standarden havde jeg overhovedet ikke tænkt
på muligheden, og da jeg læste den, var det logiske at det må compileren
godt. Jeg skulle bare lige høre om det var korrekt opfattet, eller der
var en undtagelse i et andet afsnit.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

> Min formulering af spørgsmålet indikerede ikke (bevidst) nogen bias.

Det var også bare for at vende tingene på hovedet. Ikke for at være flabet.

tpt

---

Den Mon, 11 Dec 2006 19:30:49 +0100 skrev Troels Thomsen:
>
>> Min formulering af spørgsmålet indikerede ikke (bevidst) nogen bias.
>
> Det var også bare for at vende tingene på hovedet. Ikke for at være flabet.

Ok. Det gav bare en lidt anden betydning i mine øjne.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

> At certain specified points in the execution sequence called sequence
> points, all side effects of previous evaluations shall be complete and no
> side effects of subsequent evaluations shall have taken place."

Ok, dette læste jeg godt, og forstod det på flg måde :

volatile int a,b,c,d;
result1 = a + b ; // semikolon'et udgør sequence point A
result2 = c + d ;

Står der ikke at sideeffekterne af læsningerne af a og b skal være overstået
ved sequence point A (previous evaluations), og sideeffekterne af c og d
(subsequent evaluations) må endnu ikke være sket ?

tpt

---

Troels Thomsen wrote:
>> At certain specified points in the execution sequence called sequence
>> points, all side effects of previous evaluations shall be complete and no
>> side effects of subsequent evaluations shall have taken place."
>
> Ok, dette læste jeg godt, og forstod det på flg måde :
>
> volatile int a,b,c,d;
> result1 = a + b ; // semikolon'et udgør sequence point A
> result2 = c + d ;
>
> Står der ikke at sideeffekterne af læsningerne af a og b skal være overstået
> ved sequence point A (previous evaluations), og sideeffekterne af c og d
> (subsequent evaluations) må endnu ikke være sket ?

Netop, ja.

- Anders

---

>
> Netop, ja.
>

Så hvor er det at volatile betyder at
"at rækkefølgen er særligt interessant for netop de her to variabler"

tpt

---

Den Mon, 11 Dec 2006 19:32:35 +0100 skrev Troels Thomsen:
>>
>> Netop, ja.
>>
>
> Så hvor er det at volatile betyder at
> "at rækkefølgen er særligt interessant for netop de her to variabler"

Volatile betyder i sig selv at der kan være sideeffekter. Compileren
gør bare opmærksom på at den ikke garanterer rækkefølgen af disse.

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

>
> Volatile betyder i sig selv at der kan være sideeffekter. Compileren
> gør bare opmærksom på at den ikke garanterer rækkefølgen af disse.
>

Og hvorfor er det at den ikke skal gøre det ved funktionskald så ?

tpt

---

Den Mon, 11 Dec 2006 19:40:09 +0100 skrev Troels Thomsen:
>
>>
>> Volatile betyder i sig selv at der kan være sideeffekter. Compileren
>> gør bare opmærksom på at den ikke garanterer rækkefølgen af disse.
>>
>
> Og hvorfor er det at den ikke skal gøre det ved funktionskald så ?

"Skal gøre"? Der er ingen der siger at compileren *skal* give en
warning, kun at der er grund til at gøre det.

Det er der for så vidt også ved funktionskald, det kommer an på
funktionen. De fleste funktioner er enten eller - dem der har
sideeffekter bruges normalt ikke i en beregning (som mit eksempel
med printf()+printf(), hvor tit ser man lige det?), og dem der
bruges i beregninger har ingen sideeffekter.

Compileren kan ikke se forskel, og da langt de fleste funktionskald
ikke giver problemet, er der ingen grund til at give en warning. At
gøre det ville give 100-vis af uinteressante warnings, og selv hvis
der var en enkelt imellem hvor det er et problem, ville man ikke
opdage det fordi den er gemt imellem de andre.

Med variable kan compileren derimod se forskel på variable med
sideeffekter (volatile) og uden (ikke volatile).

Mvh
Kent
--
"So there I was surrounded by all these scary creatures
They were even scarier than what Microsoft call features"
- C64Mafia: Forbidden Forest (Don't Go Walking Slow).

---

>>
>> Og hvorfor er det at den ikke skal gøre det ved funktionskald så ?
>
> "Skal gøre"? Der er ingen der siger at compileren *skal* give en
> warning, kun at der er grund til at gøre det.
>

Nu skal vi heller ikke koge ret meget mere suppe på den ged. Vi er vel 99%
enige, den sidste procent bunder måske i graden af hvor indlysende
referencerrne til standarden er.

Ikke om det er en god ide eller ej, for det synes jeg også det er.

tpt

---

Troels Thomsen wrote:
>> Netop, ja.
>>
>
> Så hvor er det at volatile betyder at
> "at rækkefølgen er særligt interessant for netop de her to variabler"

Det er en fortolkning. Hvis du fortolker det anderledes, så skal du være
velkommen til det.

- Anders