Podivný překlad v Atmel studiu

[Jirka525]

Potřeboval jsem pracovat postupně s jednotlivými bity int čísla. Vytvořil jsem si tedy proměnnou maska, pomocí které jsem chtěl vybírat jednotlivé bity.
unsigned int maska = 0x8000;
.
.
maska >>= 1;
.
.
očekával jsem že po jednotlivých průchodech budu postupně dostávat masku 0x4000, 0x2000, 0x1000 a pod.
Místo toho jsem dostával 0xc000, 0xe000, 0xf000 a pod.
záhada se vysvětlila, když jsem se podíval do kódu v assembleru. Kompilátor to přeložil následovně:
ASR R25
ROR R24

Chvíli jsem se s tím trápil a pak jsem rezignoval a přepsal zdrojový kod takhle:
pom2 = (maska >> 1);
maska = pom2;
Kompilátor vyměnil insrukci ASR za LSR a vše pracovalo, tak, jak jsem potřeboval. Není to pochopiteně velký problém ale já z principu nerad sviním zdrojový kód zbytečným textem. Zbytečně to bobtná a komplikuje to údržbu. Tak bych rád, pokud to jde, sdělil kompilátoru že nehodlám dělit 2 ale skutečně chci jen posunout bity ve slově. Nevíte někdo, jak to zařídit?
Díky Jirka.

[berk]

Asi nějaká chybka kompilátoru.

co udělá thohle?

maska = (maska >> 1);

[Jirka525]

Přeložilo s to stejně jako
maska >>= 1;
tedy
ASR R25
ROR R24

[berk]

Hmm je to zvláštní.

Asi bych to zareportoval na support od toho kompilátoru. Co je to vlastně zač?

[AB1]

[frpr666]

Mě to funguje normálně: {0x4000,0x2000,...}
Testováno v AvrStudio, WinAvr, Simulator, optimalizace -O0

[AB1]

[Jirka525]

Děkuji za radu. máte pravdu oba AB1 i FRPR666. Já jsem problém popsal zjednodušeně. Ve skutečnosti byla proměnná maska deklarována jako int a v různých místech programu se s mí paracovalo jako s int. Posun jsem dělal ve funkci posun, která dostávala jako parametr proměnnou maska.

int posun(maska)
{
unsigned int maska2;
maska2 = maska;
maska2>>=1;
return maska2;
}

neni to úplně přesné ale principielně to bylo napsáno asi takto. Když jsem to opravil, tj. deklarace unsigned int a práce s proměnnou jako unsigned int, tak to začalo fungovat.
díky Jirka

[mtajovsky]

Jenom pozor na to, že uvedená situace má implementačně závislý výsledek. Nejčastější implementace je právě uvedená, tj. při posuvu znaménkového integrálního typu vpravo se doplňuje znaménkový bit a tak se zachovává znaménko čísla (představíme si, že záporné číslo má směrem doleva nekonečnou řadu jedničkových bitů). Ovšem C++ ISO specifikace pro operátor >> v odstavci 5.8.3 uvádí, že výsledek je implementačně závislý:

"The value of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a non-negative value, the value of the result is the integral part of the quotient of E1/2^E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined."

Z uvedeného dále vyplývá, že operace >> ve skutečnosti není bitový posuv, ale dělení mocninou 2. Pro čísla uspořádaná little endian (LSB vpravo), což je dnes častý případ, se rozdíl stírá, ovšem pro big endian je to zřetelné. Ač je uspořádání bitů opačné, přesto číselný výsledek >> bude stejný. Obdobně to platí i pro operátor <<.

Toto vlákno ukazuje, jak je důležité dodržovat typovou disciplínu a řešit všechna varování překladače. Už samotné použití

int x;

v oblasti mikrokontrolérů není vzhledem k možné rozmanitosti architektur bezpečné a používaný typ by měl vyjadřovat velikost v bitech. Osobně používám makra, definující typy jako:

u08, s08, u16, s32, float32 a podobně.

[mtajovsky]

Jenom pozor na to, že uvedená situace má implementačně závislý výsledek. Nejčastější implementace je právě uvedená, tj. při posuvu znaménkového integrálního typu vpravo se doplňuje znaménkový bit a tak se zachovává znaménko čísla (představíme si, že záporné číslo má směrem doleva nekonečnou řadu jedničkových bitů). Ovšem C++ ISO specifikace pro operátor >> v odstavci 5.8.3 uvádí, že výsledek je implementačně závislý:

"The value of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a non-negative value, the value of the result is the integral part of the quotient of E1/2^E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined."

Z uvedeného dále vyplývá, že operace >> ve skutečnosti není bitový posuv, ale dělení mocninou 2. Pro čísla uspořádaná little endian (LSB vpravo), což je dnes častý případ, se rozdíl stírá, ovšem pro big endian je to zřetelné. Ač je uspořádání bitů opačné, přesto číselný výsledek >> bude stejný. Obdobně to platí i pro operátor <<.

Toto vlákno ukazuje, jak je důležité dodržovat typovou disciplínu a řešit všechna varování překladače. Už samotné použití

int x;

v oblasti mikrokontrolérů není vzhledem k možné rozmanitosti architektur bezpečné a používaný typ by měl vyjadřovat velikost v bitech. Osobně používám makra, definující typy jako:

u08, s08, u16, s32, float32 a podobně.