RTV forum PL | NewsGroups PL

Jak zmiany w win-avr-gcc wpływają na rozmiar generowanego kodu AVR?

Czy kolejne wersje win-avr-gcc generują coraz dłuższy kod?

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Jak zmiany w win-avr-gcc wpływają na rozmiar generowanego kodu AVR?

Goto page 1, 2  Next

Andrzej
Guest

Wed Mar 23, 2011 2:26 pm   



Zaczynam zabawę z AVR-ami.
Mam program skompilowany przez autora pod Win-avr-3.4.6 i zajmuje on ok.
2kB.
Ten sam program skompilowany ze źródła pod wersją 4.1.2 zajmuje ponad 4kB
(opcja -0s).
Podobno następne wersje generują coraz dłuższe kody, ale taka zmiana - to
chyba niemożliwe.
pozdrawiam,
Andrzej

shg
Guest

Wed Mar 23, 2011 5:08 pm   



On Mar 23, 2:26 pm, "Andrzej" <dydel...@op.pl> wrote:
Quote:
Podobno nast pne wersje generuj coraz d u sze kody, ale taka zmiana - to
chyba niemo liwe.

Niestety to prawda.
Kiedyś natknąłem się na wykres na którym był rozmiar tego samego kodu
kompilowanego kolejnymi wersjami avr-gcc. Monotoniczna zależność
rosnąca. Gdyby kompilacja avr-gcc nie była tak wrednym zabiegiem, to
pokusiłbym się o odtworzenie tego wykresu.
Mam też kilka swoich programów, dla których obserwuję podobną
zależność, modyfikowane są niektóre parametry, ale kod ogólnie
pozostaje niezmieniony, z każdą kolejna wersją jest większy.
Coraz więcej pojawia się sytuacji, gdzie proste operacje nie są
optymalizowane, np. przesunięcia bitowe na zmiennych 8-bitowych
wykonywane są na 16 bitach (podobnie niektóre operacje logiczne).
Sporo jest też "pogrubiania zmiennych", tzn. dwa razy zapisywane jest
to samo do jakiegoś rejestru, albo głupoty jak sprawdzanie czy zero
jest zerem (zapis zera do rejestru, a potem sprawdzanie co w tym
rejestrze jest, to wynika akurat z popsutych operacji na ośmiu bitach).

Andrzej
Guest

Wed Mar 23, 2011 6:04 pm   



Użytkownik "shg" <shogoonn@gmail.com> napisał w wiadomości
news:08dfb13c-e0d3-4b02-a4a7-e32a3319eb78@h38g2000yqn.googlegroups.com...
On Mar 23, 2:26 pm, "Andrzej" <dydel...@op.pl> wrote:
Quote:
Podobno nast pne wersje generuj coraz d u sze kody, ale taka zmiana - to
chyba niemo liwe.

Niestety to prawda.
Kiedyś natknąłem się na wykres na którym był rozmiar tego samego kodu
kompilowanego kolejnymi wersjami avr-gcc. Monotoniczna zależność
rosnąca. Gdyby kompilacja avr-gcc nie była tak wrednym zabiegiem, to
pokusiłbym się o odtworzenie tego wykresu.
Mam też kilka swoich programów, dla których obserwuję podobną
zależność, modyfikowane są niektóre parametry, ale kod ogólnie
pozostaje niezmieniony, z każdą kolejna wersją jest większy.
Coraz więcej pojawia się sytuacji, gdzie proste operacje nie są
optymalizowane, np. przesunięcia bitowe na zmiennych 8-bitowych
wykonywane są na 16 bitach (podobnie niektóre operacje logiczne).
Sporo jest też "pogrubiania zmiennych", tzn. dwa razy zapisywane jest
to samo do jakiegoś rejestru, albo głupoty jak sprawdzanie czy zero
jest zerem (zapis zera do rejestru, a potem sprawdzanie co w tym
rejestrze jest, to wynika akurat z popsutych operacji na ośmiu bitach).

Ok. Ale nie wyobrażam sobie sytuacji, żeby kod powiększył dwukrotnie
rozmiar.
Autor podaje gotowy plik hex mający rzeczywiście ok. 2kB.
Ściągnąłem wersje gcc, którą on kompilował i znowu otrzymałem plik ok. 4kB
Czegoś tu nie rozumiem...

Elektrolot
Guest

Wed Mar 23, 2011 6:10 pm   



W dniu 2011-03-23 18:04, Andrzej pisze:
Quote:
Autor podaje gotowy plik hex mający rzeczywiście ok. 2kB.
Ściągnąłem wersje gcc, którą on kompilował i znowu otrzymałem plik ok. 4kB
Czegoś tu nie rozumiem...

