Automaticke pretypovani u AVR-GCC

[Tomáš Halabala]

Děkuji, jo toto je řešení, ale co mě na tom nejvíce zaráží je, jak jsem 
psal, že v jednom případě překladač tu trojku nerozšířil a v jiném místě 
programu s úplně stejným zápisem pouze s jinými názvy proměnných tu 
trojku převedl na int, což jak píšete odpovídá ANSI C. Ale proč to tedy 
dodržuje překladač podle nálady? To už asi zůstane nezodpovězeno.
Odpovědí je zřejmě asi IAR.

Použil jsem C, protože se jedná o velmi rozsáhlý program a samozřejmě ty 
nejkritičtější části jsou psané v assembleru. Administrativní část je v 
C s tím, že neustále kontroluji efektivnost překladu. Slibuji si od toho 
přece jen snadnější přenositelnost na jiné MCU a CPU, což je také 
směrodatné.

Tomáš

Miroslav Šinko napsal(a):
> Myslim, ze problem je v konverziach na int podla ANSI C, kde cislo 3
> je implicitne 16-bit. Kedysi sa to tu preberalo.
> 
> Pohral som sa s AVR-GCC. Riesenim je takyto zapis:
> 
>  void fce(void)
>  {
> U8 val=3;
>     if (val & Status) { ...
>  ..
> }
> 
> pre druhy priklad:
>  void fce(void)
>  {
> U8 val1=3, val2=3;
>     if ((val1 & Status) == val2) { ...
>  ..
> }
> 
> Pri optimalizacii O1 nevytvara na zasobniku priestor pre val (val1,2)
> a kod je taky, ako si predstavujete :-)
> 
> 	if(val & status)
>  136:	80 91 63 00 	lds	r24, 0x0063
>  13a:	83 70       	andi	r24, 0x03	; 3
>  13c:	11 f0       	breq	.+4      	; 0x142 <fce+0xc>
> 
> 
> 	if((val1 & status) == val2)
>  136:	80 91 63 00 	lds	r24, 0x0063
>  13a:	83 70       	andi	r24, 0x03	; 3
>  13c:	83 30       	cpi	r24, 0x03	; 3
>  13e:	11 f4       	brne	.+4      	; 0x144 <fce+0xe>
> 
> miro
> 
> PS: wek by Vam este napisal nieco o vhodnosti C na casovo kriticke aplikacie :-)