Zbynio
Guest
Sun Apr 14, 2013 9:37 pm
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. ?
???
Grzegorz Niemirowski
Guest
Sun Apr 14, 2013 11:10 pm
Zbynio <i@dont.pl> napisał(a):
Quote:
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
Zbynio
Guest
Sun Apr 14, 2013 11:56 pm
"Grzegorz Niemirowski" <gnthexfiles@poczta.onet.pl> wrote in message
news:kkfd21$tva$1@news.icpnet.pl...
Quote:
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ć
Zbych
Guest
Mon Apr 15, 2013 5:47 am
W dniu 2013-04-15 01:56, Zbynio pisze:
Quote:
"Grzegorz Niemirowski" <gnthexfiles@poczta.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.