WinAVR-20090313 "inlajnowanie" funkcji.

Już znalazłem Pozdrawiam G.K.

Grzegorz Kurczyk pisze:

Kolego, to może napisz?? Ktoś kiedyś będzie szukał w archiwum i będzie widział tylko posty w stylu "już wiem", "już znalazłem"... to chyba nie jest duży problem napisać te pare zdań... Ty miałeś ten problem, to inni też go mogą kiedyś mieć...

Pozdrawiam!!

Użytkownik Konop napisał:

Sorki. Ma Kolega rację. Dla potomnych: dyrektywy kompilatora odpowiedzialne za "inlajnowanie", które należy dopisać do makefile

CFLAGS += -fno-inline CFLAGS += -fno-inline-small-functions CFLAGS += -finline-limit=3 CFLAGS += --param inline-call-cost=2

w sumie wystarczy ta pierwsza (wyłącza tryb inline).

Pozdrawiam G.K.

a mo¿e jak Kto¶ kiedy¶ bêdzie szuka³ i znajdzie Twojego posta jako ma³o oblatany nie bêdzie wiedzia³ o co chodzi... wiêc mo¿e by¶ wyja¶ni³ co to jest to "inlajnowanie" funkcji?

Jak przeczyta cały wątek i nie zrozumie to bedzie oznaczać że powinien zająć się czymś innym niż pisanie programów.

mo¿e i tak, gdyby jednak Kto¶ chcia³ napisaæ to z góry dziêki.

W dniu 2009-09-05 16:26, identyfikator: 20040501 pisze:

Ale skoro nie będzie wiedział, czego szuka to nawet nie znajdzie tej wiadomości, bo co wpisze w wyszukiwarkę? :) Jeśli chcesz się dowiedzieć więcej, szukaj pod hasłami inlining i inline function.

Użytkownik identyfikator: 20040501 napisał:

Witam ponownie.

Generalnie te informacje są istotne dla ZSOKW i ZBOKB czyli: Zwolenników Skrajnej Optymalizacji Kodu Wynikowego i Związku Bojowników o Każdy Bajt

:-)

Owo "inlajnowanie" to jedna z metod optymalizacji kodu wynikowego przez kompilator. Przykładowo mamy funkcję A wywoływaną przez funkcję B. Jeśli w wyniku kompilacji wyszło, że ciało funkcji A to w efekcie trzy bajty na krzyż, to nie ma sensu we wnętrzu funkcji B wstawiać wywołania funkcji A przez rozkaz CALL (i potem wracać przez RET co jest dodatkowym obciążeniem czasowym) ekonomiczniej jest wkompilować ciało funkcji A bezpośrednio w ciało funkcji B. Chodzi tylko aby nie przegiąć przy tej optymalizacji i nie doprowadzić do rozrostu kodu wynikowego.

P.S. Z wyłączeniem onlajnowania dyrektywą -fno-inline trzeba uważać, bo np. bloki ATOMIC zaczynają generować prawdziwe koszmarki w kodzie wynikowym zamiast prostego in r15, SREG; cli; ..... out SREG, r15. Korzystniej jest poeksperymentować z parametrem -finline-limit=3 osiągając stosowny kompromis.

Pozdrawiam Grzegorz

Ja bym to nazwal Zwiazkiem Bojownikow o Kazda Instrukcje - w skrocie "ZBoKI" co lepiej oddaje istote problemu :)

To jest jeden powod, drugi czestszy to optymalizacja pod wzgledem szybkosci. Czyli zamiast robic np. petle for mozna ja rozwinac na ciag instrukcji (to kontroluje inna dyrektywa kompilatora), albo wlasnie wstawic nawet dluzsza sekwencje rozkazow, ale za to uniknac RCALL/CALL z RET, ktore sa dlugie.

O ile sie nie myle to z gcc w WinAVR z 13.03.09 jest pewien problem - nie do konca poprawnie reaguje na te dyrektywy. Jest obejscie tego, ale w tej chwili nie pamietam, zainteresowani wygooglaja.