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

do góry

On Mar 23, 2:26 pm, "Andrzej" <d...@o...pl> wrote:
> 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).

do góry

Użytkownik "shg" <s...@g...com> napisał w wiadomości
news:08dfb13c-e0d3-4b02-a4a7-e32a3319eb78@h38g2000yq
n.googlegroups.com...
On Mar 23, 2:26 pm, "Andrzej" <d...@o...pl> wrote:
>> 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...

do góry

W dniu 2011-03-23 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...

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

do góry

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)?

--
Pozdrawiam
Michoo

do góry

On 2011-03-23 18:04, Andrzej wrote:
> 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...

Pokaż sposób tworzenia ihex.

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:imdal8$vp9$1@news.onet.pl...
>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)

>
> --
> Pozdrawiam
> Michoo

Też pozdrawiam,
Andrzej

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:imdf2d$qsd$1@news.onet.pl...
> 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.

do góry

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?

do góry

W dniu 2011-03-23 14:26, Andrzej pisze:
> 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.

do góry