avr-gcc eeprom inline

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.

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³

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?

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?

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³

Pmy³ka mia³o byæ tablica struktur

Pawe³

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³

T.M.F. pisze:

Piszesz o WinAVR 20090313 czy jakiejś dystrybucji linuxowej?

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

Pawe³

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.

Adam Dybkowski pisze:

Pisze o WinAVR.

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?

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.

T.M.F. pisze:

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