ARM GCC problem

[Marek Peca]

> 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.