Pytanie :-) Może głupie może nie. :-)

Powiedzcie mi czy mam walczyć z kompilatorem w taki sposób żeby sam zapis w
języku C był możliwie pozbawiony podfunkcji?
Czy może dla czystości kodu powinienem się skupić na problemie do
rozwiązania, a nie nad sposobem zapisu?

NP:

a() {
...
}

b() {
...
}

foo {
a();
b();
...
}

Czy może powinienem za wszelką cenę zapisywać ciała funkcji a i b wewnątrz
funkcji foo ? Analizując assembler mam mieszane uczucia. Raz mi się tworzą
call-e / rcall-e a raz kod jest strasznie posiekany ale nie wynika, że mi
calluje tylko jakby sobie je wkleił i wiedział, że to nie jest konieczne
żeby rekursywnie wywoływać a() i b() ?

No jak to jest ? Od czego to zależy kiedy kompilator wie co z tym zrobić
?Często na PC widzę czyjeś źródłą posiekane na dziesiątki małych funkcji,
później jedna jest w drugiej, a trzecia w czwartej jak ruskie babuszki. ?

???

do góry

Zbynio <...@d...pl> napisał(a):
> Pytanie :-) Może głupie może nie. :-)
> Powiedzcie mi czy mam walczyć z kompilatorem w taki sposób żeby sam
> zapis w języku C był możliwie pozbawiony podfunkcji?
> Czy może dla czystości kodu powinienem się skupić na problemie do
> rozwiązania, a nie nad sposobem zapisu?
> NP:
> a() {
> ...
> }
> b() {
> ...
> }
> foo {
> a();
> b();
> ...
> }
> Czy może powinienem za wszelką cenę zapisywać ciała funkcji a i b
> wewnątrz funkcji foo ? Analizując assembler mam mieszane uczucia. Raz
> mi się tworzą call-e / rcall-e a raz kod jest strasznie posiekany ale
> nie wynika, że mi calluje tylko jakby sobie je wkleił i wiedział, że to
> nie jest konieczne żeby rekursywnie wywoływać a() i b() ?
> No jak to jest ? Od czego to zależy kiedy kompilator wie co z tym zrobić
> ?Często na PC widzę czyjeś źródłą posiekane na dziesiątki małych funkcji,
> później jedna jest w drugiej, a trzecia w czwartej jak ruskie babuszki. ?
> ???

Zależy od wielu rzeczy, nie da się tego wytłumaczyć w jednym zdaniu.
Poczytaj sobie
http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Optimize
-Options.html Zobacz,
ile tam jest opcji konfiguracyjnych optymalizację oraz jak często pojawia
się w ich opisie odniesienie do heurystyki. Czasem heurystyka może
stwierdzić, że inline się opłaca, a innym razem, że nie.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 3 days, 6 hours, 32 minutes and 23 seconds

do góry

"Grzegorz Niemirowski" <g...@p...onet.pl> wrote in message
news:kkfd21$tva$1@news.icpnet.pl...

> Zależy od wielu rzeczy, nie da się tego wytłumaczyć w jednym zdaniu.
> Poczytaj sobie
> http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Optimize
-Options.html Zobacz,
> ile tam jest opcji konfiguracyjnych optymalizację oraz jak często pojawia
> się w ich opisie odniesienie do heurystyki. Czasem heurystyka może
> stwierdzić, że inline się opłaca, a innym razem, że nie.

\Ja wiem, czytałem to nie raz :-) I atmelowskie opracowania i tyle samo wiem
co wcześniej :-)
Ogólnie to trzeba obserwować jak przyrasta kodu po kolejnej kompilacji i
debugować :-)

do góry

W dniu 2013-04-15 01:56, Zbynio pisze:
>
> "Grzegorz Niemirowski" <g...@p...onet.pl> wrote in message
> news:kkfd21$tva$1@news.icpnet.pl...
>
>> Zależy od wielu rzeczy, nie da się tego wytłumaczyć w jednym zdaniu.
>> Poczytaj sobie
>> http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Optimize
-Options.html
>> Zobacz, ile tam jest opcji konfiguracyjnych optymalizację oraz jak
>> często pojawia się w ich opisie odniesienie do heurystyki. Czasem
>> heurystyka może stwierdzić, że inline się opłaca, a innym razem, że nie.
>
> \Ja wiem, czytałem to nie raz :-) I atmelowskie opracowania i tyle samo
> wiem co wcześniej :-)
> Ogólnie to trzeba obserwować jak przyrasta kodu po kolejnej kompilacji i
> debugować :-)

Gcc można zmusić do inline'owania atrybutem always_inline:

__attribute__((always_inline)) void foo(const char c) {
... some code
}

Oczywiście funkcja musi być widoczna w danej jednostce kompilacji.

do góry