AVR GCC lub inny.
Masz problem? Zapytaj na forum elektroda.pl
From: =?ISO-8859-2?Q?Ania_i_Grze=B6?= <brak_at_nospam_maila.pl>
Subject: AVR GCC lub inny.
Date: Mon, 24 Jan 2005 13:02:14 +0100
Witam.
Kiedys pytalem z jakich narzedzi korzystac, aby pisac kod w jezyku C dla
uPC AVR. Obecnie korzystam z WinAVR. Na stronie
http://www.avrfreaks.net/ zniknal kompilator AVRGCC, sa linki, ale zaden
(bynajmniej u mnie) nie dziala. Na stronie
http://savannah.nongnu.org/projects/avr-libc/ sa nowe biblioteki dla C
pod AVR, natomiast nie ma slowa o tym, jak je uzywac/zainstalowac pod
Windows a maja one kilka znaczacych poprawek/zmian. Chcialbym podmienic
biblioteki, ktore sa instalowane z WinAVR na te nowsze, jednak nie wiem,
czy bedzie to chcialo pozniej dzialac.
Czy ktos z Was, uzytkownicy WinAVR lub C dla AVR podmieniali biblioteki?
Moze ktos wie cos na temat AVRGCC czy jest to rozwijany projekt, czy
zaprzestali juz jego dalszego rozwoju? Najbardziej cieszylo by mnie,
gdyby byla wersja AVRGCC wspolpracujaca z AVRStudio v. 4.11, ale to
raczej tylko marzenia.
A moze ktos zna jakis projekt, ktory jest rozwijany/aktualizowany
odnosnie AVRC, pisze i mysle o jakims darmowym, bo nie chce do
samodzielnego uczenia sie w domu kupowac jakiegos full-wypas kompilatora.
Uzylem na probe CodeVisionAVR, ale wygenerowal mi plik *.hex ponad 5kb!
A byla w nim tylko obsluga DS1820 i LCD, tzn. odczyt temperatury i
wyswietlenie na LCD, toz w BASCOM mniej to zajmuje.
--
Pozdrawiam, Ania i Grzes (Od 26.12.2004 mąż i żona)
- Żwirek kręci z Muchomorkiem!?
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Mon, 24 Jan 2005 13:15:10 +0100
Pewnego dnia Ania i Grześ przemówił ludzkim głosem:
http://www.avrfreaks.net/ zniknal kompilator AVRGCC, sa linki, ale zaden
(bynajmniej u mnie) nie dziala.
http://sourceforge.net/projects/winavr/
zaprzestali juz jego dalszego rozwoju?
Nie, projekt jest cały czas rozwijany.
Najbardziej cieszylo by mnie,
gdyby byla wersja AVRGCC wspolpracujaca z AVRStudio v. 4.11, ale to
raczej tylko marzenia.
Zależy co masz na myśli pisząc współpraca. Jeśli informacje dla debugera
wygenerujesz w formacie dwarf-2, to da się to bez problemu wczytać w
AVRStudio i debugować na poziomie kodu źródłowego.
Uzylem na probe CodeVisionAVR, ale wygenerowal mi plik *.hex ponad 5kb!
A byla w nim tylko obsluga DS1820 i LCD, tzn. odczyt temperatury i
wyswietlenie na LCD, toz w BASCOM mniej to zajmuje.
Bo pewnie użyłeś printfa i zmiennego przecinka. Niestety nawet puts w
wydaniu dla avr zajmuje jakieś koszmarne ilości pamięci, dlatego
najlepiej jest napisać własne funkcje do wyświetlania stringów i zamiany
liczb na ciąg ascii.
--
Prawo jest jak płot - żmija zawsze się prześlizgnie,
tygrys zawsze przeskoczy a bydło tylko stoi i czeka.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
From: =?ISO-8859-2?Q?Ania_i_Grze=B6?= <brak_at_nospam_maila.pl>
Subject: Re: AVR GCC lub inny.
Date: Mon, 24 Jan 2005 13:24:00 +0100
Dnia 2005-01-24 13:15, Zbych napisał(a):
Pewnego dnia Ania i Grześ przemówił ludzkim głosem:
http://www.avrfreaks.net/ zniknal kompilator AVRGCC, sa linki, ale
zaden (bynajmniej u mnie) nie dziala.
http://sourceforge.net/projects/winavr/
Nie, projekt jest cały czas rozwijany.
No ostatnia aktualizacja to jakos Lipiec 2004. Biblioteki libc zmienily
sie bardzo in plus: http://www.nongnu.org/avr-libc/changes-1.2.html
dodali obsluge kilku mikrokontrolerow.. Takze nadal pozostaje pytanie,
czy mozna recznie zaktualizowac je w WinAVR.
Zależy co masz na myśli pisząc współpraca. Jeśli informacje dla debugera
wygenerujesz w formacie dwarf-2, to da się to bez problemu wczytać w
AVRStudio i debugować na poziomie kodu źródłowego.
Jako wspolpraca rozumiem mozliwosc pisania programow w C korzystajac ze
srodowiska AVRStudio. Tak, jak bylo to mozliwe w AVRStudio 3.xx.xx.
Bo pewnie użyłeś printfa i zmiennego przecinka. Niestety nawet puts w
wydaniu dla avr zajmuje jakieś koszmarne ilości pamięci, dlatego
najlepiej jest napisać własne funkcje do wyświetlania stringów i zamiany
liczb na ciąg ascii.
Raczej tak sie stalo:
<CODE>
#include <90s2313.h>
#include <stdio.h>
#include <delay.h>
#asm
.equ __w1_port=0x12 ;PORTD
.equ __w1_bit=2
#endasm
#include <1wire.h>
#include <ds1820.h>
#asm
.equ __lcd_port=0x18 ;PORTB
#endasm
#include <lcd.h>
main()
{
int temp;
char lcd_buffer[33];
PORTB=0x00;
DDRB=0x00;
PORTD=0x00;
DDRD=0x70;
TCCR0=0x00;
TCNT0=0x00;
TCCR1A=0x00;
TCCR1B=0x00;
TCNT1H=0x00;
TCNT1L=0x00;
OCR1H=0x00;
OCR1L=0x00;
GIMSK=0x00;
MCUCR=0x00;
TIMSK=0x00;
ACSR=0x80;
w1_init();
lcd_init(16);
lcd_clear();
while (1)
{
if (w1_init())
{
temp = ds1820 temperature10(0);
lcd_gotoxy(0,0);
lcd_putsf("Temperatura");
lcd_gotoxy(0,13);
sprintf(lcd_buffer,temp/10);
lcd_puts(lcd_buffer);
delay_ms(1000);
}
else
{
lcd_clear();
lcd_putsf("Blad");
}
};
}
</CODE>
--
Pozdrawiam, Ania i Grzes (Od 26.12.2004 mąż i żona)
- Żwirek kręci z Muchomorkiem!?
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Mon, 24 Jan 2005 16:35:11 +0100
Pewnego dnia Ania i Grześ przemówił ludzkim głosem:
No ostatnia aktualizacja to jakos Lipiec 2004. Biblioteki libc zmienily
sie bardzo in plus: http://www.nongnu.org/avr-libc/changes-1.2.html
dodali obsluge kilku mikrokontrolerow.. Takze nadal pozostaje pytanie,
czy mozna recznie zaktualizowac je w WinAVR.
Wystarczy, że ściągniesz najnowsze libc i skompilujesz, "zainstalujesz".
Pytanie tylko czy potrzebujesz obsługi tych najnowszych procesorów ?
Jako wspolpraca rozumiem mozliwosc pisania programow w C korzystajac ze
srodowiska AVRStudio. Tak, jak bylo to mozliwe w AVRStudio 3.xx.xx.
W wersji 4 AVRStudio MSZ się nie da. Zresztą programmers notepad, który
jest w pakiecie WinAvr jest naprawdę dobry (choć udało mi się go już
wykrzaczyć).
Raczej tak sie stalo:
temp = ds1820 temperature10(0);
lcd_gotoxy(0,0);
lcd_putsf("Temperatura");
lcd_gotoxy(0,13);
sprintf(lcd_buffer,temp/10);
^^^^^^^^^^^^^^^^^^^^^^^ tu może być winowajca
lcd_puts(lcd_buffer);
delay_ms(1000);
Sprawdź raport po linkowaniu i zobacz jakie procedury ile miejsca zajmują.
Zamiast połączenia sprintf i dzielenia ze znakiem (linia, którą
podkreśliłem) użyłbym procedury z noty aplikacyjnej
http://www.atmel.com/dyn/resources/prod_documents/doc0938.pdf
potem rozbił BCD na poszczególne liczby, dodał kod '0' ascii i wysłał na
wyświetlacz. Oczywiście wcześniej sprawdziłbym znak liczby, ewentualnie
wyświetlił minus na wyświetlaczu i zmienił znak liczby na dodatni.
Sprawdziłbym też, czy wyświetlane ciągi ("Temperatura") nie są czasem
kopiowane do ramu po starcie uK i postarał się zadeklarować je jako
code/const/PSTR/etc.
--
Prawo jest jak płot - żmija zawsze się prześlizgnie,
tygrys zawsze przeskoczy a bydło tylko stoi i czeka.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: AVR GCC lub inny.
Date: Mon, 24 Jan 2005 18:26:10 +0100
No ostatnia aktualizacja to jakos Lipiec 2004. Biblioteki libc zmienily
sie bardzo in plus: http://www.nongnu.org/avr-libc/changes-1.2.html
dodali obsluge kilku mikrokontrolerow.. Takze nadal pozostaje pytanie,
czy mozna recznie zaktualizowac je w WinAVR.
Mozna wypróbować np.
http://avrfiles.luna.kyed.com/avr-libc/avr-libc-120-win.zip
Tylko nie wiem, czy lipcowe WinAvr ma zaszytą obsługę
wszystkich nowości ujętych w avr-libc ( na pewno jest błąd
mnożenia dla attiny 13 i 2313 ).
--
Pozdrowienia
Jurek Szczesiul
From: =?ISO-8859-2?Q?Ania_i_Grze=B6?= <brak_at_nospam_maila.pl>
Subject: Re: AVR GCC lub inny.
Date: Mon, 24 Jan 2005 20:04:18 +0100
Dnia 2005-01-24 18:26, Jurek Szczesiul napisał(a):
Mozna wypróbować np.
http://avrfiles.luna.kyed.com/avr-libc/avr-libc-120-win.zip
Authorization Required
This server could not verify that you are authorized to access the
document requested. Either you supplied the wrong credentials (e.g., bad
password), or your browser doesn't understand how to supply the
credentials required.
Apache/1.3.27 Server at avrfiles.luna.kyed.com Port 80
I na probowaniu sie zakonczylo, bo google milczy podajac nazwe pliku :)
--
Pozdrawiam, Ania i Grzes (Od 26.12.2004 mąż i żona)
- Żwirek kręci z Muchomorkiem!?
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 07:54:32 +0100
Mon, 24 Jan 2005 20:04:18 +0100, na pl.misc.elektronika, Ania i Grześ
napisał(a):
Apache/1.3.27 Server at avrfiles.luna.kyed.com Port 80
I na probowaniu sie zakonczylo, bo google milczy podajac nazwe pliku :)
Sorry :-( nie sprawdzałem osobiście - to namiar wzięty z avrfreaks.
--
Pozdrowienia
Jurek Szczesiul
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: AVR GCC lub inny.
Date: Fri, 28 Jan 2005 08:47:12 +0100
Mon, 24 Jan 2005 20:04:18 +0100, na pl.misc.elektronika, Ania i Grześ
napisał(a):
Authorization Required
I na probowaniu sie zakonczylo, bo google milczy podajac nazwe pliku :)
Sorry, nie podałem kompletu - sprawdź na www.avrfreaks.net -> forum avrgcc,
powinien byc gdzieś na początku anons.
Odnowiłem też dystrybucję na www.avrside.fr.pl :
- avr-gcc 3.4.3 ( release ) z patchem obsługi stałych w formacie binarnym,
wyjściem dla debuggera elf/dwarf2 i poprawionym zgrubnie błędem instrukcji
MUL dla attiny 13/2313;
- binutils 2.15 ( bez nie wspieranego już konwertera elf-coff );
- najnowsze avr-libc 1.2.0 ( z manualem html otwieranym z poziomu menu
AvrSide ).
Cały folder można rozpakować w dowolne miejsce bez nadpisywania
istniejacych w WinAvr plików. Jeśli użyjesz AvrSide to wystarczy ustawić
odpowiednio scieżkę dostępu. Jeśli używasz make - można wpisać żądaną
wersję kompilatora do makefile ( CC = ... ) .
--
Pozdrowienia
Jurek Szczesiul
From: "Q" <oink_at_nospam_gazeta.gov.pl>
Subject: Re: AVR GCC lub inny.
Date: Mon, 24 Jan 2005 14:23:23 +0100
Bo pewnie użyłeś printfa i zmiennego przecinka. Niestety nawet puts w
o tak,
printf, nawet w najbiedniejszej postaci,
zajmuje sporo flasha :(.
From: Willy <willyvmm_no_spam_at_nospam_interia._no_spam.pl>
Subject: Re: AVR GCC lub inny.
Date: Mon, 24 Jan 2005 20:32:20 +0100
Tydzien temu skompilowalem sobie avr-gcc4.0 i cala tego otoczke.
(poprawiony bug z Attiny13 i Attiny2313)
Wystawilem to dzisiaj na http://avr-gcc.newoldworld.net/ jak ktos jest
chetny to zapraszam.
Umnie zrobilem poprostu tak ze wrzucilem to do katalogu winavr
nadpisujac pliki. Wg mnie dziala ok. ale nie jestem tego w 100%
zagwarantowac.
Z moich obserwacji (gdzies to na necie tez przeczytalem) wynika ze
linker dla avr-gcc (a moze i nietylko) nie wyrzuca NIEUZYWANEGO kodu z
pliku wynikowego. Co powoduje wlasnie tak wielkie rozrastanie sie
kodu, ktory nic nie robi.
Pozdrawiam Willy.
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 08:01:20 +0100
Mon, 24 Jan 2005 20:32:20 +0100, na pl.misc.elektronika, Willy napisał(a):
Tydzien temu skompilowalem sobie avr-gcc4.0 i cala tego otoczke.
Czy musiałeś jakoś dodatkowo patchować czy 4.0 poszedł bez bólu ?
Mnie na lekko wcześniejszym mingwie wszystkie snapshoty 4.0
regularnie się wywracają.
Z moich obserwacji (gdzies to na necie tez przeczytalem) wynika ze
linker dla avr-gcc (a moze i nietylko) nie wyrzuca NIEUZYWANEGO kodu z
pliku wynikowego. Co powoduje wlasnie tak wielkie rozrastanie sie
kodu, ktory nic nie robi.
Dokładnie to jest tak, że linker avr-ld jeśli znajduje jakąś funkcję
skompilowaną do pliku relokowalnego *.o to zawsze dołącza cały kod z pliku,
niezależnie od jego wykorzystania. Radą na to jest składanie bibliotek z
małych pliczków relokowalnych zawierających pojedyncze funkcje. Wtedy
unikamy takiego balastu. Avr-libc jest właśnie tak przygotowane i ten efekt
jest zminimalizowany - gorzej jeśli korzystamy z jakichś dodatkowych
bibliotek skompilowanych bez zwrócenia na to uwagi .
--
Pozdrowienia
Jurek Szczesiul
From: Willy <willyvmm_no_spam_at_nospam_interia._no_spam.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 09:12:53 +0100
Jurek Szczesiul napisał(a):
Czy musiałeś jakoś dodatkowo patchować czy 4.0 poszedł bez bólu ?
Mnie na lekko wcześniejszym mingwie wszystkie snapshoty 4.0
regularnie się wywracają.
Toszkę musiałem z tym powalczyć ale udało mi się.
Przedewszystkim trzeba gcc budowac w podkatalogu jakimś, inaczej sie
wywala na samiutkim początku.
Potem pojawiły sie problemy z jakimiś liczbami 32 bitowymi których
niema obsługi w avr-gcc, ale znalazłem tymczasowy patch na bugzilli
który to poprawia to.
Ostatni problem polega na tym że gdy buduje się kompilator w
podkatalogu ... niemoże on kilku includow znaleźć z config/avr.
Lekarstwem na to jest podlikowanie tych kilku plików w odpowiednie
miejsca.
Generelnie 4 dni walczyłem z tym, ale wkońcu się udało :D
Jakbyś był zainteresowany to jak wrócę z pracy poszukam linka do tych
patchy (ręcznie je trzeba nanieść) albo poszukaj w bugzilli pod hasłem
avr data chyba z okolic 5 stycznia - ale mogę się mylić !
Pozdrawiam Willy.
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: AVR GCC lub inny.
Date: Fri, 28 Jan 2005 08:34:52 +0100
Tue, 25 Jan 2005 09:12:53 +0100, na pl.misc.elektronika, Willy napisał(a):
Jakbyś był zainteresowany to jak wrócę z pracy poszukam linka do tych
patchy (ręcznie je trzeba nanieść) albo poszukaj w bugzilli pod hasłem
avr data chyba z okolic 5 stycznia - ale mogę się mylić !
THX - ale chyba na razie to odpuszczę i poczekam na release.
--
Pozdrowienia
Jurek Szczesiul
From: Wojtek Kaniewski <wojtekka_at_nospam_SPAM.SPAM.SPAM>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 09:30:59 +0100
Willy wrote:
Z moich obserwacji (gdzies to na necie tez przeczytalem) wynika ze
linker dla avr-gcc (a moze i nietylko) nie wyrzuca NIEUZYWANEGO kodu z
pliku wynikowego. Co powoduje wlasnie tak wielkie rozrastanie sie kodu,
ktory nic nie robi.
bo i skąd ma wiedzieć, że dany kod nie będzie używany? dostaje binaria i
nie wie, czy to przypadkiem nie jest kod asemblerowy, który napisano
tak, że wyrzucenie kawałka kodu rozwali skoki względne, albo że któryś
symbol nie jest nieużywaną funkcja tylko tablicą danych?
inna sprawa, że użycie printf() faktycznie może dodać całe mnóstwo kodu,
którego nie będziesz używał, chociażby do wyświetlania liczb
zmiennoprzecinkowych. dlatego w avr-libc są różne warianty funkcji printf().
w.
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 11:28:07 +0100
Pewnego dnia Wojtek Kaniewski przemówił ludzkim głosem:
bo i skąd ma wiedzieć, że dany kod nie będzie używany?
Po pierwsze nie sprawdza się czy dany fragment kodu jest nieużywany,
tylko czy dana funkcja jest nieużywana (niewywoływana w żadnej innej
funkcji). I prawdę powiedziawszy nie wiem czemu linkier dla avr nie ma
takiej funkcjonalności.
--
Prawo jest jak płot - żmija zawsze się prześlizgnie,
tygrys zawsze przeskoczy a bydło tylko stoi i czeka.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
From: J.F. <jfox_xnospamx_at_nospam_poczta.onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 11:58:00 +0100
On Tue, 25 Jan 2005 11:28:07 +0100, Zbych wrote:
Pewnego dnia Wojtek Kaniewski przemówił ludzkim głosem:
bo i skąd ma wiedzieć, że dany kod nie będzie używany?
Po pierwsze nie sprawdza się czy dany fragment kodu jest nieużywany,
tylko czy dana funkcja jest nieużywana (niewywoływana w żadnej innej
funkcji). I prawdę powiedziawszy nie wiem czemu linkier dla avr nie ma
takiej funkcjonalności.
Bo to chyba obowiazuje dla bibliotek a nie poszczegolnych obj.
W obj to chyba nawet nie bardzo ma mozliwosci wyselekcjonawania
poszczegolnych funkcji - jest symbol i jest jego adres, nie ma
"dlugosci kodu".
J.
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 13:51:46 +0100
Pewnego dnia J.F. przemówił ludzkim głosem:
W obj to chyba nawet nie bardzo ma mozliwosci wyselekcjonawania
poszczegolnych funkcji - jest symbol i jest jego adres, nie ma
"dlugosci kodu".
Prawdopodobnie masz rację. Przejrzałem trochę pliki *.lst *.map *.lss i
w żadnym z nich nie ma informacji o długości (a pewnie by była gdyby
takie informacje były zawarte w plikach *.o). W takim wypadku należałoby
ustawić adresy funkcji rosnąco i obliczać rozmiar na podstawie adresu
funkcji i adresu następnej funkcji (a w przypadku ostatniej funkcji
rozmiaru biblioteki).
--
Prawo jest jak płot - żmija zawsze się prześlizgnie,
tygrys zawsze przeskoczy a bydło tylko stoi i czeka.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
From: Albert Bartoszko <albertb_at_nospam_nt.kegel.com.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 12:58:13 +0100
Użytkownik Zbych napisał:
Pewnego dnia Wojtek Kaniewski przemówił ludzkim głosem:
bo i skąd ma wiedzieć, że dany kod nie będzie używany?
Po pierwsze nie sprawdza się czy dany fragment kodu jest nieużywany,
tylko czy dana funkcja jest nieużywana (niewywoływana w żadnej innej
funkcji). I prawdę powiedziawszy nie wiem czemu linkier dla avr nie ma
takiej funkcjonalności.
Nie może mieć. Funkcje wywołuje się nie tylko jawnie,
ale np. przez wskaźnik zawarty w zmiennej.
A tą zmienną mogę ustawić na
wartość powodującą wywołanie tej "nieużywanej"
funkcji sporo po kompilacji.
Albert
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 13:19:08 +0100
Pewnego dnia Albert Bartoszko przemówił ludzkim głosem:
Nie może mieć. Funkcje wywołuje się nie tylko jawnie,
ale np. przez wskaźnik zawarty w zmiennej.
Masz rację. Ale i na to znalazłaby się rada. Nikt przecież nie wpisuje
ręcznie adresu funkcji do wskaźnika, tylko zleca uzupełnienie tego
adresu linkierowi (bo na etapie kompilacji adres funkcji nie musi być
znany). Czyli linkier może sprawdzić, czy gdzieś nie musi wstawić adresu
funkcji, a jeśli musi to stawia parafkę "ta funkcja jest potrzebna".
--
Prawo jest jak płot - żmija zawsze się prześlizgnie,
tygrys zawsze przeskoczy a bydło tylko stoi i czeka.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
From: J.F. <jfox_xnospamx_at_nospam_poczta.onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 13:28:34 +0100
On Tue, 25 Jan 2005 12:58:13 +0100, Albert Bartoszko wrote:
Po pierwsze nie sprawdza się czy dany fragment kodu jest nieużywany,
tylko czy dana funkcja jest nieużywana (niewywoływana w żadnej innej
funkcji). I prawdę powiedziawszy nie wiem czemu linkier dla avr nie ma
takiej funkcjonalności.
Nie może mieć. Funkcje wywołuje się nie tylko jawnie,
ale np. przez wskaźnik zawarty w zmiennej.
A tą zmienną mogę ustawić na
wartość powodującą wywołanie tej "nieużywanej"
funkcji sporo po kompilacji.
Ale wartosc do ustawienia musi ci linker wstawic, wiec wie ze
odwolanie jest.
J.
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 13:50:42 +0100
Albert Bartoszko wrote:
A tą zmienną mogę ustawić na
wartość powodującą wywołanie tej "nieużywanej"
funkcji sporo po kompilacji.
Nie mozesz, bo bez wskazania nazwy tej funkcji nie
bedziesz znal jej adresu, a takie wskazanie wystarcza
do stwierdzenia, ze funkcja moze byc uzywana, wiec
jej eliminacja jest niedozwolona.
BTW, to bardzo dziwne co mowicie o tym linkerze,
w "pelnym" GCC jest przeprowadzana eliminacja
nieuzywanych funkcji.
Pozdrawiam
Piotr Wyderski
From: Albert Bartoszko <albertb_at_nospam_nt.kegel.com.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 14:43:47 +0100
Użytkownik Piotr Wyderski napisał:
Albert Bartoszko wrote:
A tą zmienną mogę ustawić na
wartość powodującą wywołanie tej "nieużywanej"
funkcji sporo po kompilacji.
Nie mozesz, bo bez wskazania nazwy tej funkcji nie
bedziesz znal jej adresu, a takie wskazanie wystarcza
do stwierdzenia, ze funkcja moze byc uzywana, wiec
jej eliminacja jest niedozwolona.
A gdybym chciał wywoływać funkcję poprzez adres podany
przez RS z Pc-ta? ;-)
Albert
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 14:34:37 +0100
Albert Bartoszko wrote:
A gdybym chciał wywoływać funkcję poprzez adres podany
przez RS z Pc-ta? ;-)
W C formalnie nie istnieje cos takiego jak adres funkcji
w sensie konkretnej wartosci numerycznej, to nie jest
asembler. Z przyczyn technicznych taki numerek oczywiscie
jest, ale w C jesli cos nie zostalo nazwane, to nie istnieje.
Stad wywolanie funkcji o adresie podanym przez RS jest
najzwyklejszym dzialaniem niezdefiniowanym.
Pozdrawiam
Piotr Wyderski
From: Wojtek Kaniewski <wojtekka_at_nospam_SPAM.SPAM.SPAM>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 16:58:46 +0100
Piotr Wyderski wrote:
W C formalnie nie istnieje cos takiego jak adres funkcji
w sensie konkretnej wartosci numerycznej, to nie jest
asembler. Z przyczyn technicznych taki numerek oczywiscie
jest, ale w C jesli cos nie zostalo nazwane, to nie istnieje.
Stad wywolanie funkcji o adresie podanym przez RS jest
najzwyklejszym dzialaniem niezdefiniowanym.
więc poniższy kawałek rozpłynął się w obłoku logiki?
#include <stdio.h>
void test1(void) { printf("test1\n"); }
void test2(void) { printf("test2\n"); }
int main(void)
{
void (*test)(void);
printf("wybierz funkcje %p lub %p\n", test1, test2);
scanf("%p", &test);
(*test)();
return 0;
}
w.
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 21:58:16 +0100
Pewnego dnia Wojtek Kaniewski przemówił ludzkim głosem:
więc poniższy kawałek rozpłynął się w obłoku logiki?
printf("wybierz funkcje %p lub %p\n", test1, test2);
^^^^^^^^^^^^^^
Zapomniałeś tylko o tym, że ktoś musi wstawić wartości liczbowe pod te
dwa wskaźniki i dzięki temu można te dwie funkcje "zaznaczyć" jako używane.
--
Prawo jest jak płot - żmija zawsze się prześlizgnie,
tygrys zawsze przeskoczy a bydło tylko stoi i czeka.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
From: Wojtek Kaniewski <wojtekka_at_nospam_SPAM.SPAM.SPAM>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 23:33:42 +0100
Zbych wrote:
Zapomniałeś tylko o tym, że ktoś musi wstawić wartości liczbowe pod te
dwa wskaźniki i dzięki temu można te dwie funkcje "zaznaczyć" jako używane.
ups, mea culpa.
tak czy inaczej, równie dobrze można napisać prosty system operacyjny,
który dynamicznie ładuje programy do flasha przez SPM. programy nie
muszą być kompilowane w otoczeniu samego systemu operacyjnego, a adresy
odpowiednich funkcji systemowych mogą zostać pobrane z binarów systemu
operacyjnego zaraz po kompilacji za pomocą avr-nm. dlaczego linker
miałby cokolwiek wyrzucać?
w.
From: J.F. <jfox_xnospamx_at_nospam_poczta.onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 16:05:07 +0100
On Tue, 25 Jan 2005 23:33:42 +0100, Wojtek Kaniewski wrote:
tak czy inaczej, równie dobrze można napisać prosty system operacyjny,
który dynamicznie ładuje programy do flasha przez SPM. programy nie
muszą być kompilowane w otoczeniu samego systemu operacyjnego, a adresy
odpowiednich funkcji systemowych mogą zostać pobrane z binarów systemu
operacyjnego zaraz po kompilacji za pomocą avr-nm. dlaczego linker
miałby cokolwiek wyrzucać?
bo programiscie zalezy na krotkim kodzie :-)
I przeciez jest wygodny, wiec nie bedzie przepisywal z wydrukow
linkera gdzie ten dana funkcje wstawil.
Wiec linker wie ze jest wstawiona :-)
J.
From: Albert Bartoszko <albertb_at_nospam_nt.kegel.com.pl>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 07:29:48 +0100
Użytkownik Piotr Wyderski napisał:
Albert Bartoszko wrote:
A gdybym chciał wywoływać funkcję poprzez adres podany
przez RS z Pc-ta? ;-)
W C formalnie nie istnieje cos takiego jak adres funkcji
w sensie konkretnej wartosci numerycznej, to nie jest
asembler. Z przyczyn technicznych taki numerek oczywiscie
jest, ale w C jesli cos nie zostalo nazwane, to nie istnieje.
Stad wywolanie funkcji o adresie podanym przez RS jest
najzwyklejszym dzialaniem niezdefiniowanym.
W standardzie C formalnie nie istnieje.
Ale zastanówmy się, jak to się ma do omawianego przykładu.
Po pierwsze w implementacji kompilatora musi to być
określone z powodów podanych przez Ciebie ;-)
W ten sposób są zdefiniowane np. procedury obsługi przerwań
o stałych adresach. Jeśli znajdziesz inny sposób zgodny
w Twoim mniemaniu ze standardami C to będzie on zarazem
sposobem na wywołanie mojej funkcji ;-)
Po drugie ja z założenia w kodzie źródłowym w C nie
używam takiej konstrukcji bo nie chcę dać szansy
linkerowi na znalezienie, że funkcja jest używana.
Więc mój kod źródłowy może być całkowicie zgodny ze
standardem. Prawda?
A wywołanie funkcji o adresie podanym przez RS?
Toż w tym czasie kod źródłowy może już nie istnieć.
A to co jest wykonywane to KOD MASZYNOWY i standardów
C nie można do niego stosować.
Albert
From: Krzysztof Rudnik <rudnik_at_nospam_kki.net.pl>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 08:49:21 +0100
Piotr Wyderski wrote:
Albert Bartoszko wrote:
A tą zmienną mogę ustawić na
wartość powodującą wywołanie tej "nieużywanej"
funkcji sporo po kompilacji.
Nie mozesz, bo bez wskazania nazwy tej funkcji nie
bedziesz znal jej adresu, a takie wskazanie wystarcza
do stwierdzenia, ze funkcja moze byc uzywana, wiec
jej eliminacja jest niedozwolona.
BTW, to bardzo dziwne co mowicie o tym linkerze,
w "pelnym" GCC jest przeprowadzana eliminacja
nieuzywanych funkcji.
Wydaje mi sie, ze eliminowane sa nieuzywane pliki
posrednie (.o, .obj) jesli do linkowania wchodza w
bibliotekach statycznie linkowalnych (.a).
Podanie do linkowania bezposrednio pliku .o
spowoduje ze zostanie on wlaczony bezwarunkowo.
Zawartosc pojedynczego pliku posredniego
nie moze byc przez linker zmodyfkowana (poza
uzupelnieniem adresow) do moze on zawierac
miedzyfunkcyjne wywolania niewidoczne dla
linkera (np. funkcje static) itp.
Krzysiek Rudnik
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 13:46:38 +0100
Zbych wrote:
Po pierwsze nie sprawdza się czy dany fragment kodu jest nieużywany,
Sprawdza, nazywa sie to "dead code elimination" i jest
przeprowadzane przez optymalizator, jesli potrafi on
udowodnic, ze dla danego zbioru parametrow nie istnieje
sciezka przeplywu sterowania prowadzaca do tego kodu.
Ale oczywiscie nie jest to az tak rozbudowane, by umiec
wyrzucic pewne fragmenty kodu z printf(), tu masz racje.
Pozdrawiam
Piotr Wyderski
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 14:01:04 +0100
Pewnego dnia Piotr Wyderski przemówił ludzkim głosem:
Sprawdza, nazywa sie to "dead code elimination" i jest
przeprowadzane przez optymalizator,
To i ja wiem :-). Dziwię się tylko czemu nikt tego nie zaimplementował w
narzędziach z serii gcc (a może to tylko przypadłość portu dla avr?).
--
Prawo jest jak płot - żmija zawsze się prześlizgnie,
tygrys zawsze przeskoczy a bydło tylko stoi i czeka.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
From: "Piotr Wyderski" <wyderskiREMOVE_at_nospam_ii.uni.wroc.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 14:30:46 +0100
Zbych wrote:
Dziwię się tylko czemu nikt tego nie zaimplementował
w narzędziach z serii gcc
DCE jest w GCC od dawna, ale to nie jest eliminacja
nieuzywanych funkcji -- DCE dziala na poziomie blokow
bazowych.
(a może to tylko przypadłość portu dla avr?).
Moze, ale mnie sie wydaje, ze pytajacy po prostu nie
potrafi naklonic linkera do odpowiedniego dzialania. :-)
Pozdrawiam
Piotr Wyderski
From: Wojtek Kaniewski <wojtekka_at_nospam_SPAM.SPAM.SPAM>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 17:04:23 +0100
Piotr Wyderski wrote:
Sprawdza, nazywa sie to "dead code elimination" i jest
przeprowadzane przez optymalizator, jesli potrafi on
udowodnic, ze dla danego zbioru parametrow nie istnieje
sciezka przeplywu sterowania prowadzaca do tego kodu.
Ale oczywiscie nie jest to az tak rozbudowane, by umiec
wyrzucic pewne fragmenty kodu z printf(), tu masz racje.
tyle że kompilator może sprawdzić kod w obrębie jednego pliku. wszystkie
funkcje nie zadeklarowane jako statyczne mogą być wywołane z zewnątrz.
w.
From: Wojtek Kaniewski <wojtekka_at_nospam_SPAM.SPAM.SPAM>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 17:01:54 +0100
Zbych wrote:
Po pierwsze nie sprawdza się czy dany fragment kodu jest nieużywany,
tylko czy dana funkcja jest nieużywana (niewywoływana w żadnej innej
funkcji).
tym się zajmuje kompilator, jak już niektórzy wspomnieli.
I prawdę powiedziawszy nie wiem czemu linkier dla avr nie ma
takiej funkcjonalności.
linker zajmuje się linkowaniem kodu, nie optymalizacją.
w.
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Tue, 25 Jan 2005 21:55:06 +0100
Pewnego dnia Wojtek Kaniewski przemówił ludzkim głosem:
tym się zajmuje kompilator, jak już niektórzy wspomnieli.
A co z takim razie z gotowymi, skompilowanymi bibliotekami zawierającymi
kilkadziesiąt funkcji ? W tym przypadku kompilator raczej nie się nie
przyda, a zadanie wyboru używanych funkcji spada właśnie na linkier.
linker zajmuje się linkowaniem kodu, nie optymalizacją.
Nie mam zamiaru sprzeczać się co do podziału zadań między linkierem a
optymalizatorem, ale logiczne wydaje mi się usuwanie zbędnych fragmentów
na etapie linkowania, bo mamy wtedy pełną informację co do wzajemnych
zależności między funkcjami (i nie tylko w ramach jednej biblioteki, a w
ramach całego projektu).
--
Prawo jest jak płot - żmija zawsze się prześlizgnie,
tygrys zawsze przeskoczy a bydło tylko stoi i czeka.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
From: Wojtek Kaniewski <wojtekka_at_nospam_SPAM.SPAM.SPAM>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 00:26:30 +0100
Zbych wrote:
tym się zajmuje kompilator, jak już niektórzy wspomnieli.
A co z takim razie z gotowymi, skompilowanymi bibliotekami zawierającymi
kilkadziesiąt funkcji ? W tym przypadku kompilator raczej nie się nie
przyda, a zadanie wyboru używanych funkcji spada właśnie na linkier.
linker może wybrać co najwyżej używane pliki obiektowe, bo operuje na
plikach, nie funkcjach czy symbolach. zadaniem programisty jest takie
podzielenie biblioteki na osobne pliki obiektowe, żeby więcej niż jedną
funkcję umieszczać w pliku obiektowym tylko i wyłącznie, gdy jedna bez
drugiej nie może działać.
tak czy inaczej avr-libc jest tworzona zgodnie z tymi zasadami i do kodu
wynikowego nie powinny trafić żadne nieużywane funkcje. jeśli jest
inaczej, wypadałoby zgłosić błąd autorom.
w.
From: JS <_do_not_use__at_nospam_polbox.com>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 10:16:18 +0000 (UTC)
W artykule <ct5qlq$qnh$2_at_nospam_inews.gazeta.pl>
autorem którego mieni się Wojtek Kaniewski, napisano:
linker zajmuje się linkowaniem kodu, nie optymalizacją.
Mógłby się zajmować optymalizacją zewnętrznych
skoków i wywołań funkcji, tzn. wybierać instrukcje
z adresowaniem względnym (rcall) tam, gdzie cel leży
w zasięgu, zamiast stosować wszędzie adresy długie
(call).
Mógłby nawet optymalizować pod tym kątem kolejność
linkowania modułów.
BTW, może jednak się zajmuje, a ja o czymś nie wiem ?
GCC dla Hitachi H8 to umie (code relaxing).
--
Moje konto na Polboksie to jar0sz
Pozdrawiam
Jarosław Szynal
From: J.F. <jfox_xnospamx_at_nospam_poczta.onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 16:17:19 +0100
On Wed, 26 Jan 2005 10:16:18 +0000 (UTC), JS wrote:
W artykule <ct5qlq$qnh$2_at_nospam_inews.gazeta.pl>
linker zajmuje się linkowaniem kodu, nie optymalizacją.
Mógłby się zajmować optymalizacją zewnętrznych
skoków i wywołań funkcji, tzn. wybierać instrukcje
z adresowaniem względnym (rcall) tam, gdzie cel leży
w zasięgu, zamiast stosować wszędzie adresy długie
(call).
I co - ma dopelnic nopami i czy przesuwac kod ?
J.
From: JS <_do_not_use__at_nospam_polbox.com>
Subject: Re: AVR GCC lub inny.
Date: Thu, 27 Jan 2005 18:23:50 +0000 (UTC)
W artykule <aicfv090a14q73iom0o30vtsqsaii05n2v_at_nospam_4ax.com>
autorem którego mieni się J.F, napisano:
On Wed, 26 Jan 2005 10:16:18 +0000 (UTC), JS wrote:
W artykule <ct5qlq$qnh$2_at_nospam_inews.gazeta.pl>
linker zajmuje się linkowaniem kodu, nie optymalizacją.
Mógłby się zajmować optymalizacją zewnętrznych
skoków i wywołań funkcji, tzn. wybierać instrukcje
z adresowaniem względnym (rcall) tam, gdzie cel leży
w zasięgu, zamiast stosować wszędzie adresy długie
(call).
I co - ma dopelnic nopami i czy przesuwac kod ?
Jak dopełni, zysk będzie w jednym cyklu czasu wykonania mniej,
czyli taki sobie.
Jak przesunie - oprócz w.w. się kod skróci, ale co linker
się bajtami namacha, to jego. Nie wspominając już, że musi
wiedzieć, którymi.
Sprawdziłem na programie dla ATmegi128:
- rozmiar kodu wynikowewgo ok. 100k (bez bibliotek i stałych),
- 3208 instrukcji call,
- 768 instrukcji można zamienić na rcall (pewnie nieco więcej,
nie analizowałem dokładnie), wtedy kod skróciłby się o ok. 1.5%
Wywołania wewnątrzmodułowe (nawet funkcji statycznych)
są też realizowane przez call. Optymalizacja wykonywana
podczas generowania kodu (w obrębie jednostki kompilacji),
realizowana tylko przez komilator, mogłaby być znacznie
prostsza do realizacji (i być może da to większość korzyści
możliwych do osiągnięcia tą metodą, bez potrzeby angażowania
linkera).
--
Moje konto na Polboksie to jar0sz
Pozdrawiam
Jarosław Szynal
From: Wojtek Kaniewski <wojtekka_at_nospam_SPAM.SPAM.SPAM>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 17:14:12 +0100
JS wrote:
linker zajmuje się linkowaniem kodu, nie optymalizacją.
Mógłby się zajmować optymalizacją zewnętrznych
skoków i wywołań funkcji, (...)
dla niektórych architektur to jest obsługiwane przez gcc i ld, ale
akurat dla avr nie. zresztą co innego zmienić rodzaj relokacji i wstawić
inną daną w konkretne miejsce w kodzie (nie trzeba przypadkiem używać
-fPIC?), co innego usuwać i przestawiać kawałki kodu będące z punktu
widzenia linkera jedną logiczną całością.
w.
From: Albert Bartoszko <albertb_at_nospam_nt.kegel.com.pl>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 07:29:53 +0100
Użytkownik Zbych napisał:
Pewnego dnia Wojtek Kaniewski przemówił ludzkim głosem:
bo i skąd ma wiedzieć, że dany kod nie będzie używany?
Po pierwsze nie sprawdza się czy dany fragment kodu jest nieużywany,
tylko czy dana funkcja jest nieużywana (niewywoływana w żadnej innej
funkcji). I prawdę powiedziawszy nie wiem czemu linkier dla avr nie ma
takiej funkcjonalności.
A który ma?
Prosty test: test.c
*************************************
test(){}
main(){}
*************************************
Dla ułatwienia zadania funkcja test() jest nie tylko nieużywana,
ale także pusta i bez parametrów.
Kto pokaże mi jaki kompilator/linker, z jakimi parametrami
i ewentualnie dla jakiego procesora wyeliminuje
kod funkcji test() z pliku wykonywalnego?
Myślę, że może to być jeden z prostych testów jakości kompliatora,
bo porównywanie ich to zawsze powód do flame war ;-)
Albert
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 11:14:14 +0100
Pewnego dnia Albert Bartoszko przemówił ludzkim głosem:
A który ma?
test(){}
main(){}
Kto pokaże mi jaki kompilator/linker, z jakimi parametrami
i ewentualnie dla jakiego procesora wyeliminuje
kod funkcji test() z pliku wykonywalnego?
keil to robi. program po kompilacji ma 17 bajtów (zerowanie pamięci +
ustawienie stosu + skok do main). Czyli jednak da się wyrzucić
automatycznie nieużywany kod :-)
--
Prawo jest jak płot - żmija zawsze się prześlizgnie,
tygrys zawsze przeskoczy a bydło tylko stoi i czeka.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
From: "Krzysztof Rudnik" <rudnik_at_nospam_kki.net.pl>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 12:04:22 +0100
Użytkownik "Zbych" <abuse_at_nospam_onet.pl> napisał w wiadomości
news:ct7qhn$h4r$1_at_nospam_julia.coi.pw.edu.pl...
Pewnego dnia Albert Bartoszko przemówił ludzkim głosem:
A który ma?
test(){}
main(){}
Kto pokaże mi jaki kompilator/linker, z jakimi parametrami
i ewentualnie dla jakiego procesora wyeliminuje
kod funkcji test() z pliku wykonywalnego?
keil to robi. program po kompilacji ma 17 bajtów (zerowanie pamięci +
ustawienie stosu + skok do main). Czyli jednak da się wyrzucić
A co robi funkcja ta main?
automatycznie nieużywany kod :-)
To jest blad - nie ma pewnosci ze funkcja test nie zostanie uzyta z
zewnatrz.
W tym szczegolnym przypadku - mamy main i widzimy ze jest pusty tak jest,
ale gdyby to byl jakis modul nie wolno wyrzucic zadnej funkcji nie-static.
Ciekawe czy gdyby w main bylo wywolanie jakiejs funkcji (np. bibliotecznej)
Krzysiek Rudnik
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 12:07:23 +0100
Pewnego dnia Krzysztof Rudnik przemówił ludzkim głosem:
To jest blad -
Tak, mój :-). Wyjaśnienie we wcześniejszym poście.
--
Prawo jest jak płot - żmija zawsze się prześlizgnie,
tygrys zawsze przeskoczy a bydło tylko stoi i czeka.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
From: Albert Bartoszko <albertb_at_nospam_nt.kegel.com.pl>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 12:09:40 +0100
Użytkownik Zbych napisał:
Pewnego dnia Albert Bartoszko przemówił ludzkim głosem:
A który ma?
test(){}
main(){}
Kto pokaże mi jaki kompilator/linker, z jakimi parametrami
i ewentualnie dla jakiego procesora wyeliminuje
kod funkcji test() z pliku wykonywalnego?
keil to robi. program po kompilacji ma 17 bajtów (zerowanie pamięci +
ustawienie stosu + skok do main). Czyli jednak da się wyrzucić
automatycznie nieużywany kod :-)
Jasne, że się da. Ja pisałem "nie może" w sensie "nie powinien",
a nie "nie da się". Potwierdza to chyba przykład programu,
który podałem.
Nie używam keila (tak samo jak avr-gcc ;-) ). Czy robi to
domyślnie, czy po podaniu jakichś specjalnych parametrów do
optymalizacji?
Moim zdaniem w drugim przypadku świadczy to o jego przewadze w stosunku
do avr-gcc, a w pierwszym odwrotnie ;-)
I jeszcze prośba. Podeślij kod wynikowy, z chęcią obejrzę.
Albert
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 12:05:24 +0100
Pewnego dnia Albert Bartoszko przemówił ludzkim głosem:
Jasne, że się da. Ja pisałem "nie może" w sensie "nie powinien",
a nie "nie da się". Potwierdza to chyba przykład programu,
który podałem.
Niestety muszę odwołać to co napisałem. Przeoczyłem, że jednak kawałek
funkcji zostaje (ret). A dałbym sobie głowę uciąć, że nieużywane funkcje
są wycinane :-)
MOV R0,#0x7F
CLR A
L01:
MOV _at_nospam_R0,A
DJNZ R0,L01
MOV SP(0x81),#0x07
LJMP main
11: test(){}
12:
RET
13: void main(void)
RET
--
Prawo jest jak płot - żmija zawsze się prześlizgnie,
tygrys zawsze przeskoczy a bydło tylko stoi i czeka.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
From: "Krzysztof Rudnik" <rudnik_at_nospam_kki.net.pl>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 12:29:49 +0100
Użytkownik "Zbych" <abuse_at_nospam_onet.pl> napisał w wiadomości
news:ct7thm$e8b$1_at_nospam_julia.coi.pw.edu.pl...
Pewnego dnia Albert Bartoszko przemówił ludzkim głosem:
Jasne, że się da. Ja pisałem "nie może" w sensie "nie powinien",
a nie "nie da się". Potwierdza to chyba przykład programu,
który podałem.
Niestety muszę odwołać to co napisałem. Przeoczyłem, że jednak kawałek
funkcji zostaje (ret). A dałbym sobie głowę uciąć, że nieużywane funkcje
są wycinane :-)
[ ciach kod startowy ]
11: test(){}
12:
RET
13: void main(void)
RET
Wlasnie, jedna instrukcje (zoptymalizowana wesja pustej funkcji)
latwo przeoczyc. Daj:
static test()
{
}
i wtedy jej nie bedzie.
Juz ktos napisac w innym watku, moze powtorze:
piszemy kazda funkcje w oddzielnym pliku .c
wyniki (pliki .o) laczymy w biblioteke statyczna .a (ar w normalnym gcc)
linkujemy ta biblioteke (plik z main dobrze jest zostawic na zewnatrz
biblioteki jako .o - wtedy biblioteka bedzie mogla sie jeszcze do czegos
przydac)
W takiej wersji z biblioteki zostana pobrane tylko uzywane w programie
funkcje.
Krzysiek Rudnik
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 12:34:38 +0100
Pewnego dnia Krzysztof Rudnik przemówił ludzkim głosem:
Daj:
static test()
{
}
i wtedy jej nie bedzie.
dalej jest
Juz ktos napisac w innym watku, moze powtorze:
i ta recepta mi się podoba :-)
--
Prawo jest jak płot - żmija zawsze się prześlizgnie,
tygrys zawsze przeskoczy a bydło tylko stoi i czeka.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
From: J.F. <jfox_xnospamx_at_nospam_poczta.onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 16:17:19 +0100
On Wed, 26 Jan 2005 12:34:38 +0100, Zbych wrote:
Pewnego dnia Krzysztof Rudnik przemówił ludzkim głosem:
Daj:
static test()
{
}
i wtedy jej nie bedzie.
dalej jest
W sumie powinno - dosc skomplikowane bedzie sprawdzenie przez
kompilator ze jest to funkcja nieuzywana.
J.
From: "Krzysztof Rudnik" <rudnik_at_nospam_kki.net.pl>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 17:01:12 +0100
Użytkownik "J.F." <jfox_xnospamx_at_nospam_poczta.onet.pl> napisał w wiadomości
news:mdcfv05evfnr73o840m8d2j2v47b58t4en_at_nospam_4ax.com...
On Wed, 26 Jan 2005 12:34:38 +0100, Zbych wrote:
Pewnego dnia Krzysztof Rudnik przemówił ludzkim głosem:
Daj:
static test()
{
}
i wtedy jej nie bedzie.
dalej jest
W sumie powinno - dosc skomplikowane bedzie sprawdzenie przez
kompilator ze jest to funkcja nieuzywana.
Static - czyli moze byc uzyta tylko wewnatrz jednego pliku - przy
odpowiednich
opcjach optymalizacji gcc takie rzeczy pomija. Nie pamietam,
czy nie daje ostrzezenia.
Krzysiek Rudnik
From: J.F. <jfox_xnospamx_at_nospam_poczta.onet.pl>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 16:05:07 +0100
On Wed, 26 Jan 2005 11:14:14 +0100, Zbych wrote:
Pewnego dnia Albert Bartoszko przemówił ludzkim głosem:
A który ma?
test(){}
main(){}
Kto pokaże mi jaki kompilator/linker, z jakimi parametrami
i ewentualnie dla jakiego procesora wyeliminuje
kod funkcji test() z pliku wykonywalnego?
keil to robi. program po kompilacji ma 17 bajtów (zerowanie pamięci +
ustawienie stosu + skok do main). Czyli jednak da się wyrzucić
automatycznie nieużywany kod :-)
Sprawdz najpierw czy w tych 17 bajtach nie miesci sie 1 bajt procedury
test :-)
Ale i tak moze byc to sprawka kompilatora - nie ma tresci to nie
skompilowal .. chociaz powinien, bo byc moze sa odwolania w innym
pliku.
J.
From: AK <arkkar_at_nospam_tiscali.usunto.de>
Subject: Re: AVR GCC lub inny.
Date: Wed, 26 Jan 2005 20:28:16 +0100
Albert Bartoszko napisaĹ(a):
UĹźytkownik Zbych napisaĹ:
Pewnego dnia Wojtek Kaniewski przemĂłwiĹ ludzkim gĹosem:
bo i skÄ
d ma wiedzieÄ, Ĺźe dany kod nie bÄdzie uĹźywany?
Po pierwsze nie sprawdza siÄ czy dany fragment kodu jest nieuĹźywany,
tylko czy dana funkcja jest nieuĹźywana (niewywoĹywana w Ĺźadnej innej
funkcji). I prawdÄ powiedziawszy nie wiem czemu linkier dla avr nie ma
takiej funkcjonalnoĹci.
A ktĂłry ma?
Prosty test: test.c
*************************************
test(){}
main(){}
*************************************
Dla uĹatwienia zadania funkcja test() jest nie tylko nieuĹźywana,
ale takĹźe pusta i bez parametrĂłw.
Kto pokaĹźe mi jaki kompilator/linker, z jakimi parametrami
i ewentualnie dla jakiego procesora wyeliminuje
kod funkcji test() z pliku wykonywalnego?
Np. IAR dla AVR
--
Pozdr
AK
From: Albert Bartoszko <albertb_at_nospam_nt.kegel.com.pl>
Subject: Re: AVR GCC lub inny.
Date: Thu, 27 Jan 2005 07:56:30 +0100
UĹźytkownik AK napisaĹ:
[...]
Prosty test: test.c
*************************************
test(){}
main(){}
*************************************
Dla uĹatwienia zadania funkcja test() jest nie tylko nieuĹźywana,
ale takĹźe pusta i bez parametrĂłw.
Kto pokaĹźe mi jaki kompilator/linker, z jakimi parametrami
i ewentualnie dla jakiego procesora wyeliminuje
kod funkcji test() z pliku wykonywalnego?
Np. IAR dla AVR
A moĹźna prosiÄ o kod wynikowy / ustawienia parametrĂłw kompilacji?
Albert
From: AK <arkkar_at_nospam_tiscali.usunto.de>
Subject: Re: AVR GCC lub inny.
Date: Thu, 27 Jan 2005 21:44:04 +0100
Albert Bartoszko napisaĹ(a):
A moĹźna prosiÄ o kod wynikowy / ustawienia parametrĂłw kompilacji?
Albert
Oczywiscie:
Mamy dwa pliki:
plik test.c
--------------------------------------------
#include <iom128.h>
#include <stdio.h>
extern int ext_function(int y);
int function1(int x, int c)
{
int i = 0;
while(x--)
{
i += (x * 1000) + (c/2);
c += 34;
i &= 0xFFFE;
}
return i;
}
void main(void)
{
int z;
z = ext_function(2345);
z = function1(z, 1234);
printf("Result: %d", z);
while(1);
}
------------------------------------------------------
plik test_2.c
------------------------------------------------------
#include <stdlib.h>
int ext_function(int y)
{
y *= 2;
return abs(y);
}
--------------------------------------------------------
I teraz wyniki kompilacji i linkowania:
rozmiar rozmiar rozmiar
kodu pliku pliku
wynikowego test.c test_2.c
1. Pliki kompilowane w postaci jak powyzej 5884 141 8
2. Pliki kompilowane z usunietym wywolaniem
funkcji <function1> (zaremowane) 5778 135 8
3. Pliki kompilowane z usunietym wywolaniem
funkcji <function1> i z usunieta sama
funkcja <function1> 5778 35 8
Jak widac, w przypadku drugim, cala funkcja zostala usunieta przez
linker ,
Kompilator: IAR AVR 3.10C
Opcje kompilacji i linkowania:
-------------------------------------------------------------------
MAKE Version 5.2 Copyright (c) 1987, 2000 Borland
Compiling src\test.c
iccavr -I \INC\DLIB\ -I \INC\ -I ..\Common\ -I
..\common\rtos\include -I Include -o _obj\ --cpu=m128
-DENABLE_BIT_DEFINITIONS -lC _lst -r -ms -e -s9 -y src\test.c
IAR Atmel AVR C/EC++ Compiler V3.10C/W32
Copyright 1996-2004 IAR Systems. All rights reserved.
135 bytes of CODE memory (+ 7 bytes shared)
11 bytes of DATA memory
Errors: none
Warnings: none
Compiling src\test_2.c
iccavr -I \INC\DLIB\ -I \INC\ -I ..\Common\ -I
..\common\rtos\include -I Include -o _obj\ --cpu=m128
-DENABLE_BIT_DEFINITIONS -lC _lst -r -ms -e -s9 -y src\test_2.c
IAR Atmel AVR C/EC++ Compiler V3.10C/W32
Copyright 1996-2004 IAR Systems. All rights reserved.
8 bytes of CODE memory
Errors: none
Warnings: none
xlink.exe -I_obj test.r90 test_2.r90 \LIB\DLIB\dl3s-ec.r90
-I\LIB\\DLIB\ -f cfgm128.xcl -D_..X_HEAP_SIZE=10
-D_..X_CSTACK_SIZE=A0 -D_..X_RSTACK_SIZE=20 -D_..X_EXT_CSTACK_BASE=0
-D_..X_EXT_CSTACK_END=0 -D_..X_EXT_SRAM_BASE=0 -D_..X_EXT_SRAM_END=0
-D_..X_EXT_RSTACK_BASE=0 -D_..X_EXT_RSTACK_END=0
-D_..X_EXT_ROM_BASE=0 -D_..X_EXT_ROM_END=0 -D_..X_EXT_NV_BASE=0
-D_..X_EXT_NV_END=0 -e_small_write=_formatted_write
-e_medium_read=_formatted_read -f cfg3s.xcl
-D_..X_FLASH_BASE=_..X_INTVEC_SIZE -H1895
-h(CODE)0-(_..X_INTVEC_SIZE-1) -xsem -ws -l
_lst\test_out_01_MemoryMap.txt -Fubrof8 -o _exe\test_out_01.d90
-Ointel-extended,(CODE)=_exe\test_out_01.hex
-Ointel-extended,(XDATA)=_exe\test_out_01.eep -ws
IAR Universal Linker V4.58A/386
Copyright 1987-2004 IAR Systems. All rights reserved.
5 884 bytes of CODE memory (+ 136 range fill )
275 bytes of DATA memory
Errors: none
Warnings: none
---------------------------------------------------------------------
--
Pozdr
AK