Automaticke pretypovani u AVR-GCC

[Tomáš Halabala]

Milan B. napsal(a):
> Obavam sa, ze to riesenie nie je.

Jak se to vezme. Je to reseni jak premluvit GCC, aby pri optimalizaci 
konverzi vyskrtnul. A pri prechodu na novou verzi nebo jiny kompilator 
se nemuze nic zkazit, coz je dulezite.

> 
> Najprv trochu vyskumu:
> 
> Vezmime si tri pripady:
> 
> A. if ( 3 & Status) ...
> B. if ( 3==(3 & Status) ...
> C. if ( ss = (3 & Status ) ...      // ss je tiez unsigned char
> 
> Pri skompilovani avr-gcc (verzia 4.3.2) *bez optimalizacie* pripady A aj 
> B su skompilovane ako 16-bitove, pripad C je skompilovany ako 8-bitovy. 
> Pokial zapneme optimalizaciu, tak aj pripad B sa zmeni na 8-bitovy 
> (napriek tomu, ze je tam to cislo 3)

Vidite a jsme u te "nalady". Pouzivam stejnou verzi prekladace a pripad 
B je nekdy skompilovany ako 8-bitovy a nekdy ako 16-bitovy.

> 
> Avsak ci uz je optimalizacia zapnuta alebo nie, vyrazy v pripadoch A a B 
> su vyhodnocovane ako 16-bitove. Pripad B je upraveny az pri neskorsej 
> optimalizacii - prezretim dump suborov (avr-gcc -fdump-rtl-all) sa da 
> presne zistit, kedy sa to stalo (and:HI (half-integer )sa  zmeni na 
> and:QI (quarter-integer)). Z tychto dumpov je tiez viditelne, ze oba 
> pripady A a B boli povodne vyhodnotene ako 16-bitove a C ako 8-bitovy
> 
> Takze tu vznika domnienka: GCC sa snazi co najviac pracovat s operandmi 
> v nativnej sirke slova, predpokladajuc ze CPU s takymito operandmi vie 
> pracovat najefektivnejsie.  Ak ma k tomu nejaky dovod (napr. vysledok sa 
> uklada do premennej konkretneho typu), tak svoje chovanie moze zmenit - 
> to je pripad C. Kedze avr-gcc  ma definovanu nativnu sirku slova 16 bit  
> tak pripady A a B su spracovane ako 16-bitove (pretoze vysledok sa len 
> pouzije pri porovnani, nikde sa neuklada). Ak si ten isty priklad 
> vyskusame s x86 gcc, dostaneme sa k 32-bitovym operaciam - co len 
> potvrdzuje tuto domnienku
> (Len na okraj: ak v pripade C je premenna ss 32-bitova, cela transakcia 
> sa udeje v 32 bitoch aj na AVR... )
> 
> Takze skutocnost, ze pripad B bol; prelozeny ako 8-bitovy nema vela 
> spolocne s tym, ako vyzera zdrojovy kod, ale co s nim urobili zaverercne 
> optimalizacie.
> 
> Samozrejme ostava otazka, preco kompilator nezoptimalizoval pripad A. 
> Pravdepodobne na zaklade popisu architektury (machine description), 
> ktoru dodali autori portu, kompilator  nenasiel vhodnu redukciu ... ( v  
> pripade A kompilator generuje pseudoinstrukciu tsthi a v pripade B cmphi 
> - pre cmphi je zda sa moznost substitucie na bytove operacie, zatial co 
> pre tsthi sa jednoducho generuje kod - ale hlbsie skumat sa mi to 
> nechce, to som len letmo nahliadol do machine description)
> 
> Takze da sa povedat, ze GCC pracuje perfektne a generuje optimalny kod - 
> pre take AVR, ake mu zadefinovali autori portu avr-gcc, tj. AVR s 
> nativnou sirkou slova 16bit a s takym machine description, ake je. Chova 
> sa podla popisu architektury, nie podla nalady. A asi tazko s tym nieco 
> urobite - jedine ze by ste vylepsili popis architektury (najdete ho v 
> zdrojakoch gcc v adresari gcc/config/avr/avr.md)
> 
> 
> Len poznamka na zaver:
> Uvedomte si, ze pri vyssich jazykoch je dolezite, ci dostanete vysledok 
> podla specifikacie. Vo vasom pripade, ci podmienka funguje tak ako ma. 
> To, ako to kompilator prelozi, je jeho vec a - s prepacenim - nic vas do 
> toho nie je :). To je proste princip vyssich jazykov. Ak chcete pocitat 
> takty a instrukcie - mate assembler. Ono ked vytunite program v C pre 
> nejaky kompilator, s novou verziou alebu znackou kompilatora ste zasa na 
> zaciatku a o prenositelnosti sa neda hovorit - ale mam dojem, ze to vam 
> tu uz niekto povedal.
> 
> -m-

Pri prechodu na jiny MCU se aspon teda v mem pripade predpoklada prechod 
na vykonnejsi kousek, takze i v pripade minimalnich uprav by nemel byt 
vysledek na zpracovani pomalejsi. Prenositelnost bez uprav se opravdu 
uvazovat neda, ale kdyz se program dobre napise, je prace s upravami 
mnohonasobne mensi nez pri prepisovani assembleru nemluve o chybach, 
ktere se pri tom clovek muze dopustit.

Tomas