ARM GCC problem

[Jan Waclawek]

Aha.

V povodnom prispevku dotycny pouzil klucove slovo #def, co sice 
nepoznam, ale predpokladal som, ze nejde o #define ale ide o 
nestandardne rozsirenie prekladaca a ma podobny vyznam ako #pragma, co 
sice syntaxou vyzera ako direktiva predprocesora, ale nie je (aj ked 
moze byt :-O ).

To, ze C (aj v implementaciach pokusajucich sa pridrziavat standardu/ov) 
je vo vseobecnosti jeden obrovsky bordel, to prosim teraz neprejednavajme.

wek




Marek Peca wrote:
>>Nerozumiem v com presne je Vas dusevny problem :-)
>>
>>Ak take prave v GCC nie je (aj ked ja by som hladal #pragma), tak 
>>nevidim problem (samozrejme ciste teoreticky) v tom to tam dopisat...
>>
>>Akykolvek prekladac obvykle preklada jednotlive funkcie (takmer) uplne 
>>izolovane jednu od druhej, a tak nie je problem menit uroven 
>>optimalizacie per funkcia. Urcite sa daju najst aj vyrazne mensie useky 
>>zdrojoveho textu kde je optimalizaciu mozne menit bez straty desitky.
> 
> 
> No ja vubec nevidim problem v urcovani, ktere casti kodu (nejen
> funkce) budou mit optimalizaci vypnutou a ktere ne. Ja se jen
> podivuji nad tim, ze by nekdo sveril zapinani a vypinani
> _preprocesoru_. Tam to podle me nepatri, proto jsem zvedavy, zda se
> mylim, pripadne co koho pudilo to do preprocesoru zahrnout.
> 
> Preprocesor nevi, s cim pracuje, proto mi pripada obskurni, ze by se
> jim hrabalo do optimalizace.
> 
> (Neco jineho je samozrejme nadefinovat si nejake makro, v jehoz
> definici bude pouzito neco jako volatile, to pak je v poradku, ovsem
> takove makro je mnohem konkretnejsi konstrukce, nez obecne
> vypnuti/zapnuti optimalizace.)
> 
> 
> Ze se "da" napsat kdejaka blbost, to je bez pochyby. Dulezite ale je,
> co je spravne a co vede k babylonu, pripadne chybnym vysledkum.
> 
> 
> Ony nektere kompilatory jsou takove radoby vstricne (napr. umoznuji
> nezarovnany pristup v urcitych nevhodnych pripadech) a vysledkem je
> bud napr. neefektivni kod, jindy napr. neprenositelnost zdroje ci
> vysledneho kodu do slozitejsiho prostredi (viceprocesorovy stroj,
> jiny endian, jina architektura). Takovy "populismus" v pripade jazyka
> C je zavrzenihodny, neb zrovna v C by mel _programator_ byt ten, kdo
> vi co chce a vi, jak to spravne udelat.
> 
> 
> Zdravi Marek P.
> 
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list@list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>