Ceckarsky kviz III

[Jan Kral]

Tech hodnot 0x7fff to melo podle me nabyvat proto, ze v nejvyssim bitu je ulozeno znamenko. To ze se zapnutymi optimalizacemi se to chova jinak nez pri vypnutych optimalizacich jste zminil az ted.

Takze v tom pripade je moje prvni uvaha o znamenku spatne a zrejme se prostym pricitanim k int promenne meni hodnota v plnem rozsahu a prekladac nema duvod neco zkrouhnout.
Spis to bude tim, ze prekladac pri optimalizaci se domniva, ze vzhledem k predchazejicimu i++ nemuze dojit k tomu, ze by bylo znamenko nekdy zaporne a tudiz tento test nedela a provadi natvrdo jen tu jednu vetev, druhou vubec do prekladu nezahrne. A to jeste v tom lepsim pripade, protoze vzhledem k while (1) a opakovanem nastavovani stejne hodnoty na port muze dojit pri optimalizaci k tomu, ze udela nastaveni te hodnoty a teprve potom udel aprazdny cyklus while (1)


S pozdravem JK

> 
> >> >Pripadne je mozne delat test ne na 0x8000, ale na 0x4000 
> a pak to fungovat bude. 
> >> 
> >> To je pravda.
> >> 
> >> >Jestli to chcete na plnou hubu, tak to bude tim, ze 
> promenna typu int a delku 2 byty bude nabyvat ve zminem 
> prikladu hodnot 0-0x7fff.
> >> 
> >> Hmmmm... Mozete to prosim odovodnit?
> >
> >Zrejme prekladac hodnotu 0x8000 zkrouhne na 0x0000, protoze 
> se "nevleze" do daneho
> >typu?
> 
> 
> No, znie to sice vierohodne, ale teraz pride pointa: povodny 
> autor otazky experimentoval s nastaveniami prekladaca, a 
> zistil, ze ak sa preklada so zapnutymi optimalizaciami, tak 
> LEDka neblika.
> 
> Lenze ak sa preklada s vypnutymi optimalizaciami, tak LEDka blika.
> 
> Myslite, ze *zapnutim* optimalizacie sa *prida* operacia 
> ("zkrouhnutie")?
> 
> wek
>