Kviz - podivna chovani programu pro 8bitove uP

[Jan Kral]

Velmi dobre, je fakt, ze ten posledni test na -400 mel byt spis nekde kolem -200. Tento test je z duvodu ke ktere casti promenne se prekladac rozhodne driv pro jeji natazeni z pameti. Takze uplne spravna odpoved pri testu na -400 by mela byt ze to zalezi na tom jak to prekladac prelozi. S nekterym prekladacem 100, s jinym 10 :-)). Ale jinak naprosto presne.

Zajimalo by, kolik programatoru v Ccku a pod s temito variantami pocita a jak se to ma spravne resit. Ja co programuji v asm si pred nactenim hodnot z RAM zakazu preruseni a po jej opet povolim. Tohle jsem resil v jiz hotovem programu a cteni hodnoty jsem obalil nastavenim a snulovanim promenne, kterou testuji pred updatem counteru v preruseni a v tom problemovem pripade jsem aktualizaci neprovedl.

Jinak muzu rict, ze takovato chyba se v hotovem programu hleda dost blbe, zvlast kdyz update hodnoty "counter" probiha na zaklade nejakych vnejsich podminek. 

JK

> 
> Ahaho, problem "atomicity", v kombinacii s pouzitim 
> nevhodneho datoveho 
> typu v - s prepacenim - vyssom jazyku. Toto by sa malo 
> rozdavat vsetkym 
> adeptom programovania ako psia znamka na krk.
> 
> Toto je klasicky ucebnicovy priklad premennej (counter), ktora je v 
> maine pouzita (tu: testovana, pouzita v odcitani) prerusitelnou 
> sekvenciou instrukcii - a pouziva sa (tu: meni) aj v preruseni. Este 
> dobre, ze s premenna counter sa v main-e nemeni, to by mohlo byt este 
> zaujimavejsie :-) Ale existuju aj zakernejsie verzie, napr. ak su dve 
> premenne sice pouzivane "atomicky" ale musia zachovat nejaky vzajomny 
> vztah - klasicky priklad je obsah buffra a pointer nan...
> 
> Analyza:
> counter na zaciatku zmeni stav postupne z -22 na -40, pricom 
> sa v maine 
> (pri counter=-30) nastavi result na 10 - to je napokon 
> zamyslana funkcia 
>   (dostatocne rychle vykonavanie cyklu zaruci, ze sa to aspon raz 
> stane). potom counter nadobuda uz iba hodnoty 0 (= 0x0000), -1 (= 
> 0xFFFF), -2, -3, -4, -15, -16, -17, -18, -19 (= 0xFFED) a 
> znova 0 atd. 
> Ak nastane prerusenie "uprostred" pouzitia counter-a, main "vidi" bud 
> predchadzajuce LSB a nasledujuce MSB alebo naopak v zavislosti od 
> poradia pouzitia (pri kontrole zhody s konstantou to moze byt 
> akokolvek, 
> pri odcitani to bude zrejme LSB first aj ked to tiez nie je na 100%, 
> prekladac si moze napr. odkopirovat hodnotu pre odcitanie aj 
> v opacnom 
> poradi). V prvom pripade moze teda main "vidiet" okrem uz uvedenych 
> hodnot countera aj 0x00ED = 237 (pri prechode z -19 na 0) a 0xFF00 = 
> -256 (pri prechode z 0 na -1); v druhom pripade sa moze vyskytnut 
> "naviac" 0xFF00 = -256 a 0x00FF = 255.
> 
> Takze pripad A a B uz nenastane, prvy pripad C raz 
> pravdepodobne nastane 
> (zavisi to este od potencialneho synchronizmu prerusenia voci 
> "main"-u) 
> a druhy pripad C by tiez nemal nastat ("najzapornejsi" vysledok bude 
> -256-100 = -356. -10 ani -30 sa uz nevyskytne.
> 
> Takze "konecny" vysledok je 100.
> 
> Mno samozrejme sa mozem mylit ako obvykle...
> 
> wek