Funkcje w eeprom.h jako always inline - możliwość zmiany na non-inline?

Sat Mar 14, 2009 7:54 pm   

Witam.
Dlaczego funkcje deklarowane w eeprom.h są always inline?
Czy muszą takie być ze względu na ich konstrukcję?

Akurat potrzebuję takich funkcji non-inline ze względu na braki pamięci
programu
czy mogę poprostu przepisać ten plik i nie deklarować ich jako always
inline?

Dzięki za pomoc.
Pozdrawiam
Paweł

Sat Mar 14, 2009 8:30 pm   

pawel pisze:

To wynika z tego, że rejestry sterujące eepromem są pod różnymi adresami
w różnych uC a biblioteka jest jedna dla wszystkich. Dzięki
inline'owaniu adresy mogą być ustalone na etapie kompilacji projektu a
nie biblioteki.


Samo usunięcie inline nic nie da (kompilator będzie narzekał na
zdublowane definicje). Najlepiej w jednym pliku swojego projektu zrób
własne funkcje zapisu/odczytu eepromu i umieść w nich odwołania do
funkcji bibliotecznych.

Sat Mar 14, 2009 9:00 pm   

Chodzi ci o coś takiego?

uint8_t eeprommy_read_byte (const uint8_t *addr){
return eeprom_read_byte(addr);
}

Mam sporo wywołań bibliotecznych funkcji.
Czy to napewno zmniejszy mi rozmiaru kodu?
Czy wywołanie powyższej funkcji nie spowoduje mimo wszystko wstawienia za
każdym razem
funkcji eeprom_read_byte jako inline?

Pozdrawiam
Paweł

Sat Mar 14, 2009 9:24 pm   

pawel pisze:


Jeśli eeprommy_read_byte wyląduje w pliku *.c a nie w nagłówkowym to
rozmiar powinien zmaleć.


Uważasz, że kompilator robi kopię normalnej funkcji przy każdym wywołaniu?

Sat Mar 14, 2009 9:52 pm   

Zbych pisze:

Czasami tak.
Pytanie kontrolne - jakiej wersji avr-gcc uzywasz? Najnowsza ma
regression bug i ma tendencje do bardzo ostrego inlinowania funkcji co
zwieksza objetosc. Rozwiazaniem jest proba kompilacji jakas wczesniejsza
wersja lub ew. sprobowanie najnowszej wersji RC, czy czym nie wiem czy
ten blad poprawiono.
Inna sprawa, ze funkcje zapisu do EEPROM sa na tyle krotkie, ze koszt
ich wywolania i przekazania parametrow moze byc wyzszy niz kazdorazowe
osadzanie calej funkcji.
Ile ci brakuje bajtow?

Sat Mar 14, 2009 10:05 pm   

Stosunkowo sporo, atmega32
Program: 32830 bytes (100.2% Full)

Maksymalnie 32768.

Wyremowanie jednej linijki

for(i = 0; i < MAX_DS18X20; i++)
{
//blablabla
eeprom_write_byte(&ds18x20_ee[i].restout, k);
//blablabla
}

gdzie ds18x20_ee to struktura, restout to jej pole
zmniejsza kod wynikowy do:
Program: 32744 bytes (99.9% Full)

Paweł

Sat Mar 14, 2009 10:10 pm   

Pmyłka miało być tablica struktur

Paweł

Sat Mar 14, 2009 10:14 pm   

A jeszcze cikawiej, wyjęcie zapisu do eeprom poza pętle zmniejsz rozmiar
pliku wynikowego z
Program: 32830 bytes (100.2% Full)
do
Program: 32816 bytes (100.1% Full)

Może w pętli liczyć na ramie a zapis robić poza nią?
Mimo wszystko i tak sporo to zajmuje.
Paweł

Sat Mar 14, 2009 10:34 pm   

T.M.F. pisze:


Piszesz o WinAVR 20090313 czy jakiejś dystrybucji linuxowej?

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Sat Mar 14, 2009 10:41 pm   

Witam.
Chociaż pytanie nie do mnie.
Używam WinAvr 20071221 niestety we wszystkich nowszych wersjach kod znacznie
się rozrasta.

Paweł

Sun Mar 15, 2009 8:22 pm   

pawel pisze:

Ee, czyli spoko, to praktycznie nic :)


Jesli mozesz to odwroc warunek od MAX_DS18X20 do 0. To wymaga mniej
instrukcji do sprawdzenia. W innych petlach podobnie - staraj sie, zeby
kompilator nie musial wstawiac dodatkowych CP, czyli np. odliczaj do
zera, albo do 255, 256 czy cos w tym stylu.


restout ma jaka dlugosc? Jesli 1 lub 2 bajty to nie oplaca sie
przekazywac adresu, lepiej wartosc.

Zobacz tez czy nie masz gdzies w kodzie operatorow logicznych, mozna je
zoptymalizowac okreslajac explicite typ na np. uint8_t, gdyz gcc
automatycznieje promuje do uint, co wielokrotnie zwieksza ilosc operacji.

Sun Mar 15, 2009 8:22 pm   

Adam Dybkowski pisze:

Pisze o WinAVR.

Mon Mar 16, 2009 12:18 am   

T.M.F. pisze:

A, i nie o 20090313, to chyba wersja RC jest. Ale ostatnia stabilna tak
sie paskudnie zzachowuje i co wiecej okreslanie przez opcje kompilatora
jakie funkcje maja nie byc inline nic nie zmienia.
BTW, jesli masz ta wersje RC zainstalowana mozesz sprawdzic, czy dziala
wprowadzona do gcc opcja umozliwiajaca okreslenie optymalizacji na
poziomie funkcji?

Mon Mar 16, 2009 12:45 am   

T.M.F. pisze:


Nie używam RC, na razie śmigam jeszcze na starej dobrej 20080610.
A optymalizację inline'owania wymuszam przez atrybuty funkcji noinline i
always_inline, jak na razie to działa poprawnie. Poczekam, aż coś się
wyklaruje z nowszym WinAVR'em jeżeli takie problemy są obecnie.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

Mon Mar 16, 2009 1:19 am   

T.M.F. pisze:


Ale to ma chyba działać dopiero od 4.4, a w winavr jest jeszcze 4.3.