Dobrze byłoby porównywać rozmiar plików BIN a nie Intel Hex.

Michoo
Guest

Wed Mar 23, 2011 6:29 pm   



W dniu 23.03.2011 18:04, Andrzej pisze:
Quote:
Autor podaje gotowy plik hex mający rzeczywiście ok. 2kB.
Ściągnąłem wersje gcc, którą on kompilował i znowu otrzymałem plik ok. 4kB
Czegoś tu nie rozumiem...
Użyj avr-size na obu to dostaniesz informację ile co zajmuje.


Pliki hex mają każdą linię zaczynającą się od adresu - jak są krótkie to
plik znacząco tyje.
Poza tym może coś masz wrzucone do hex, czego nie powinno być (np bss)?

--
Pozdrawiam
Michoo

Sebastian Biały
Guest

Wed Mar 23, 2011 7:44 pm   



On 2011-03-23 18:04, Andrzej wrote:
Quote:
Autor podaje gotowy plik hex majcy rzeczywicie ok. 2kB.
cignem wersje gcc, któr on kompilowa i znowu otrzymaem plik ok. 4kB
Czego tu nie rozumiem...

Pokaż sposób tworzenia ihex.

Andrzej
Guest

Wed Mar 23, 2011 8:06 pm   



Użytkownik "Michoo" <michoo_news@vp.pl> napisał w wiadomości
news:imdal8$vp9$1@news.onet.pl...
Quote:
W dniu 23.03.2011 18:04, Andrzej pisze:
Autor podaje gotowy plik hex mający rzeczywiście ok. 2kB.
Ściągnąłem wersje gcc, którą on kompilował i znowu otrzymałem plik ok.
4kB
Czegoś tu nie rozumiem...
Użyj avr-size na obu to dostaniesz informację ile co zajmuje.

Pliki hex mają każdą linię zaczynającą się od adresu - jak są krótkie to
plik znacząco tyje.
Poza tym może coś masz wrzucone do hex, czego nie powinno być (np bss)?


W pliku hex policzyłem komórki, pomijając adresy.
Co to jest bss? (mówiłem, że dopiero zaczynam)

Quote:

--
Pozdrawiam
Michoo

Też pozdrawiam,
Andrzej

Andrzej
Guest

Wed Mar 23, 2011 8:09 pm   



Użytkownik "Sebastian Biały" <heby@poczta.onet.pl> napisał w wiadomości
news:imdf2d$qsd$1@news.onet.pl...
Quote:
On 2011-03-23 18:04, Andrzej wrote:
Autor podaje gotowy plik hex maj?cy rzeczywi?cie ok. 2kB.
|ci?gn?3em wersje gcc, któr? on kompilowa3 i znowu otrzyma3em plik ok.
4kB
Czego? tu nie rozumiem...

Pokaż sposób tworzenia ihex.

Nie wiem, co to takiego.

Sebastian Biały
Guest

Wed Mar 23, 2011 9:05 pm   



On 2011-03-23 20:09, Andrzej wrote:
Quote:
Poka sposób tworzenia ihex.
Nie wiem, co to takiego.

W wyniku kompilacji i obróbki pliku .elf dostaniesz albo plik bin albo
hex (intel hex). Jakie polecenie i z jakimi argumentami go wygenerowało?

Zakarm
Guest

Wed Mar 23, 2011 9:11 pm   



W dniu 2011-03-23 14:26, Andrzej pisze:
Quote:
Zaczynam zabawę z AVR-ami.
Mam program skompilowany przez autora pod Win-avr-3.4.6 i zajmuje on ok.
2kB.
Ten sam program skompilowany ze źródła pod wersją 4.1.2 zajmuje ponad 4kB
(opcja -0s).
Podobno następne wersje generują coraz dłuższe kody, ale taka zmiana - to
chyba niemożliwe.
pozdrawiam,
Andrzej



pewnie ten sam kod napisany poprostu w assemblerze zajalby kilkaset bajtow.

Adam Dybkowski
Guest

Wed Mar 23, 2011 9:18 pm   



W dniu 2011-03-23 14:26 Andrzej napisał(a):

Quote:
Zaczynam zabawę z AVR-ami.
Mam program skompilowany przez autora pod Win-avr-3.4.6 i zajmuje on ok.
2kB.
Ten sam program skompilowany ze źródła pod wersją 4.1.2 zajmuje ponad 4kB
(opcja -0s).

