Poslední přidané názory v blogu Jet

Počítání s přetečením v C

Jet — Thu, 09 Oct 2014 17:58:02 GMT

Dekuji vsem diskutujicim za podmente pripominky, diky teto diskuzi jsem zjistil, ze gcc-avr podporuje i long long aritmetiku. Jaksi me nenapadlo, ze je to vlastne standard. Dal jsem zjistil, ze tento processor je osmibitovy a ne 32 bitovy - nejak jsem si prilis zvykl na ARM. Pak jsem zjistil, ze gcc-avr preklada naprosto nesmyslnym zpusobem i naprosto jednoduche long long scitani, viz [25]. Ale program fungoval, dokonce lepe nez na PIC, kde jsem to mel v assembleru. Ale nedalo mi to, pustil jsem se do optimalizaci. Nakonec jsem prepsal funkci sum do assembleru a rozepsal cykly ve volajici funkci, aby nerotovala 64 bitove, ale vzala si to byte po byte a rotovala po 8mi bitech. Doba vypoctu sla asi na ctvrtinu. Pritom jsem jeste zjistil, ze gcc-avr nedokaze odkazovat na registry long long. Odkazy se delaji %A pro nejnizsi byte, %B pro dalsi a tak dale az po %D, ktery odkazuje na nejvyssi registr longu. Ale jaksi zapomneli podporovat %E az %G. Takze temporary registry jsem musel udelat dva longove misto jednoho long long. No a ted ta funkce na scitani, secte dve unsigned long long cisla, a v navratove hodnote vrati carry: typedef unsigned long long ull;unsigned char sum(ull *r, const ull *a) // *r+=*a, returns carry{ unsigned long int r1; unsigned long int r2; asm volatile( "movw %[z],%[r]" LF "movw %[y],%[a]" LF "ld %A[tmp1],Z" LF "ldd %B[tmp1],Z+1" LF "ldd %C[tmp1],Z+2" LF "ldd %D[tmp1],Z+3" LF "ldd %A[tmp2],Z+4" LF "ldd %B[tmp2],Z+5" LF "ldd %C[tmp2],Z+6" LF "ldd %D[tmp2],Z+7" LF "ld __tmp_reg__, Y" LF "add %A[tmp1], __tmp_reg__" LF "ldd __tmp_reg__, Y+1" LF "adc %B[tmp1], __tmp_reg__" LF "ldd __tmp_reg__, Y+2" LF "adc %C[tmp1], __tmp_reg__" LF "ldd __tmp_reg__, Y+3" LF "adc %D[tmp1], __tmp_reg__" LF "ldd __tmp_reg__, Y+4" LF "adc %A[tmp2], __tmp_reg__" LF "ldd __tmp_reg__, Y+5" LF "adc %B[tmp2], __tmp_reg__" LF "ldd __tmp_reg__, Y+6" LF "adc %C[tmp2], __tmp_reg__" LF "ldd __tmp_reg__, Y+7" LF "adc %D[tmp2], __tmp_reg__" LF "st Z, %A[tmp1]" LF "std Z+1, %B[tmp1]" LF "std Z+2, %C[tmp1]" LF "std Z+3, %D[tmp1]" LF "std Z+4, %A[tmp2]" LF "std Z+5, %B[tmp2]" LF "std Z+6, %C[tmp2]" LF "std Z+7, %D[tmp2]" LF "clr %A[tmp1]" LF "rol %A[tmp1]" LF // carry -> tmp1 :[z]"=z"(r), [y]"=y"(a), [tmp1]"=r"(r1), [tmp2]"=r"(r2) :[r]"r"(r), [a]"r"(a) ); return r1; }

Počítání s přetečením v C

Pavel Tisnovsky — Thu, 09 Oct 2014 17:23:03 GMT

[42][43] jj já vím, ten komentář jsem napsal proto, že bych nezatracoval jiné interní formáty čísel a ALU operace. A zrovna u céčka, kde není jisté skoro nic (šířka charu například, již zmíněný aritmetický posun u signed hodnota atd. = a právě kvůli dvojkovému doplňku) je defenzivní přístup - resp. respektování normy - docela vhodné. FP16 si dovolím tvrdit, že docela dobře vím co je :-)

Počítání s přetečením v C

Jet — Thu, 09 Oct 2014 17:10:15 GMT

Ovsem v mem pripade potrebuji pocitat na 65 bitu, takze 64+carry. Algoritmus totiz vede na (a+b)%n, takze na neco jako result=a+b; if (carry || result>=n) result-=n; pricemz A i B jsou obe mensi nez N takze je vzdy (A+B)<2*N a vzhledem k tomu, ze a N>(1<<63), muze nastat carry

Počítání s přetečením v C

Kolemjdoucí — Thu, 09 Oct 2014 08:49:46 GMT

[41] Saturated neimplikuje nemožnost použít dvojkový doplněk a zrovna v DSP se dvojkový doplněk používá masivně. 16-bit float je něco úplně jiného než integer.

Počítání s přetečením v C

Kolemjdoucí — Thu, 09 Oct 2014 06:03:27 GMT

[41] Saturace je něco naprosto jiného, navíc není problém udělat saturaci na dvojkovém doplňku. Kratké FP je 16-bit floating point.

Počítání s přetečením v C

Pavel Tisnovsky — Wed, 08 Oct 2014 20:07:45 GMT

[39] ale to nahodou neni tak spatne, napriklad pro DSP je vubec add/sub s pretecenim naprosto spatna operace s principialne mnoha dost hroznymi nasledky ... Lepsi jsou pro mnoho aplikaci vypocty se saturaci. Anebo "kratke" FP, tak jak to delaji GPUcka :-)

Počítání s přetečením v C

BrainLess — Tue, 07 Oct 2014 12:17:23 GMT

A co tohle ? http://stackoverflow.com/questions/199333/best-way-to-detect-integer-overflow-in-c-c

Počítání s přetečením v C

Kolemjdoucí — Tue, 07 Oct 2014 08:19:31 GMT

[35] Pracky urážet každému, kdo udržuje při životě obskurdní architektury kde znaménkový integer je něco jiného než dvojkový doplněk. Prostě takový hardware se nekupuje a tyto problémy se neřeší. Obdobným přístupem už se podařilo vymýtit platformy s jinou délkou slova než 2^N a je to tak dobře. [38] Volatile je něco naprosto jiného jako atomické operace. Jestli používáte atomické operace tam kde stačilo volatile, potom je to mimořádně špatně.

Počítání s přetečením v C

JSH — Mon, 06 Oct 2014 15:58:00 GMT

[37] Pravda, tohle jsem zapomněl zdůraznit. Uspořádané jsou jen ty volatile přístupy a to jenom z pohledu optimalizací překladače. Ty nevolatile si mezi tím překladač může přehazovat jak chce. Na architekturách jako ARM navíc může hardware přeházet i ty volatilní. Každopádně od C11 s atomickými operacemi už vlastně ani nevím, k čemu bych volatile použil. S atomic věcmi jde všechno nějak lépe, spolehlivěji a radostněji.

Počítání s přetečením v C

gamer — Mon, 06 Oct 2014 10:18:10 GMT

[33] volatile znamená, jak jsi správně napsal, že zabrání překladači přehazovat a ODSTRAŇOVAT přístupy do paměti. To odstraňovat je tam důležité, protože z kódu a = b; a = 3; nemůže překladač vyhodit přiřazení a = b, pokud je proměnná a volatile. To co jsi popsal (zabránění přeskládání přístupu do paměti) není volatile, ale říká se tomu memory barrier.