www.elektronik.si

[Glitch]

Res sem ga spregledal, zato sem prvotni post zbrisal in povzel ugotovitve, ki so bile podane v razlicnih postih. Si ravno pisal odgovor med mojo spremembo

[alessio]

[alessio]

OK, Glitch, očitno prihaja do race condition-ov.

[Glitch]

(to je semafor)

oz.

[alessio]

[Glitch]

Hm... Don't let me download and install dev. tools here man!!!!!!

Kdo lahko proba static?

Tisto o semaforju, hotel sem povedati, da tisti smajli pomeni semafor, pa sem se spomnil kar na konkretno kodo.

[alessio]

Rezultat prevajanje z deklaracijo static volatile int c; :

[Sokrat]

Da ne bo cisto iztrgano iz konteksta: za "..." si lahko predstavlja vsak svoje. Napisi cel prevedeni listing, ki je v bistvu lahko podoben zdjasnjemu, seveda bos pa tudi c uporabil nekje v glavnem programu (sicer je razumljivo da njo in vse kar se nanasa nanjo prevajalnik odoptimizira stran, ce ni uporabljena, zanko pa pac pusti, ker je i volatile in jo mora obravnavati).

Na podlagi takega konkretnega (nic oskubljenega) listinga se potem pogovarjamo dalje. Ni treba tvojega celega programa, samo toliko konkreten naj bo, da se prikaze napaka.

[Glitch]

Sem pogledal ja. Zanimivo branje, ni kaj. To moram pokazat nekomu, ki je strasno obcutljiv na gcc tematiko

Kakorkoli ze, kot jaz vidim problematiko tega je, da c ni tretiran kot memory system variable. Je v registru, tudi stack se mi tudi zdi samo virtualni pomnilniski hranilnik, ki virtualno prevzame vlogo globalno vidnost za vse kar sledi po deklaraciji znotraj {}.
Kot je v claniku tudi povedano, nekako sploh ni jasno definirano kaj to je, kako se tretira itd. Se mi zdi, da je najbolj pomembna tocka clanka ravno poglavje 7.5.

Zato sem toliko spraseval kaj to je memory system. V primeru globalnik spremenljiv in registrov pa to dejansko so pomnilniske lokacije, nekje tam... Here be dragons lokacija, pazi kaj delas

V primerih v clanku so spremenljivke deklarirane z volatile vedno izven funkcij, kjer se jih uporablja, vidnost pa ceprav na stacku se postavi kot lokalno globalna (kot sem napisal prej). Se vedno pa ostaja problem, da tudi v teh primerih pride do napak, kjer je ocitno, da ne sme mesetarit po pomnilniku, ceprav je stack.

Ampak... ne da mi miru ta primer. Moram rect, da je res nesrecno zloben Je realna koda taka? Spremenljivko c bos menda uporabil. Mogoce bi se razvijalci prevajalnikov izvlekli s tem, da recejo, da je prevajalnik namenjen realni in uporabni kodi. Hehe.

Drugace pa, novi gcc ima atribut za funkcije s katerim za vsako funkcijo posebej definiras nivo optimizacije. Ohranjas modularno/logicno strukturo in kontroliras kriticne dele hkrati.

[gregoral]

Smo se pa razpisali .

Ja volatile je zelo pomembna zadeva še posebaj pri embedded projektih in kadar pišemo gonilnike.

Kot sem že enkrat napisal in smo že ugotovili na praktičnem primeru, je volatile namenjen globalnim spremenljivkam.

Po mojem je uporaba volatile pri lokalnih spremenljivkah v "twilight zone". Nekateri prevajalniki v takem primeru tudi javijo napako.

Torej jaz mislim da je škoda zgubljat čas z razglabljanjem če je to prav ali ne. Ker se mi zdi da se strinjamo, da je volatile namenjen globalnim spremenljivkam, bi se osredotočil na ta primer uporabe.

Pravilo bi se torej glasilo: Uporabljaj volatile le z globalnimi spremenljivkami.

Če kljub temu pride do težav zaradi optimizacije, pa nemudoma poročat .

LP,G

[Glitch]

[gregoral]

Uporaba volatile za števec znotraj zanke mi je čudna. Kdaj bi to zares rabil?

Glitch, če v volatile spremenljivko 10x zapišeš isto konstanto tega prevajalnik ne bi smel optimizirat, ker je HW lahko narejen tako, da ob vsakem pisanju na določeno lokacijo recimo nekaj naredi. Tega prevajalnik ne more vedeti, zato ne sme optimizirat.

Mislim pa, da je bil volatile dodan v C kasneje in ni ravno najbolj posrečeno definiran, saj obstaja precej sivih lis v specifikaciji, ki niso natančno določene.

Glede globalnih spremenljivk se strinjam, da se jih je treba izogibat. Samo če je to dejansko kontrolni register, ali pa se spremnljivka uporablja za komunikacijo / sinhronizacijo med main in isp, pa je uporaba smiselna.

[Glitch]

[gregoral]

Zdravo!

Jaz res ne vem kdaj bi bilo dobro imeti števec v zanki volatile:

[Glitch]

Podobno kot prejsni problemi. Vzami primer, ko v zanki samo nekaj preverjas in ne zelis neskoncnega izvajanja oz. zelis imeti stevec dogodkov, spremenljivka v zanki pa je taksna kot je in nimas kontrole nad njo.

Ampak ne zelim povedati, da i mora biti volatile. So samo doloceni primeri, ki pomagajo, da zadeve ne zoptimizira. Odvisno od sistema in prevajalnika, v dolocenih primerih bo i namesto v registru postavljen nekam v pomnilnik.