Podobno następne wersje generują coraz dłuższe kody, ale taka zmiana - to
chyba niemożliwe.

Możliwe i właśnie tak jest.
Niestety dodanie wsparcia nowych/dużych procków spowodowało pogorszenie
kodu wynikowego nawet w małych prockach. Wróć do starego gcc i już.

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

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

Andrzej
Guest

Wed Mar 23, 2011 9:40 pm   



Użytkownik "Sebastian Biały" <heby@poczta.onet.pl> napisał w wiadomości
news:imdjpf$fsg$1@news.onet.pl...
Quote:
On 2011-03-23 20:09, Andrzej wrote:
Poka? sposób tworzenia ihex.
Nie wiem, co to takiego.

W wyniku kompilacji i obróbki pliku .elf dostaniesz albo plik bin albo hex
(intel hex). Jakie polecenie i z jakimi argumentami go wygenerowało?

OK. Załapałem ihex to Intel hex.
I cały pic polega na tym, że autorowi z tą samą wersją gcc wychodzi plik,
który mieści się w pamięci attiny2313.
A u mnie:
rm -rf proba.o proba.elf dep/* proba.hex proba.eep
Build succeeded with 0 Warnings...
avr-gcc.exe -mmcu=attiny2313 -Wall -gdwarf-2 -Os -fsigned-char -MD -MP -MT
proba.o -MF dep/proba.o.d -c ../proba.c
avr-gcc.exe -mmcu=attiny2313 proba.o -o proba.elf
avr-objcopy -O ihex -R .eeprom proba.elf proba.hex
avr-objcopy -j
..eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma
..eeprom=0 --no-change-warnings -O ihex proba.elf proba.eep || exit 0
c:\WinAVR-20070525\bin\avr-objcopy.exe: there are no sections to be copied!
AVR Memory Usage
----------------
Device: attiny2313
Program: 4968 bytes (242.6% Full)
(.text + .data + .bootloader)
Data: 74 bytes (57.8% Full)
(.data + .bss + .noinit)

Sebastian Biały
Guest

Wed Mar 23, 2011 9:56 pm   



On 2011-03-23 21:40, Andrzej wrote:
Quote:
avr-gcc.exe -mmcu=attiny2313 -Wall -gdwarf-2 -Os -fsigned-char -MD -MP -MT

Wywal -gdwarf-2 i zobacz co się stanie.

Michoo
Guest

Wed Mar 23, 2011 10:17 pm   



W dniu 23.03.2011 21:40, Andrzej pisze:
Quote:
AVR Memory Usage
odpal:

avr-size.exe proba.elf

--
Pozdrawiam
Michoo

Tom
Guest

Thu Mar 24, 2011 4:23 am   



On 24/03/2011 6:40 AM, Andrzej wrote:
Quote:
Użytkownik "Sebastian Biały"<heby@poczta.onet.pl> napisał w wiadomości
news:imdjpf$fsg$1@news.onet.pl...
On 2011-03-23 20:09, Andrzej wrote:
Poka? sposób tworzenia ihex.
Nie wiem, co to takiego.

W wyniku kompilacji i obróbki pliku .elf dostaniesz albo plik bin albo hex
(intel hex). Jakie polecenie i z jakimi argumentami go wygenerowało?

OK. Załapałem ihex to Intel hex.
I cały pic polega na tym, że autorowi z tą samą wersją gcc wychodzi plik,
który mieści się w pamięci attiny2313.
A u mnie:
rm -rf proba.o proba.elf dep/* proba.hex proba.eep
Build succeeded with 0 Warnings...
avr-gcc.exe -mmcu=attiny2313 -Wall -gdwarf-2 -Os -fsigned-char -MD -MP -MT
proba.o -MF dep/proba.o.d -c ../proba.c
avr-gcc.exe -mmcu=attiny2313 proba.o -o proba.elf
avr-objcopy -O ihex -R .eeprom proba.elf proba.hex
avr-objcopy -j
.eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma
.eeprom=0 --no-change-warnings -O ihex proba.elf proba.eep || exit 0
c:\WinAVR-20070525\bin\avr-objcopy.exe: there are no sections to be copied!
AVR Memory Usage
----------------
Device: attiny2313
Program: 4968 bytes (242.6% Full)
(.text + .data + .bootloader)
Data: 74 bytes (57.8% Full)
(.data + .bss + .noinit)

Kod jest autora, skad masz makefile?

Tomek

Goto page 1, 2  Next

elektroda NewsGroups Forum Index - Elektronika Polska - Jak zmiany w win-avr-gcc wpływają na rozmiar generowanego kodu AVR?

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map