Dziwne zachowanie kompilatora w AVRGCC.
Masz problem? Zapytaj na forum elektroda.pl
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Dziwne zachowanie kompilatora w AVRGCC.
Date: Wed, 05 May 2004 01:59:51 +0200
Ehlo.
Jako ze guru wiedzy na temat C jeszcze nie jestem (ale zamierzam ;-)))
), wynalazlem pewien problem ktory mnie meczy. Mianowicie w programie
definiuje znaki LCD za w nastepujacy sposob:
definicje znakow:
static unsigned char _attribute_ ((progmem)) polish_chars[]={
0x0C,0x04,0x06,0x0C,0x04,0x04,0x0E,0x00, //0 - l
[...]
0x00,0x04,0x0E,0x10,0x10,0x11,0x0E,0x00}; //5 = c
for (unsigned char f=1;f<64;f++)
{
lcd_port=pgm_read_byte(&polish_chars+f);
data_port |= (unsigned char)_BV(rs);
nop();nop();nop();
data_port |= (unsigned char)_BV(en);
nop();nop();nop();
data_port &= (unsigned char)~_BV(en);
data_port &= (unsigned char)~_BV(rs);
lcd_delay_short();
}
No i problem. Mianowicie wartosc wyliczona przez (&polish_chars+f) w
pierwszym odczycie daje poprawnie wartosc 0x22, jednak w kolejnym kroku
kompilator zwieksza Z nie o jeden jak powinien lecz o 0x31 (cos jakby
wartosc '1' w ASCII). Popelniam jakis blad ??
Za to ten programik dziala poprawnie. Z jest zwiekszane o 0x01.
unsigned char f=0;
int g;
g=(&polish_chars);
while (f<64)
{
lcd_port=pgm_read_byte(g+f);
data_port |= (unsigned char)_BV(rs);
nop();nop();nop();
data_port |= (unsigned char)_BV(en);
nop();nop();nop();
data_port &= (unsigned char)~_BV(en);
data_port &= (unsigned char)~_BV(rs);
lcd_delay_short();
f++;
}
Moze mi ktos wytlumaczyc czy to ja robie zle czy co ? Z gorki dzieki.
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.internetia.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Wed, 05 May 2004 02:24:23 +0200
Milosz Skowyra wrote:
Juz sam wiem, olalem warninga kompilatora i zapomnialem o zrzutowaniu
wskaznika na integera ;-)
lcd_port=pgm_read_byte(&polish_chars+f);
powinno byc
lcd_port=pgm_read_byte(((int)&polish_chars)+f);
I dziala ;-)
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: "Tomq" <tomq_at_nospam_nieistnieje.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Wed, 5 May 2004 08:38:28 +0200
Juz sam wiem, olalem warninga kompilatora i zapomnialem o zrzutowaniu
wskaznika na integera ;-)
lcd_port=pgm_read_byte(&polish_chars+f);
powinno byc
lcd_port=pgm_read_byte(((int)&polish_chars)+f);
nie jestem specem, ale kiedyś chciałbym być. proszę mnie oświecić
dlaczwgo "int" ? przecież tablica była definiowana jako "unsigned char"
"f" również, skąd i po co " int " ?
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Wed, 05 May 2004 12:32:24 +0200
On Wed, 5 May 2004 08:38:28 +0200, Tomq wrote:
Juz sam wiem, olalem warninga kompilatora i zapomnialem o zrzutowaniu
wskaznika na integera ;-)
lcd_port=pgm_read_byte(&polish_chars+f);
powinno byc
lcd_port=pgm_read_byte(((int)&polish_chars)+f);
nie jestem specem, ale kiedyś chciałbym być. proszę mnie oświecić
dlaczwgo "int" ? przecież tablica była definiowana jako "unsigned char"
"f" również, skąd i po co " int " ?
Bo sa dwa problemy:
a) .. '51 .. kto wie jaki rozmiar ma wskaznik, byc moze tylko
1 bajt ? Wiec wskaznik plus char moze sie ograniczac do 256.
b) kolega przekombinowal [a raczej nie przeczytal pewnej ksiazki :-)]
polish_chars+f powinno dzialac dobrze.
ale &polish_chars wskazuje na cala tablice i ma rozmiar jej calej,
wiec &polish_chars+1 to adres calej kolejnej tablicy, a nie
drugiego elementu ..
J.
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Wed, 05 May 2004 15:09:37 +0200
"J.F." wrote:
b) kolega przekombinowal [a raczej nie przeczytal pewnej ksiazki :-)]
Czytam powoli... i podpieram sie dodatkowo kieszonkowym leksykonem C++.
Tyle tylko ze nie dopisalem kontekstu programu. Po prostu mam tablic
definicji znakow kilka i dodatkowo sa troche porozrzucane po flashu.
Korzystajac z jednej procedury chce wczytac jedna wybrana z nich.
Dlatego tak mi bylo wygodniej. Poza tym ten zapis jest dla mnie bardziej
czytelny. Ale moze sie myle. Ja go rozumiem tak:
pgm_read_byte(((int)&polish_chars)+f); odczytaj z pamieci ROM bajt z
adresu (gdzie adres=adres poczatku tablicy polish_chars, powiekszony o
f). Poniewaz pgm_read_byte() operuje na int to rzutuje polish_char na
inta i dodaje f jako char-a. W programie dla jednej tablicy co prawda
wystarczylby char, ale dla kilku juz nie ;-)
polish_chars+f powinno dzialac dobrze.
Dziala, zezarl 20 bajtow wiecej ;-)
ale &polish_chars wskazuje na cala tablice i ma rozmiar jej calej,
Zaraz... bo sie pogubilem. Zalozmy ze mam tablice char tab[20];
I teraz zeby dostac sie do 10 elementu moge uzyc:
a) char x=tab[9]
b) Znalezc adres tablicy i dodac offset czyli char x=(((int)&tab)+10);
c) Wskaznik na poczatek tablicy i zwiekszyc go o 10 i odczytac. char *x;
*x=&polish_chars; *x+=10;
Jesli jest tak jak piszesz o rozmiarze to dlaczego sizeof(&polish_chars)
daje 2 ? To znaczy dla mnie to jasne bo wynikiem jest adres ktory jest
integerem wiec ma rozmiar 2. Myle sie ??
wiec &polish_chars+1 to adres calej kolejnej tablicy, a nie
drugiego elementu ..
Tu sie zgodze.
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Wed, 05 May 2004 16:59:19 +0200
On Wed, 05 May 2004 15:09:37 +0200, Milosz Skowyra wrote:
"J.F." wrote:
b) kolega przekombinowal [a raczej nie przeczytal pewnej ksiazki :-)]
Czytam powoli... i podpieram sie dodatkowo kieszonkowym leksykonem C++.
Czytac szybciej, szczegolnie rozdzial arytmetyka wskaznikow :-)
Ogolnie C dziala tak, ze (wsk+liczba) ma wartosc liczbowa
adres(wsk) + liczba*sizeof(*wskaznik)
Innymi slowy - trzeba pilnie uwazac na typ na ktory wskaznik wskazuje,
bowiem dodajemy rozne wartosci. Ale to jest dla wygody, dzieki temu
t[i] jest dokladnie tym samym co *(t+i)
Ja go rozumiem tak:
pgm_read_byte(((int)&polish_chars)+f); odczytaj z pamieci ROM bajt z
adresu (gdzie adres=adres poczatku tablicy polish_chars, powiekszony o f).
Owszem, z tym ze :
- wystarczy pgm_read_byte(((int)polish_chars)+f) -
polish_chars i &polish_chars to sa te same adresy, roznia
sie natomiast wielkoscia obiektu wskazywanego [co tu nie ma
znaczenia]
- w innym procku relacje miedzy wskaznikiem a integerem moga byc
inne, wiec zaleca sie nie dokonywac takiej konwersji.
- akurat w AVR byc moze ta funkcja faktycznie ma parametr int,
a nie char*.
polish_chars+f powinno dzialac dobrze.
Dziala, zezarl 20 bajtow wiecej ;-)
A to ciekawe. Zglos moze te uwagi supportowi, moze poprawia.
Zaraz... bo sie pogubilem. Zalozmy ze mam tablice char tab[20];
I teraz zeby dostac sie do 10 elementu moge uzyc:
a) char x=tab[9]
b) Znalezc adres tablicy i dodac offset czyli char x=(((int)&tab)+10);
Nie - tak to oliczyles adres [zly!], nie pobrales natomiast
zlokalizowanej tam danej, czemu sluzy *
x=*(((int)&tab)+9)
a dokladniej, to by wypadalo napisac
x=*( (char*) (((int)&tab)+9));
to samo moglbys zapisac jako
x=*( (char*) (((int)tab)+9));
x=*( tab+9 );
Czy nawet 9[x] - co z definicji wynosi *(9+tab)
c) Wskaznik na poczatek tablicy i zwiekszyc go o 10 i odczytac. char *x;
*x=&polish_chars; *x+=10;
Tu glupoty jakies piszes:-)
char *x;
OK, x jest wskaznikiem, czyli adresem, komorki pamieci zawierajacej
znak. x jest oczywiscie zmienna, czyli zajmuje dwa bajty w tym procku.
x chwilowo jest niezainicjowany, czyli wskazuje w losowo wybrane
miejsce pamieci [starsze C wymagaly zeby takie zmienne globalne
byly wstepnie zerowane].
*x=&polish_chars;
To jest glupota totalna, bo w ten jeden znak wskazywany przez x
[czyli chwilowo w jakies losowe miejsce w pamieci :-)] usilujesz
wpisac adres tablicy - czyli pewnie tylko mlodszy bajt adresu.
*x+=10;
A niniejszym usilujesz do znaku wskazywanego przez x dodac 10.
Z sensem wygladaloby to tak:
char *x; //wskaznik
x=&polish_chars; //teraz wskazuje na poczatek tablicy
x+=3 //teraz wskazuje na 4 znak tablicy
*x+=5 // a teraz ten znak powiekszamy o 5
Gdyby w tablicy bylo "ABCDEFGHI", to po wykonaniu zrobiloby sie
"ABCIEFGHI" ... gdyby to nie byl ROM.
Jesli jest tak jak piszesz o rozmiarze to dlaczego sizeof(&polish_chars)
daje 2 ? To znaczy dla mnie to jasne bo wynikiem jest adres ktory jest
integerem wiec ma rozmiar 2. Myle sie ??
Bo polish_chars jest tablica, i rozmiar ma chocby i 64.
Ale &polish_chars jest juz tylko adresem, a ten liczy 2 bajty.
Natomiast kompilator pamieta na co &polish_chars wskazuje,
wiec &polish_chars+1 to bynajmniej nie jest ten sam adres
co polish_chars+1.
Nawiasem mowiac - moglbys to zrobic tak:
char * dp;
dp=polish_chars; // lub jak wolisz dp=&polish_chars ;
for (unsigned char f=1;f<64;f++)
{
lcd_port=pgm_read_byte(dp);
dp++;
// lub wrecz lcd_port=pgm_read_byte(dp++);
data_port |= (unsigned char)_BV(rs); [...]
}
Tracisz 2 bajty RAM na dodatkowa zmienna [zreszta niekoniecznie], ale
byc moze zyskujesz cos na programie - o ile powiekszenie wskaznika
jest w danym procku prostsza operacja niz dodanie dwoch liczb 16 bit..
A swoja droga - o ile kompilator pozwala zdefiniowac taka tablice
w obszarze pgm, to imho powinien poprawnie komplilowac po prostu
polish_chars[f] - albo cos o tym pisze w faq, albo trzeba serwis
powiadomic..
J.
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!hs001.slackware.pl!new
From: Jan Dubiec <jdx_at_nospam_slackware.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: 05 May 2004 17:54:28 +0200
On Wed, 05 May 2004 16:59:19 +0200, J.F. <jfox_nospam_at_nospam_poczta.onet.pl> wrote:
On Wed, 05 May 2004 15:09:37 +0200, Milosz Skowyra wrote:
[.....]
Owszem, z tym ze :
- wystarczy pgm_read_byte(((int)polish_chars)+f) -
polish_chars i &polish_chars to sa te same adresy, roznia
sie natomiast wielkoscia obiektu wskazywanego [co tu nie ma
znaczenia]
Na mój gust to są dwa różne adresy - polish_chars jest adresem obszaru
pamięci w którym umieszczone są obiekty typu char (czyli polish_chars
to jest po prostu typu char *), natomiast &polish_chars jest adresem adresu
w/w obszaru czyli mówiąc inaczej jest typu char **, albo jescze inaczej,
jest wskaźnikiem na wskaźnik. :-)
[.....]
Zaraz... bo sie pogubilem. Zalozmy ze mam tablice char tab[20];
I teraz zeby dostac sie do 10 elementu moge uzyc:
a) char x=tab[9]
b) Znalezc adres tablicy i dodac offset czyli char x=(((int)&tab)+10);
Nie - tak to oliczyles adres [zly!], nie pobrales natomiast
zlokalizowanej tam danej, czemu sluzy *
x=*(((int)&tab)+9)
a dokladniej, to by wypadalo napisac
x=*( (char*) (((int)&tab)+9));
Nie chce mi się odpalać kompilatora ale jestem pewien że żadna z
powyższych konstrukcji nie zadziała tak jak oczekiwano. :-)
to samo moglbys zapisac jako
x=*( (char*) (((int)tab)+9));
x=*( tab+9 );
Drugie wyrażenie będzie działać, pierwsze nie zawsze. Ale one nie są
równoważne tym dwóm wcześniejszym.
Poza tym w zasadzie warto byłoby sprecyzować w tej dyskusji (i w
świetle tego co napisałem na samym początku) co to znaczy "znaleźć
adres tablicy". Bo jeśli chodzi o adres obszar pamięci w którym
znajdują się przechowywane obiekty, to wartość zmiennej tab (pisanej
bez żadnych indeksów) jest właśnie tym adresem i nic nie trzeba
szukać.
[.....]
Z sensem wygladaloby to tak:
char *x; //wskaznik
x=&polish_chars; //teraz wskazuje na poczatek tablicy
^- powinno być tez tego ampersanda
x+=3 //teraz wskazuje na 4 znak tablicy
*x+=5 // a teraz ten znak powiekszamy o 5
Regards,
/J.D.
--
Jan Dubiec, jdx_at_nospam_slackware.pl, mobile: +48 506 790442
Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Wed, 05 May 2004 19:45:58 +0200
On 05 May 2004 17:54:28 +0200, Jan Dubiec wrote:
On Wed, 05 May 2004 16:59:19 +0200, J.F. <jfox_nospam_at_nospam_poczta.onet.pl> wrote:
- wystarczy pgm_read_byte(((int)polish_chars)+f) -
polish_chars i &polish_chars to sa te same adresy, roznia
sie natomiast wielkoscia obiektu wskazywanego [co tu nie ma
znaczenia]
Na mój gust to są dwa różne adresy - polish_chars jest adresem obszaru
pamięci w którym umieszczone są obiekty typu char (czyli polish_chars
to jest po prostu typu char *), natomiast &polish_chars jest adresem adresu
w/w obszaru czyli mówiąc inaczej jest typu char **, albo jescze inaczej,
jest wskaźnikiem na wskaźnik. :-)
Nie - pamietaj ze polish_chars jest tablica !
wiec "jej wartosc liczbowa" jest adresem pierwszego elementu, i
pokrywa sie z adresem calosci.
[.....]
Zaraz... bo sie pogubilem. Zalozmy ze mam tablice char tab[20];
I teraz zeby dostac sie do 10 elementu moge uzyc:
a) char x=tab[9]
b) Znalezc adres tablicy i dodac offset czyli char x=(((int)&tab)+10);
Nie - tak to oliczyles adres [zly!], nie pobrales natomiast
zlokalizowanej tam danej, czemu sluzy *
x=*(((int)&tab)+9)
a dokladniej, to by wypadalo napisac
x=*( (char*) (((int)&tab)+9));
Nie chce mi się odpalać kompilatora ale jestem pewien że żadna z
powyższych konstrukcji nie zadziała tak jak oczekiwano. :-)
Powinny.
to samo moglbys zapisac jako
x=*( (char*) (((int)tab)+9));
x=*( tab+9 );
Drugie wyrażenie będzie działać, pierwsze nie zawsze.
Zgodze sie - potrafia byc niuanse. Ale czesto int sie pokrywa
ze wskaznikiem - i wtedy powinno zadzialac.
Ale one nie są równoważne tym dwóm wcześniejszym.
Poza tym drobnym zastrzezeniem - sa.
Poza tym w zasadzie warto byłoby sprecyzować w tej dyskusji (i w
świetle tego co napisałem na samym początku) co to znaczy "znaleźć
adres tablicy". Bo jeśli chodzi o adres obszar pamięci w którym
znajdują się przechowywane obiekty, to wartość zmiennej tab (pisanej
bez żadnych indeksów) jest właśnie tym adresem i nic nie trzeba
szukać.
Dokladnie. Wiec tab==&tab - choc sa miedzy nimi roznice typu
i nie zachowuja sie tak samo.
Aha - to dotyczy rzeczywistej deklaracji tablicy, bo
deklaracja w naglowku funkcji jest wskaznikiem..
J.
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!mimuw.edu.pl!news.mimuw.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!hs001.slackware.pl!new
From: Jan Dubiec <jdx_at_nospam_slackware.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: 05 May 2004 21:17:26 +0200
On Wed, 05 May 2004 19:45:58 +0200, J.F. <jfox_nospam_at_nospam_poczta.onet.pl> wrote:
On 05 May 2004 17:54:28 +0200, Jan Dubiec wrote:
On Wed, 05 May 2004 16:59:19 +0200, J.F. <jfox_nospam_at_nospam_poczta.onet.pl> wrote:
- wystarczy pgm_read_byte(((int)polish_chars)+f) -
polish_chars i &polish_chars to sa te same adresy, roznia
sie natomiast wielkoscia obiektu wskazywanego [co tu nie ma
znaczenia]
Na mój gust to są dwa różne adresy - polish_chars jest adresem obszaru
pamięci w którym umieszczone są obiekty typu char (czyli polish_chars
to jest po prostu typu char *), natomiast &polish_chars jest adresem adresu
w/w obszaru czyli mówiąc inaczej jest typu char **, albo jescze inaczej,
jest wskaźnikiem na wskaźnik. :-)
Nie - pamietaj ze polish_chars jest tablica !
wiec "jej wartosc liczbowa" jest adresem pierwszego elementu, i
pokrywa sie z adresem calosci.
[.....]
Dokladnie. Wiec tab==&tab - choc sa miedzy nimi roznice typu
i nie zachowuja sie tak samo.
Rzeczywiście, masz rację co widać na załączonym przykładzie:
#include <stdio.h>
int main(int argc, char **argv)
{
char tab1[10], *tab2, **tp1, **tp2;
tp1 = (char**) &tab1;
tp2 = &tab2;
printf("tab1=%p, tp1=%p, *tp1=%p\n", tab1, tp1, *tp1);
printf("tab2=%p, tp2=%p, *tp2=%p\n", tab2, tp2, *tp2);
tab2 = tab1;
printf("tab2=%p, tp2=%p, *tp2=%p\n", tab2, tp2, *tp2);
return 0;
}
Niby do tab1 i tab2 można odwoływać się w ten sam sposób, tj. przy pomocy
indeksów lub arytmetyki wskaźników ale jednak są pewne niuanse w działaniu
operatora &. :-) Używając C trzeba być jednak czujnym przez cały czas. :-)
Aha - to dotyczy rzeczywistej deklaracji tablicy, bo
deklaracja w naglowku funkcji jest wskaznikiem..
Nie bardzo rozumiem. Może jakiś przykład?
Regards,
/J.D.
--
Jan Dubiec, jdx_at_nospam_slackware.pl, mobile: +48 506 790442
Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 06 May 2004 12:41:06 +0200
On 05 May 2004 21:17:26 +0200, Jan Dubiec wrote:
Aha - to dotyczy rzeczywistej deklaracji tablicy, bo
deklaracja w naglowku funkcji jest wskaznikiem..
Nie bardzo rozumiem. Może jakiś przykład?
int test(char tab1[10])
{
char *tab2, **tp1, **tp2;
tp1 = (char**) &tab1;
tp2 = &tab2;
printf("tab1=%p, tp1=%p, *tp1=%p\n", tab1, tp1, *tp1);
printf("tab2=%p, tp2=%p, *tp2=%p\n", tab2, tp2, *tp2);
tab2 = tab1;
printf("tab2=%p, tp2=%p, *tp2=%p\n", tab2, tp2, *tp2);
return 0;
}
No i juz dziala inaczej.
J.
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 06 May 2004 11:53:20 +0200
"J.F." wrote:
b) kolega przekombinowal [a raczej nie przeczytal pewnej ksiazki :-)]
Czytam powoli... i podpieram sie dodatkowo kieszonkowym leksykonem C++.
Czytac szybciej, szczegolnie rozdzial arytmetyka wskaznikow :-)
Robi sie... problem tylko ze co innego czytalem a co innego rozumialem
;-(((
Znaczy sam sie w pole (marchewki) wyprowadzilem.
[...]
Z sensem wygladaloby to tak:
char *x; //wskaznik
x=&polish_chars; //teraz wskazuje na poczatek tablicy
x+=3 //teraz wskazuje na 4 znak tablicy
*x+=5 // a teraz ten znak powiekszamy o 5
Gdyby w tablicy bylo "ABCDEFGHI", to po wykonaniu zrobiloby sie
"ABCIEFGHI" ... gdyby to nie byl ROM.
I juz kumam. Nie wiem dlaczego ale caly czas lazilo mi po glowie ze jak
operujemy na wskazniku to na wskazniku, czyli jak mamy char *x; to
wszystkie operacje tycza sie *x. Teraz wiem ze operacje na zawartosci
wskazywanej zmiennej odbywa sie przez dereferencje.
Jeszcze ostatnia niejasnosc...
char x[20],y[20],a;
char *xptr;
xptr=&x; //######
a=*xptr; //w a laduje element x[0]
xptr=&x+1; //######
a=*xptr; //w a laduje element y[0]
xptr=x;
a=*xptr; //w a laduje element x[0]
xptr=x+1;
a=*xptr; //w a laduje element x[1]
juz mysle dobrze czy nadal gdzies blad w logice ??
I jeszcze jedno. Kompilacja tego powyzej daje w liniach oznaczonych
##### warninga
"main.c:16: warning: assignment from incompatible pointer type". Mam
racje ze chodzi o to ze 2 bajtowy pointer nie miesci sie w char-ze ??
Bo polish_chars jest tablica, i rozmiar ma chocby i 64.
Ale &polish_chars jest juz tylko adresem, a ten liczy 2 bajty.
Natomiast kompilator pamieta na co &polish_chars wskazuje,
wiec &polish_chars+1 to bynajmniej nie jest ten sam adres
co polish_chars+1.
To chyba wlasnie pojalem ;-)
A swoja droga - o ile kompilator pozwala zdefiniowac taka tablice
w obszarze pgm, to imho powinien poprawnie komplilowac po prostu
polish_chars[f] - albo cos o tym pisze w faq, albo trzeba serwis
powiadomic..
Jak dziala polish_chars[f] to juz podalem ;-)
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 6 May 2004 13:05:43 +0200
Thu, 06 May 2004 11:53:20 +0200, na pl.misc.elektronika, Milosz Skowyra
napisał(a):
Jeszcze ostatnia niejasnosc...
char x[20],y[20],a;
char *xptr;
xptr=&x; //######
a=*xptr; //w a laduje element x[0]
xptr=&x+1; //######
a=*xptr; //w a laduje element y[0]
xptr=x;
a=*xptr; //w a laduje element x[0]
xptr=x+1;
a=*xptr; //w a laduje element x[1]
juz mysle dobrze czy nadal gdzies blad w logice ??
BTW - czy masz zestawione jakies srodowisko symulacyjne ?
Do takich roznych niuansow jest jak znalazl. Pod Win swietnie
sie sprawdza AvrStudio 4.08
I jeszcze jedno. Kompilacja tego powyzej daje w liniach oznaczonych
##### warninga
"main.c:16: warning: assignment from incompatible pointer type". Mam
racje ze chodzi o to ze 2 bajtowy pointer nie miesci sie w char-ze ??
Raczej nie - w avr-gcc wskaznik jest zawsze 16-bitowy ( czyli rozmiar int
). Wiec deklaracja char *xptr; tworzy zmienna dwubajtowa xptr. Natomiast
kompilator kontroluje 'target' wskaznika - jesli chcesz tam wpisac jakas
dowolna liczbe to ostrzega, ze mu sie nie zgadza. Wystarczy poinformowac
xptr=(char*)(&x+1); zeby zgasic warninga.
Pozdrowienia
Jurek Szczesiul
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.nask.pl!news-stoc.telia.net!news-stoa.telia.net!telia.net!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 06 May 2004 15:06:17 +0200
Jurek Szczesiul wrote:
BTW - czy masz zestawione jakies srodowisko symulacyjne ?
Do takich roznych niuansow jest jak znalazl. Pod Win swietnie
sie sprawdza AvrStudio 4.08
Mam, robie coff-a i do AvrStudio. Ale czasem to tez nie daje pelnego
obrazka... zwlaszcza jak wiedzy brakuje ;-(
I jeszcze jedno. Kompilacja tego powyzej daje w liniach oznaczonych
##### warninga
"main.c:16: warning: assignment from incompatible pointer type". Mam
racje ze chodzi o to ze 2 bajtowy pointer nie miesci sie w char-ze ??
Raczej nie - w avr-gcc wskaznik jest zawsze 16-bitowy ( czyli rozmiar int
). Wiec deklaracja char *xptr; tworzy zmienna dwubajtowa xptr. Natomiast
kompilator kontroluje 'target' wskaznika - jesli chcesz tam wpisac jakas
dowolna liczbe to ostrzega, ze mu sie nie zgadza. Wystarczy poinformowac
xptr=(char*)(&x+1); zeby zgasic warninga.
Jasne. Dzieki.
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 06 May 2004 14:59:45 +0200
On Thu, 06 May 2004 11:53:20 +0200, Milosz Skowyra wrote:
Jeszcze ostatnia niejasnosc...
char x[20],y[20],a;
char *xptr;
xptr=&x; //######
a=*xptr; //w a laduje element x[0]
xptr=&x+1; //######
a=*xptr; //w a laduje element y[0]
Oj, w a laduje x[20]. A czy to jest y[0] to juz tylko konkretny
kompilator wie. Generalnie nie musi.
xptr=x+1;
a=*xptr; //w a laduje element x[1]
juz mysle dobrze czy nadal gdzies blad w logice ??
Prawidlowo.
I jeszcze jedno. Kompilacja tego powyzej daje w liniach oznaczonych
##### warninga
"main.c:16: warning: assignment from incompatible pointer type". Mam
racje ze chodzi o to ze 2 bajtowy pointer nie miesci sie w char-ze ??
Nie - chodzi o to ze zmieniasz typ wskaznika - tzn typ obiektu
wskazywanego.
A potem bedziesz narzekal ze xptr+1 to nie jest rowne &x+1 ..
A swoja droga - o ile kompilator pozwala zdefiniowac taka tablice
w obszarze pgm, to imho powinien poprawnie komplilowac po prostu
polish_chars[f] - albo cos o tym pisze w faq, albo trzeba serwis
powiadomic..
Jak dziala polish_chars[f] to juz podalem ;-)
Ale w koncu nie zrozumialem - przekombinowales, czy kompilator
zle dziala ?
J.
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.man.poznan.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 06 May 2004 15:51:19 +0200
"J.F." wrote:
char x[20],y[20],a;
char *xptr;
xptr=&x; //######
a=*xptr; //w a laduje element x[0]
xptr=&x+1; //######
a=*xptr; //w a laduje element y[0]
Oj, w a laduje x[20]. A czy to jest y[0] to juz tylko konkretny
kompilator wie. Generalnie nie musi.
Zakladajac ze kompilator ulozy w pamieci tablice x i y po sobie (pewnie
nie ma co takiej ewentualnosci zakladac, bo optymalizacja moze
pomieszac, ale jesli chodzi o elementy struktury to chyba mozna cos
takiego zalozyc, czy nie ??) Ale generalnie chodzilo mi o to czy wskaze
nastepny bajt po koncy tablicy x.
xptr=x+1;
a=*xptr; //w a laduje element x[1]
juz mysle dobrze czy nadal gdzies blad w logice ??
Prawidlowo.
W koncu... jakas pomrocznosc mnie dopadla.
I jeszcze jedno. Kompilacja tego powyzej daje w liniach oznaczonych
##### warninga
"main.c:16: warning: assignment from incompatible pointer type". Mam
racje ze chodzi o to ze 2 bajtowy pointer nie miesci sie w char-ze ??
Nie - chodzi o to ze zmieniasz typ wskaznika - tzn typ obiektu
wskazywanego.
A potem bedziesz narzekal ze xptr+1 to nie jest rowne &x+1 ..
No dobrze, ale ja zrobie jak proponuje Jurek tzn. xptr=(char*) to znow
zgwalce kompilator ??
Jak dziala polish_chars[f] to juz podalem ;-)
Ale w koncu nie zrozumialem - przekombinowales, czy kompilator
zle dziala ?
Tak dziala i dziala poprawnie konstrukcja:
lcd_port=pgm_read_byte(polish_chars+f);
Diobra.
MOV R31,R29 //adres tablicy w R28-R29
MOV R30,R28
LPM
MOV R24,R0
OUT 0x18,R24
[...] // tu mruganie pinami do wyswietlacza.
SUBI R17,0xFF
ADIW R28,0x01
CPI R17,0x40
BRCS +0x5D
Tak w ogole to dziwi mnie ze bezposrednio nie inkrementuje Z, chociaz Z
nie jest uzywany przez nic innego. Ale moze taka polityka ;-)
To nie dziala (znaczy sie czyta smieci).
lcd_port=pgm_read_byte(polish_chars[f]);
MOV R31,R15 ;r14-r15 adres
MOV R30,R14
LD R24,Z+ ;tego nie kumkam
MOV R14,R30
MOV R15,R31
MOV R30,R24 ;i tego tez
CLR R31
LPM
MOV R24,R0
[...] //tu tez mrugranie liniami LCD
SUBI R28,0xFF
CPI R28,0x40
BRCS +0x59
Wyglada jakby z pamieci programu pobieral 1 bajtowy wskaznik do danej we
flashu. Hmmm dlaczego nie wiem.
Chociaz cos mi zaczelo chodzic po glowie.
[chwila kombinacji............] W faqu jest przyklad:
const char foo[] PROGMEM = "Foo";
const char bar[] PROGMEM = "Bar";
PGM_P array[2] PROGMEM = {
foo,
bar
};
int main (void)
{
char buf[32];
strcpy_P (buf, array[1]);
return 0;
}
Na jego podstawie wyklepalem:
const unsigned char polish_chars[] PROGMEM ={
0x0C,0x04,0x06,0x0C,0x04,0x04,0x0E,0x00, //0 - l
0x00,0x00,0x0E,0x11,0x1F,0x10,0x0E,0x02, //1 = e
0x00,0x02,0x16,0x19,0x11,0x11,0x11,0x00, //2 = n
0x00,0x04,0x1F,0x02,0x04,0x08,0x1F,0x00, //3 = z
0x02,0x04,0x0E,0x011,0x11,0x11,0x0E,0x00, //4 = o
0x00,0x04,0x0E,0x10,0x10,0x11,0x0E,0x00}; //5 = c
PGM_P pol_znak[] ={polish_chars};
Odwolujac sie za pomoca: lcd_port=pgm_read_byte(pol_znak[f]);
dostaje nie dzialajacy kod ;-)
MOV R30,R28
CLR R31
LSL R30
ROL R31
SUBI R30,0xA0
SBCI R31,0xFF
LD R0,Z+
LDD R31,Z+0
MOV R30,R0
LDD R24,Z+0
MOV R30,R24
CLR R31
LPM
MOV R24,R0
[...] //mruganie liniami LCD
natomiast dziala
lcd_port=pol_znak[f];
tyle ze kopiuje stringa do RAM.
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 6 May 2004 16:02:00 +0200
Thu, 06 May 2004 15:51:19 +0200, na pl.misc.elektronika, Milosz Skowyra
napisał(a):
Tak dziala i dziala poprawnie konstrukcja:
lcd_port=pgm_read_byte(polish_chars+f);
polish_chars jest de facto adresem tablicy w ROM,
polish_chars + f = adres f-tego elementu - i OK
To nie dziala (znaczy sie czyta smieci).
lcd_port=pgm_read_byte(polish_chars[f]);
A polish_chars[f] juz nie jest adresem tylko wartoscia
f-tego elementu - wiec smieci czyli tez OK :-)
Napisz lcd_port=pgm_read_byte(&polish_chars[f]);
--
Pozdrowienia
Jurek Szczesiul
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 06 May 2004 16:50:31 +0200
Jurek Szczesiul wrote:
To nie dziala (znaczy sie czyta smieci).
lcd_port=pgm_read_byte(polish_chars[f]);
A polish_chars[f] juz nie jest adresem tylko wartoscia
f-tego elementu - wiec smieci czyli tez OK :-)
Napisz lcd_port=pgm_read_byte(&polish_chars[f]);
Jasne... tepota straszna ze mnie ;-(((
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 06 May 2004 19:44:34 +0200
On Thu, 06 May 2004 15:51:19 +0200, Milosz Skowyra wrote:
I jeszcze jedno. Kompilacja tego powyzej daje w liniach oznaczonych
##### warninga
"main.c:16: warning: assignment from incompatible pointer type". Mam
racje ze chodzi o to ze 2 bajtowy pointer nie miesci sie w char-ze ??
Nie - chodzi o to ze zmieniasz typ wskaznika - tzn typ obiektu
wskazywanego.
A potem bedziesz narzekal ze xptr+1 to nie jest rowne &x+1 ..
No dobrze, ale ja zrobie jak proponuje Jurek tzn. xptr=(char*) to znow
zgwalce kompilator ??
To nie jest gwalcenie, tylko jawna zmiana typu.
Zakladamy ze programista wie co robi :-)
Jak dziala polish_chars[f] to juz podalem ;-)
Ale w koncu nie zrozumialem - przekombinowales, czy kompilator
zle dziala ?
Tak dziala i dziala poprawnie konstrukcja:
lcd_port=pgm_read_byte(polish_chars+f);
Ale mi chodzilo o
lcd_port=polish_chars[f] ;
To nie dziala (znaczy sie czyta smieci).
lcd_port=pgm_read_byte(polish_chars[f]);
I prawidlowo, bo co tu kazales?
a) bierzemy f-ty element z tablicy polish_chars - nie adres,
ale juz wartosc, czyli te twoje 0x0C np
b) odczytujemy bajt pamieci programu spod adresu bedacego odczytana
poprzednio wartoscia [czyli 0x000C]
MOV R31,R15 ;r14-r15 adres
MOV R30,R14
LD R24,Z+ ;tego nie kumkam
A mi sie wydaje ze to na przyszlosc - i tak trzeba wskaznik powiekszyc
MOV R14,R30
MOV R15,R31
MOV R30,R24 ;i tego tez
bo tu realizujemy b)
CLR R31
wlasnie rozszerzamu uchar do wskaznika czy int
LPM
Wyglada jakby z pamieci programu pobieral 1 bajtowy wskaznik do danej we
flashu. Hmmm dlaczego nie wiem.
IMHO - bo mu dokladnie wlasnie to kazales.
[...]Na jego podstawie wyklepalem:
const unsigned char polish_chars[] PROGMEM ={
0x0C,0x04,0x06,0x0C,0x04,0x04,0x0E,0x00, //0 - l
PGM_P pol_znak[] ={polish_chars};
Odwolujac sie za pomoca: lcd_port=pgm_read_byte(pol_znak[f]);
Bo na ile sie domyslam to:
a) zadeklarowales tablice wskaznikow pol_znak,
wskazujacych na progmem [kompilator musi to wiedziec zeby wlasciwe
instrukcje stosowac].
b) tablica jest jednoelementowa i zawiera adres [wskazanie w/g
Bieleckiego] polish_chars
c) pol_znak[f] jest f-tym wskaznikiem w tablicy pol_znak - czyli
smieciami, bo poza tablica,
d) odczytany wskaznik traktujemy jako adres bajtu w progmem, ktory
pobieramy
dostaje nie dzialajacy kod ;-)
MOV R30,R28
CLR R31
f do R30,31
LSL R30
ROL R31
elementy pol_znak sa dwubajtowe, wiec trzeba pomnozyc f przez 2
SUBI R30,0xA0
SBCI R31,0xFF
Dziwne, ale to jest widac adres poczatkowy pol_znak
LD R0,Z+
LDD R31,Z+0
MOV R30,R0
pobieramy z pamieci polznak[f] - dwa bajty, bo to wskaznik
LDD R24,Z+0
MOV R30,R24
CLR R31
LPM
A to jest lekko dziwaczne - jakby kolejne posrednie adresowanie,
ty nie sklamales z tym lcd_port=pgm_read_byte(pol_znak[f]) ?
natomiast dziala
lcd_port=pol_znak[f];
tyle ze kopiuje stringa do RAM.
Zaraz - jakim cudem to moze dzialac ?
Milosz - my naprawde dobrze radzimy - albo przeczytasz ze zrozumieniem
ksiazke, albo .. na marchewce tez sie mozna dorobic.
J.
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Fri, 07 May 2004 16:40:04 +0200
"J.F." wrote:
A potem bedziesz narzekal ze xptr+1 to nie jest rowne &x+1 ..
No dobrze, ale ja zrobie jak proponuje Jurek tzn. xptr=(char*) to znow
zgwalce kompilator ??
To nie jest gwalcenie, tylko jawna zmiana typu.
Jasne... sadzac z ksiazeczki nazywa sie to typecast ;-)))
Zakladamy ze programista wie co robi :-)
W asm-ie wiem dokladnie do robie... w C ma to robic za mnie
kompilator... ale za malo piffa z nim wypilem ;-))) Ale sens powyzszego
jest jasny.
Ale mi chodzilo o
lcd_port=polish_chars[f] ;
Dziala, tylko ze na starcie programu kopiuje cala tablice do RAM, a tego
wlasnie chce uniknac.
To nie dziala (znaczy sie czyta smieci).
lcd_port=pgm_read_byte(polish_chars[f]);
I prawidlowo, bo co tu kazales?
Wyglada jakby z pamieci programu pobieral 1 bajtowy wskaznik do danej we
flashu. Hmmm dlaczego nie wiem.
IMHO - bo mu dokladnie wlasnie to kazales.
Jasne. Probu i wysylke przeprowadzilem w czasie kiedy rozsadek poszedl
na spacer. Dlatego takie wyniki. Teraz sam widze co powyprawialem ;-(((
A to jest lekko dziwaczne - jakby kolejne posrednie adresowanie,
ty nie sklamales z tym lcd_port=pgm_read_byte(pol_znak[f]) ?
Nie ma szans, pisalem ze rozsadek mial wolne. Wszystko bylo Copy&Paste.
natomiast dziala
lcd_port=pol_znak[f];
tyle ze kopiuje stringa do RAM.
Zaraz - jakim cudem to moze dzialac ?
Nie wiem, ale raczej zbieg okolicznosci ;-) Pierwszy znak jest zle
definiowyany, potem ok.
Milosz - my naprawde dobrze radzimy - albo przeczytasz ze zrozumieniem
ksiazke, albo .. na marchewce tez sie mozna dorobic.
No i wlasnie wrocilem z przebiegu po moim "ukochanym" miescie Opolu.
Bylem w 6 ksiegarniach i tak naprawde to nie ma co kupic. W jenej
znalazlem pozycje "C" Bjorna Stroustrupa, ale w skorze z odcisnietymi
literkami za jedyne 144 pln. Reszta to malo ciekawe dla mnie pozycje,
dotyczace najczesciej obiektowych wersji C, samouczki C, a nawet "C w 24
godziny". Co do ANSI C to nie znalazlem ani jednej pozycji. Z
ciekawostek byly 2 ksiazki typu 99 najczestszych bledow w C++, nawet
ciekawe. Ale jakies 80% porad dotyczylo wersji okienkowych. W koncu juz
w trzeciej bibliotece znalazlem "C" K&R, a dodatkowo pozyczylem z
sentymentu "Sam na sam z jezykiem C" Bieleckiego, opisujacy HiSoft C
na.... ZX ;-) Zaczyna sie od slow LOAD "" ;-)
Na razie mam "C" K&R, Kieszkonkowy leksykon C i Borland C++. Mysle ze
wystarczy, a jak nie to kupie cos naprawde sensownego ale w interq ;-)))
Dalsze pytania nie wykluczone... Jak bede we Wrocku to stawiam piffo.
Dzieki.
PS. Ksiazki ogrodnicze o uprawie marchewki byly wszedzie... za wyjatkiem
ksiegarni technicznej ;-)
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Fri, 07 May 2004 18:55:51 +0200
On Fri, 07 May 2004 16:40:04 +0200, Milosz Skowyra wrote:
"J.F." wrote:
Ale mi chodzilo o
lcd_port=polish_chars[f] ;
Dziala, tylko ze na starcie programu kopiuje cala tablice do RAM, a tego
wlasnie chce uniknac.
Hm, moze przeceniam avrgcc, ale skoro zadeklarowales tablice w
progmem, to nie powinien tego robic.
w trzeciej bibliotece znalazlem "C" K&R, a dodatkowo pozyczylem z
sentymentu "Sam na sam z jezykiem C" Bieleckiego, opisujacy HiSoft C
na.... ZX ;-) Zaczyna sie od slow LOAD "" ;-)
Bielecki w C byl dobry. Co prawda specyficzny to autor i ksiazki mial
trudne, ale jak go zrozumiesz to i C zrozumiesz :-)
Z tym ze wersja ZX moze byc bardzo uproszczona.
J.
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sat, 08 May 2004 14:04:01 +0200
"J.F." wrote:
Ale mi chodzilo o
lcd_port=polish_chars[f] ;
Dziala, tylko ze na starcie programu kopiuje cala tablice do RAM, a tego
wlasnie chce uniknac.
Hm, moze przeceniam avrgcc, ale skoro zadeklarowales tablice w
progmem, to nie powinien tego robic.
A kicha... nie dziala. Usiluje czytac z RAM-u ale wczesniej do niego nie
kopiuje stringa.
MOV R14,R21 //w r14-15 adres, poprawny bo napis w flash
leci od 0x0021
LDI R21,0x00
MOV R15,R21
ale samo czytanie odbywa sie z ramu.
MOV R31,R15
MOV R30,R14
LD R24,Z+
MOV R14,R30
MOV R15,R31
OUT 0x18,R24
Bielecki w C byl dobry. Co prawda specyficzny to autor i ksiazki mial
trudne, ale jak go zrozumiesz to i C zrozumiesz :-)
Z tym ze wersja ZX moze byc bardzo uproszczona.
Zgadza sie, pamietam ksiazki Bieleckiego z okresu ZX-a (bylem gdzies w
4-5 klasie podstawowki) i pozniejsze z pecetologii. Ciezki do czytania i
rozumienia, ale za to trzeba mu przyznac ze wiedze posiadal spora.
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.man.poznan.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sat, 8 May 2004 17:25:03 +0200
Sat, 08 May 2004 14:04:01 +0200, na pl.misc.elektronika, Milosz Skowyra
napisał(a):
A kicha... nie dziala. Usiluje czytac z RAM-u ale wczesniej do niego nie
kopiuje stringa.
MOV R14,R21 //w r14-15 adres, poprawny bo napis w flash
leci od 0x0021
LDI R21,0x00
MOV R15,R21
ale samo czytanie odbywa sie z ramu.
MOV R31,R15
MOV R30,R14
LD R24,Z+
MOV R14,R30
MOV R15,R31
OUT 0x18,R24
To juz nie wiem jak robisz. Taki tu prosty przyklad różnych składni:
const char Tx1[] PROGMEM = "One";
....................
i=1;
x=pgm_read_byte(Tx1);
x=pgm_read_byte(&Tx1[i]);
i=2;
x=pgm_read_byte(Tx1 + i);
generuje :
i=1;
180: 81 e0 ldi r24, 0x01 ; 1
182: 90 e0 ldi r25, 0x00 ; 0
184: 90 93 70 00 sts 0x0070, r25
188: 80 93 6f 00 sts 0x006F, r24
x=pgm_read_byte(Tx1);
18c: e6 e9 ldi r30, 0x96 ; 150
18e: f0 e0 ldi r31, 0x00 ; 0
190: 84 91 lpm r24, Z
192: 80 93 6c 00 sts 0x006C, r24
x=pgm_read_byte(&Tx1[i]);
196: 31 96 adiw r30, 0x01 ; 1
198: 84 91 lpm r24, Z
19a: 80 93 6c 00 sts 0x006C, r24
i=2;
19e: 82 e0 ldi r24, 0x02 ; 2
1a0: 90 e0 ldi r25, 0x00 ; 0
1a2: 90 93 70 00 sts 0x0070, r25
1a6: 80 93 6f 00 sts 0x006F, r24
x=pgm_read_byte(Tx1 + i);
1aa: 31 96 adiw r30, 0x01 ; 1
1ac: 84 91 lpm r24, Z
1ae: 80 93 6c 00 sts 0x006C, r24
--
Pozdrowienia
Jurek Szczesiul
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!opal.futuro.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sat, 08 May 2004 18:04:32 +0200
Jurek Szczesiul wrote:
To juz nie wiem jak robisz. Taki tu prosty przyklad różnych składni:
const char Tx1[] PROGMEM = "One";
i=1;
x=pgm_read_byte(Tx1);
x=pgm_read_byte(&Tx1[i]);
i=2;
x=pgm_read_byte(Tx1 + i);
Przeciez Jarek ewidentnie pytal czy dziala sekwencja.
Ale mi chodzilo o
lcd_port=polish_chars[f] ;
Specjalnie zostawilem cytat ktory wyciales. Przeczytaj ze dwa posty
wyzej.
Mozesz zreszta pokazac co da w Twoim przypadki x=Tx1[i];
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sat, 8 May 2004 18:22:39 +0200
Sat, 08 May 2004 18:04:32 +0200, na pl.misc.elektronika, Milosz Skowyra
napisał(a):
Przeciez Jarek ewidentnie pytal czy dziala sekwencja.
Specjalnie zostawilem cytat ktory wyciales. Przeczytaj ze dwa posty
wyzej.
OK, OK ;-)
Watek sie cokolwiek pokomplikowal.
Mozesz zreszta pokazac co da w Twoim przypadki x=Tx1[i];
Zoptymalizowalo :
x=Tx1[i];
178: 80 91 97 00 lds r24, 0x0097
17c: 80 93 6c 00 sts 0x006C, r24
--
Pozdrowienia
Jurek Szczesiul
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.internetia.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sat, 08 May 2004 20:28:16 +0200
Jurek Szczesiul wrote:
Mozesz zreszta pokazac co da w Twoim przypadki x=Tx1[i];
Zoptymalizowalo :
x=Tx1[i];
178: 80 91 97 00 lds r24, 0x0097
17c: 80 93 6c 00 sts 0x006C, r24
Niby tak, tylko ze zoptymalizowalo pod katem odczytu z ramu, a to co
potrzebujemy lezy w romie. O tym rozmawialismy z J.F. IMHO GCC traktuje
wszystko, jak dane umieszczone w pamieci ram, nie patrzac na definicje
obszaru w ktorym zmienna zostala zadeklarowana. Tylko specyficzne
komendy odwoluja sie za pomoca LPM, SPM czy ELPM.
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sat, 8 May 2004 22:00:04 +0200
Sat, 08 May 2004 20:28:16 +0200, na pl.misc.elektronika, Milosz Skowyra
napisał(a):
Mozesz zreszta pokazac co da w Twoim przypadki x=Tx1[i];
Zoptymalizowalo :
x=Tx1[i];
178: 80 91 97 00 lds r24, 0x0097
17c: 80 93 6c 00 sts 0x006C, r24
Niby tak, tylko ze zoptymalizowalo pod katem odczytu z ramu, a to co
potrzebujemy lezy w romie. O tym rozmawialismy z J.F. IMHO GCC traktuje
wszystko, jak dane umieszczone w pamieci ram, nie patrzac na definicje
obszaru w ktorym zmienna zostala zadeklarowana. Tylko specyficzne
komendy odwoluja sie za pomoca LPM, SPM czy ELPM.
O, teraz wlasnie jest poruszone sedno sprawy. Wlasnie tak jest, bo gcc
pochodzi ze swiata ciaglej pamieci, gdzie nie ma pod takimi samymi adresami
ramu, flasha i eepromu. Wskaznik jest 2-bajtowy i nie ma w nim miejsca na
okreslenie, o ktora pamiec chodzi ( np. w prostym kompilatorku dla 51
mialem wskazniki 3-bajtowe - i tam wszystkie odwolania przebiegaly
tradycyjnie - 3. bajt jednoznacznie okreslal typ pamieci ). Wiec zrobiono
za pomoca makr i funkcji. Chociaz ostatnio coraz czesciej na liscie avr-gcc
pojawiaja sie rozwazania, ze chyba wypadaloby cos z tym w koncu zrobic :-)
--
Pozdrowienia
Jurek Szczesiul
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 09 May 2004 01:31:17 +0200
On Sat, 8 May 2004 22:00:04 +0200, Jurek Szczesiul wrote:
Niby tak, tylko ze zoptymalizowalo pod katem odczytu z ramu, a to co
potrzebujemy lezy w romie. O tym rozmawialismy z J.F. IMHO GCC traktuje
wszystko, jak dane umieszczone w pamieci ram, nie patrzac na definicje
obszaru w ktorym zmienna zostala zadeklarowana. Tylko specyficzne
komendy odwoluja sie za pomoca LPM, SPM czy ELPM.
O, teraz wlasnie jest poruszone sedno sprawy. Wlasnie tak jest, bo gcc
pochodzi ze swiata ciaglej pamieci, gdzie nie ma pod takimi samymi adresami
ramu, flasha i eepromu. Wskaznik jest 2-bajtowy i nie ma w nim miejsca na
okreslenie, o ktora pamiec chodzi
Ale w tym przypadku mamy konkretna tablice, w ktorejs jakos sie
znalazlo miejsce na atrybut "progmem". Printf czy inna funkcja
mialby problemy z okresleniem o ktora pamiec chodzi po wskazniku - ale
tablica[i] kompilator moglby prawidlowo skompilowac, bo wie gdzie
sie ta tablica miesci.
np. w prostym kompilatorku dla 51
mialem wskazniki 3-bajtowe - i tam wszystkie odwolania przebiegaly
tradycyjnie - 3. bajt jednoznacznie okreslal typ pamieci ). Wiec zrobiono
za pomoca makr i funkcji. Chociaz ostatnio coraz czesciej na liscie avr-gcc
pojawiaja sie rozwazania, ze chyba wypadaloby cos z tym w koncu zrobic :-)
tak ... zmienic procka :-) Bo ten zawsze bedzie sprawial takie
klopoty.
J.
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.atman.pl!not-for-mai
From: Krzysztof Rudnik <rudnik_at_nospam_kki.net.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 09 May 2004 11:09:53 +0200
J.F. wrote:
On Sat, 8 May 2004 22:00:04 +0200, Jurek Szczesiul wrote:
Niby tak, tylko ze zoptymalizowalo pod katem odczytu z ramu, a to co
potrzebujemy lezy w romie. O tym rozmawialismy z J.F. IMHO GCC traktuje
wszystko, jak dane umieszczone w pamieci ram, nie patrzac na definicje
obszaru w ktorym zmienna zostala zadeklarowana. Tylko specyficzne
komendy odwoluja sie za pomoca LPM, SPM czy ELPM.
O, teraz wlasnie jest poruszone sedno sprawy. Wlasnie tak jest, bo gcc
pochodzi ze swiata ciaglej pamieci, gdzie nie ma pod takimi samymi
adresami ramu, flasha i eepromu. Wskaznik jest 2-bajtowy i nie ma w nim
miejsca na okreslenie, o ktora pamiec chodzi
Ale w tym przypadku mamy konkretna tablice, w ktorejs jakos sie
znalazlo miejsce na atrybut "progmem". Printf czy inna funkcja
mialby problemy z okresleniem o ktora pamiec chodzi po wskazniku - ale
tablica[i] kompilator moglby prawidlowo skompilowac, bo wie gdzie
sie ta tablica miesci.
Mozna by to obejsc gdyby narzucic dodatkowy warunek na zgodnosc typow -
atrybut wskaznika jest integralna czescia typu i wskazniki na rozne
typu pamieci sa niekompatybilne. Wtedy w naglowku funkcji moznaby
okreslic jakiego wskaznika oczekuje.
np. w prostym kompilatorku dla 51
mialem wskazniki 3-bajtowe - i tam wszystkie odwolania przebiegaly
tradycyjnie - 3. bajt jednoznacznie okreslal typ pamieci ). Wiec zrobiono
za pomoca makr i funkcji. Chociaz ostatnio coraz czesciej na liscie
avr-gcc pojawiaja sie rozwazania, ze chyba wypadaloby cos z tym w koncu
zrobic :-)
tak ... zmienic procka :-) Bo ten zawsze bedzie sprawial takie
klopoty.
To jest zdaje tzw architektura Harward (nie chce mi sie teraz
wyciagac mojej starej pracy dyplomowej o TMS320),
Krzysiek Rudnik
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.dialog.net.pl!not-for-mai
From: "Piotr Wyderski" <piotr.wyderski_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 9 May 2004 13:16:23 +0200
Krzysztof Rudnik wrote:
Mozna by to obejsc gdyby narzucic dodatkowy warunek na zgodnosc typow -
atrybut wskaznika jest integralna czescia typu i wskazniki na rozne
typu pamieci sa niekompatybilne.
Jak to sobie konkretnie wyobrazasz? Tj. czym rozni sie
const char* p; wskazujace na dane w RAM od
const char* p; wskazujace na dane w ROM?
Mozna oczywiscie dodac do jezyka nowe specyfikatory rodzaju
wskazywanej pamieci i zabronic konwersji miedzy nimi, ale to juz
nie bedzie C. :-)
To jest zdaje tzw architektura Harward
Zgadza sie, pamieci danych i programu sa fizycznie rozdzielone.
Pozdrawiam
Piotr Wyderski
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.internetia.pl!mimuw.edu.pl!news.mimuw.edu.pl!uw.edu.pl!news.pw.edu.pl!not-for-mai
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 09 May 2004 13:37:43 +0200
Pewnego dnia Piotr Wyderski przemówił ludzkim głosem:
const char* p; wskazujace na dane w RAM od
^^^^^^^ to bym wywalił
const char* p; wskazujace na dane w ROM?
^^^^^^^^ a tu aż się prosi o umieszczenie w romie
Mozna oczywiscie dodac do jezyka nowe specyfikatory rodzaju
wskazywanej pamieci i zabronic konwersji miedzy nimi, ale to juz
nie bedzie C. :-)
Ale czy ktoś się upiera, że to musi być klasyczne C ? To ma być wygodne
narzędzie. Jeśli norma nie uwzględnia małego otworu na końcu młotka do
powieszenia go na gwoździu, to nie znaczy, że ktoś nie może tego zrobić,
a już nie daj boże sprzedawać pod nazwą "ansi/iso młotek" (pod
warunkiem, że to rozszerzenie da się wyłączyć).
--
*Warning*: Dates in Calendar are closer than they appear.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.dialog.net.pl!not-for-mai
From: "Piotr Wyderski" <piotr.wyderski_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 9 May 2004 14:01:46 +0200
Zbych wrote:
Ale czy ktoś się upiera, że to musi być klasyczne C ?
Nikt sie nie upiera, nawet wprost przeciwnie; ja tylko
informuje, ze po takich modyfikacjach to juz nie bedzie C. :-)
Pozdrawiam
Piotr Wyderski
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.dialog.net.pl!not-for-mai
From: "Piotr Wyderski" <piotr.wyderski_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 9 May 2004 14:05:45 +0200
Zbych wrote:
Zapomnialem o tym:
const char* p; wskazujace na dane w RAM od
^^^^^^^ to bym wywalił
A to dlaczego? Co zabrania miec w pamieci RAM
dane, ktore w danym kontekscie nie sa zapisywalne
(co nie oznacza, ze nie sa zapisywalne w ogole)?
const char* p; wskazujace na dane w ROM?
^^^^^^^^ a tu aż się prosi o umieszczenie w romie
Ale skad kompilator ma o tym wiedziec? OK, jesli const
odnosi sie do globalnej definicji danej, to kompilator moze
to wywnioskowac, ale co z automatycznymi obiektami
z atrybutem const? :-)
Pozdrawiam
Piotr Wyderski
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.pw.edu.pl!not-for-mai
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 09 May 2004 14:40:01 +0200
Pewnego dnia Piotr Wyderski przemówił ludzkim głosem:
A to dlaczego? Co zabrania miec w pamieci RAM
dane, ktore w danym kontekscie nie sa zapisywalne
(co nie oznacza, ze nie sa zapisywalne w ogole)?
Dla mnie jeśli coś jest stałe to jest stałe i już.
(co nie znaczy, że twórcy c myśleli podobnie).
ale co z automatycznymi obiektami
z atrybutem const? :-)
A co to są automatyczne obiekty (w kontekście klasycznego c) ?
--
*Warning*: Dates in Calendar are closer than they appear.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 9 May 2004 14:59:24 +0200
Sun, 09 May 2004 14:40:01 +0200, na pl.misc.elektronika, Zbych napisał(a):
Dla mnie jeśli coś jest stałe to jest stałe i już.
(co nie znaczy, że twórcy c myśleli podobnie).
IMHO oni chyba w ogole nie przewidywali takich
problemow - w pecetowym programie i tak de facto
wszystko jest w ramie - nie masz stalych, ktore
trzeba przy odwolaniu sciagac pojedynczo z dysku ;-)
--
Pozdrowienia
Jurek Szczesiul
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.nask.pl!uw.edu.pl!news.pw.edu.pl!not-for-mai
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 09 May 2004 15:09:38 +0200
Pewnego dnia Jurek Szczesiul przemówił ludzkim głosem:
IMHO oni chyba w ogole nie przewidywali takich
problemow - w pecetowym programie i tak de facto
wszystko jest w ramie - nie masz stalych, ktore
trzeba przy odwolaniu sciagac pojedynczo z dysku ;-)
Chwila, przecież c to lata 60 (70 ?) i maszyny unixowe (PDP ?), które
już miały ochronę pamięci. Więc jeśli coś jest umieszczone w segmencie
kod (a nie danych) to nie powinno się tego dać zmodyfikować z poziomu
programu.
--
*Warning*: Dates in Calendar are closer than they appear.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 9 May 2004 16:27:36 +0200
Sun, 09 May 2004 15:09:38 +0200, na pl.misc.elektronika, Zbych napisał(a):
Pewnego dnia Jurek Szczesiul przemówił ludzkim głosem:
Hau ;-)
Chwila, przecież c to lata 60 (70 ?) i maszyny unixowe (PDP ?), które
już miały ochronę pamięci. Więc jeśli coś jest umieszczone w segmencie
kod (a nie danych) to nie powinno się tego dać zmodyfikować z poziomu
programu.
Fakt - i const wlasnie to okresla. Ale segment tak czy siak w ramie. A tu
oddzielny obszar z powielonymi adresami i zupelnie inna maszynowa
obsluga dostepu (a stale moga byc przeciez rowniez w eeprom ).
Wiec sam const przestaje wystarczac - pozostala z niego tylko funkcja
wykrywania bledu przy omylkowej probie zapisu.
--
Pozdrowienia
Jurek Szczesiul
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.dialog.net.pl!not-for-mai
From: "Piotr Wyderski" <piotr.wyderski_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 9 May 2004 16:04:44 +0200
Zbych wrote:
Dla mnie jeśli coś jest stałe to jest stałe i już.
(co nie znaczy, że twórcy c myśleli podobnie).
Ale w C slowo kluczowe "const" nie znaczy "stale", tylko "nie
moze wystapic jako l-wartosc w danym kontekscie" :-)
Coz, to nie nasza wina, ze w C slowa kluczowe niezbyt
odpowiadaja swoim znaczeniom... Porzadniejsze jezyki
maja do tego slowa kluczowe "in" oraz "out", ktore
oznaczaja odpowiednio "tylko do odczytu" i "tylko do
zapisu", a "const" deklaruje prawdziwe stale, zazwyczaj
nie zajmujace ani bajta pamieci (cos jak #define, ale
z pelna kontrola typow). Sprawa "const" w C i C++ jest
bardzo sliska, szczegolnie po dodaniu atrybutu "mutable",
co daje obiekty "czesciowo stale". :->
A co to są automatyczne obiekty (w kontekście klasycznego c) ?
Obiekty umieszczane przez kompilator na stosie.
Pozdrawiam
Piotr Wyderski
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!opal.futuro.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 9 May 2004 14:52:12 +0200
Sun, 9 May 2004 13:16:23 +0200, na pl.misc.elektronika, Piotr Wyderski
napisał(a):
Mozna oczywiscie dodac do jezyka nowe specyfikatory rodzaju
wskazywanej pamieci i zabronic konwersji miedzy nimi, ale to juz
nie bedzie C. :-)
I tak to jest wlasnie zrobione dla '51 - dodatkowo dla zmiennych (stalych)
okresla sie zadany obszar ( np. code, data, idata, xdata ) - potem
kompilator juz 'sam wie' jak poszczegolne zmienne obslugiwac.
--
Pozdrowienia
Jurek Szczesiul
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.dialog.net.pl!not-for-mai
From: "Piotr Wyderski" <piotr.wyderski_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 9 May 2004 16:12:01 +0200
Jurek Szczesiul wrote:
I tak to jest wlasnie zrobione dla '51 - dodatkowo dla zmiennych (stalych)
okresla sie zadany obszar ( np. code, data, idata, xdata )
A w jaki sposob to konkretnie wyglada? Wprowadzili nowe slowa
kluczowe do jezyka, czy tez korzystaja z _attribute_((...))?
Pozdrawiam
Piotr Wyderski
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 9 May 2004 16:43:55 +0200
Sun, 9 May 2004 16:12:01 +0200, na pl.misc.elektronika, Piotr Wyderski
napisał(a):
I tak to jest wlasnie zrobione dla '51 - dodatkowo dla zmiennych (stalych)
okresla sie zadany obszar ( np. code, data, idata, xdata )
A w jaki sposob to konkretnie wyglada? Wprowadzili nowe slowa
kluczowe do jezyka, czy tez korzystaja z _attribute_((...))?
W tych, ktore ogladalem byly to slowa kluczowe
( zreszta jest to nazwane jednoznacznie, np. w opisach SDCC jako
'mcs51 storage class language extensions' ).
--
Pozdrowienia
Jurek Szczesiul
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 09 May 2004 22:53:49 +0200
On Sun, 9 May 2004 16:12:01 +0200, Piotr Wyderski wrote:
Jurek Szczesiul wrote:
I tak to jest wlasnie zrobione dla '51 - dodatkowo dla zmiennych (stalych)
okresla sie zadany obszar ( np. code, data, idata, xdata )
A w jaki sposob to konkretnie wyglada? Wprowadzili nowe slowa
kluczowe do jezyka, czy tez korzystaja z _attribute_((...))?
w '51 to nei wiem, ale w AVR attribute
http://users.rcn.com/rneswold/avr/c957.html
J.
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.atman.pl!not-for-mai
From: Krzysztof Rudnik <rudnik_at_nospam_kki.net.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 09 May 2004 16:50:33 +0200
Piotr Wyderski wrote:
Krzysztof Rudnik wrote:
Mozna by to obejsc gdyby narzucic dodatkowy warunek na zgodnosc typow -
atrybut wskaznika jest integralna czescia typu i wskazniki na rozne
typu pamieci sa niekompatybilne.
Jak to sobie konkretnie wyobrazasz? Tj. czym rozni sie
const char* p; wskazujace na dane w RAM od
const char* p; wskazujace na dane w ROM?
Dodanie _attribute_ juz wykracza poza C.
Krzysiek Rudnik
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 09 May 2004 22:53:49 +0200
On Sun, 9 May 2004 13:16:23 +0200, Piotr Wyderski wrote:
Krzysztof Rudnik wrote:
Mozna by to obejsc gdyby narzucic dodatkowy warunek na zgodnosc typow -
atrybut wskaznika jest integralna czescia typu i wskazniki na rozne
typu pamieci sa niekompatybilne.
Jak to sobie konkretnie wyobrazasz? Tj. czym rozni sie
const char* p; wskazujace na dane w RAM od
const char* p; wskazujace na dane w ROM?
mozna zrobic tak jak zrobiono:
prog_char: char _attribute_((progmem))
PGM_P : prog_char const*
Kompilator sie zorientuje ... ale jak zmusic printf i inne funkcje
zeby sie po adresie orientowaly ? :-)
Niby mozna tak jak kolega tu proponowal - wskazniki 3 bajtowe,
pierwszy wskazuje obszar ... tylko ze wtedy zegnaj wydajnosc :-(
To jest zdaje tzw architektura Harward
Zgadza sie, pamieci danych i programu sa fizycznie rozdzielone.
Co nie zabrania istnienia jednolitej adresacji. Np
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
Tylko jak to zrobic jesli niektorzy chca 64KB ram, 256KB ROM
i oszczedne 16-bitowe wskazniki.
Ech, to gdzie dostac ARMa w przyzwoitej cenie, detalicznej ilosci i
obudowie nie BGA ?
J.
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.dialog.net.pl!not-for-mai
From: "Piotr Wyderski" <piotr.wyderski_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 9 May 2004 23:03:13 +0200
J.F. wrote:
mozna zrobic tak jak zrobiono:
prog_char: char _attribute_((progmem))
PGM_P : prog_char const*
Kompilator sie zorientuje ...
...i po pierwszym przypisaniu do zwyklego wskaznika zgubi te
informacje i znow niczego biedaczek nie bedzie wiedzial. :-)
ale jak zmusic printf i inne funkcje
zeby sie po adresie orientowaly ? :-)
Bez "dynamicznego typowania", czyli kodowania typu
obszaru pamieci we wskazniku wyglada to na problem
nierozstrzygalny podczas statycznej analizy przeplwu
danych. :-)
Niby mozna tak jak kolega tu proponowal - wskazniki 3 bajtowe,
pierwszy wskazuje obszar ... tylko ze wtedy zegnaj wydajnosc :-(
No to jest wlasnie rodzaj takiego dynamicznego typowania.
Tylko jak to zrobic jesli niektorzy chca 64KB ram, 256KB ROM
i oszczedne 16-bitowe wskazniki.
Za pomoca bankowania. :-)
Pozdrawiam
Piotr Wyderski
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!opal.futuro.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Mon, 10 May 2004 01:31:02 +0200
Piotr Wyderski wrote:
Tylko jak to zrobic jesli niektorzy chca 64KB ram, 256KB ROM
i oszczedne 16-bitowe wskazniki.
Za pomoca bankowania. :-)
Tia... tylko w AVR bankowanie zaczyna sie od 64 KB. I dodatkowo nie
dziala tak jak powinno... ;-(
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.man.poznan.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!hs001.slackware.pl!new
From: Jan Dubiec <jdx_at_nospam_slackware.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: 10 May 2004 00:34:22 +0200
On Sun, 09 May 2004 22:53:49 +0200, J.F. <jfox_nospam_at_nospam_poczta.onet.pl> wrote:
On Sun, 9 May 2004 13:16:23 +0200, Piotr Wyderski wrote:
Krzysztof Rudnik wrote:
Mozna by to obejsc gdyby narzucic dodatkowy warunek na zgodnosc typow -
atrybut wskaznika jest integralna czescia typu i wskazniki na rozne
typu pamieci sa niekompatybilne.
Jak to sobie konkretnie wyobrazasz? Tj. czym rozni sie
const char* p; wskazujace na dane w RAM od
const char* p; wskazujace na dane w ROM?
mozna zrobic tak jak zrobiono:
prog_char: char _attribute_((progmem))
PGM_P : prog_char const*
Kompilator sie zorientuje ... ale jak zmusic printf i inne funkcje
zeby sie po adresie orientowaly ? :-)
Zmuszać to chyba nie trzeba ponieważ w avr-libc są przecież funkcje z
postfiksem _P. Problem jest w tym że w przypadku dużych AVR-ów wskaźki
wskazujące na dane znajdujące się w pamięci programu powinny być 17 (a
w przyszłości chyba i 18) bitowe a nie 16 bitowe.
[.....]
To jest zdaje tzw architektura Harward
Zgadza sie, pamieci danych i programu sa fizycznie rozdzielone.
Co nie zabrania istnienia jednolitej adresacji. Np
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
W naszym przypadku to zadziałałoby dla adresów >= 0x10000, ale jak
rozpoznać czy adres np. 0x1000 dotyczy RAM czy ROM. :-) Właśnie po to
są te wszyskie _P funkcje.
Poza tym w architekturze harwardzkiej przestrzeń adresowa z definicji
jest podzielona na dwa obszary i stosowane są różne instrukcje do
zapisu/odczytu danych z tych obszarów. Jest podzielona przynajmniej
logicznie - fizycznie może być różnie - szyna adresowa/danych może być
wspólna a tylko szyny sterujące rozdzielone (np. MCS-51) albo, ze
względu na wydajność (a AFAIK właśnie o to chodziło twórcom tej
architektury), wszystkie szyny zdublowane dla każdego z obszarów jak
chyba jest w zdecydowanej większości DSP (np. w starym ale jarym
ADSP-218x Analoga). I tak jest również w AVR, tylko że tam wszystko
dotyczące pamięci programu jest ukryte wewnątrz kości - tak przynajmniej
wynika z lektury dejtaszitów (nigdy nie używałem tych kości w praktyce).
BTW. Wcale nie należy się tak bardzo przyzwyczajać do schematu że
pamięć programu to jest jakiś ROM. Np. we wspomnianych Analogach, ze
względu na wydajność, pamięcią programu jest RAM - podczas startu kod
jest ładowany do RAM z jakiegoś ROM lub przez IDMA z "procesora
nadrzędnego".
[.....]
Ech, to gdzie dostac ARMa w przyzwoitej cenie, detalicznej ilosci i
obudowie nie BGA ?
W Memec-u? Ewentualnie, prawie po sąsiedzku (w MSC), możesz kupić H8. :-)
Regards,
/J.D.
--
Jan Dubiec, jdx_at_nospam_slackware.pl, mobile: +48 506 790442
Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.pw.edu.pl!not-for-mai
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Mon, 10 May 2004 01:04:45 +0200
Pewnego dnia Jan Dubiec przemówił ludzkim głosem:
Co nie zabrania istnienia jednolitej adresacji. Np
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
W naszym przypadku to zadziałałoby dla adresów >= 0x10000, ale jak
rozpoznać czy adres np. 0x1000 dotyczy RAM czy ROM. :-)
Skoro i tak wskaźnik zrobi się dłuższy niż 2 bajty to można by
wykorzystać najstarszy bit z 3 bajtu do rozróżniania obszarów.
--
*Warning*: Dates in Calendar are closer than they appear.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.atman.pl!not-for-mai
From: Krzysztof Rudnik <rudnik_at_nospam_kki.net.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Mon, 10 May 2004 09:30:39 +0200
Zbych wrote:
Pewnego dnia Jan Dubiec przemówił ludzkim głosem:
Co nie zabrania istnienia jednolitej adresacji. Np
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
W naszym przypadku to zadziałałoby dla adresów >= 0x10000, ale jak
rozpoznać czy adres np. 0x1000 dotyczy RAM czy ROM. :-)
Skoro i tak wskaźnik zrobi się dłuższy niż 2 bajty to można by
wykorzystać najstarszy bit z 3 bajtu do rozróżniania obszarów.
Ale ta metoda zmuszala by kompilator by kazde odwolanie do
pamieci poprzez wskaznik kompilowal jako sekwencje rozkazow
ze sprawdzeniem wskaznika i wybraniem odpowiedniej instrukcji
w zaleznosci od tego warunku. Kazde odwolanie - to znacznie
wydluzyloby kod.
Krzysiek Rudnik
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.pw.edu.pl!not-for-mai
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Mon, 10 May 2004 10:49:46 +0200
Pewnego dnia Krzysztof Rudnik przemówił ludzkim głosem:
w zaleznosci od tego warunku. Kazde odwolanie - to znacznie
wydluzyloby kod.
A teraz gdy masz dwa zestawy funkcji, osobny do każdej przestrzeni
adresowej to myślisz, że kod jest krótki ? Według mnie w keilu
rozwiązali to naprawdę dobrze. Jeśli z góry wiesz do jakiej pamięci się
odwołujesz to jawnie deklarujesz typ pamięci przy wskaźniku. A jeśli
masz funkcje, które muszą obsłużyć dowolny typ pamięci to używasz
"kombinowanej" wersji wskaźnika.
--
*Warning*: Dates in Calendar are closer than they appear.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Mon, 10 May 2004 01:39:04 +0200
On 10 May 2004 00:34:22 +0200, Jan Dubiec wrote:
To jest zdaje tzw architektura Harward
Zgadza sie, pamieci danych i programu sa fizycznie rozdzielone.
Co nie zabrania istnienia jednolitej adresacji. Np
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
W naszym przypadku to zadziałałoby dla adresów >= 0x10000, ale jak
rozpoznać czy adres np. 0x1000 dotyczy RAM czy ROM. :-) Właśnie po to
są te wszyskie _P funkcje.
To wlasnie musialoby byc zaszyte w procku - inny zakres adresow
ma ROM, inny RAM. To ze oprocz tego bylyby rozdzielone i mialy
osobne magistrale to osobna kwestia - ale adresacja jednolita.
Poza tym w architekturze harwardzkiej przestrzeń adresowa z definicji
jest podzielona na dwa obszary i stosowane są różne instrukcje do
zapisu/odczytu danych z tych obszarów.
IMHO - te rozne instrukcje to juz nie z definicji.
Jest podzielona przynajmniej logicznie - fizycznie może być różnie
Fizycznie w mikrokontrolerach to zawsze jest podzielona - inaczej sie
robi RAM a inaczej EE/E/P/ROM/Flash.
BTW. Wcale nie należy się tak bardzo przyzwyczajać do schematu że
pamięć programu to jest jakiś ROM. Np. we wspomnianych Analogach, ze
względu na wydajność, pamięcią programu jest RAM - podczas startu kod
jest ładowany do RAM z jakiegoś ROM lub przez IDMA z "procesora
nadrzędnego".
A no chyba ze tak.
J.
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.internetia.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!hs001.slackware.pl!new
From: Jan Dubiec <jdx_at_nospam_slackware.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: 10 May 2004 03:14:20 +0200
On Mon, 10 May 2004 01:39:04 +0200, J.F. <jfox_nospam_at_nospam_poczta.onet.pl> wrote:
On 10 May 2004 00:34:22 +0200, Jan Dubiec wrote:
To jest zdaje tzw architektura Harward
Zgadza sie, pamieci danych i programu sa fizycznie rozdzielone.
Co nie zabrania istnienia jednolitej adresacji. Np
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
W naszym przypadku to zadziałałoby dla adresów >= 0x10000, ale jak
rozpoznać czy adres np. 0x1000 dotyczy RAM czy ROM. :-) Właśnie po to
są te wszyskie _P funkcje.
To wlasnie musialoby byc zaszyte w procku - inny zakres adresow
ma ROM, inny RAM. To ze oprocz tego bylyby rozdzielone i mialy
osobne magistrale to osobna kwestia - ale adresacja jednolita.
No ale to byłoby rozwiązanie sprzętowe. I to dosyć "głębokie". Poza
tym nie jestem przekonany czy w takim przypadku rozdzielenie szyn
pamięci danych i programu miałoby sens - ów "dekoder adresów" mógłby
być wąskim gardłem. Trzebaby to przemyśleć.
Poza tym w architekturze harwardzkiej przestrzeń adresowa z definicji
jest podzielona na dwa obszary i stosowane są różne instrukcje do
zapisu/odczytu danych z tych obszarów.
IMHO - te rozne instrukcje to juz nie z definicji.
Jest podzielona przynajmniej logicznie - fizycznie może być różnie
Fizycznie w mikrokontrolerach to zawsze jest podzielona - inaczej sie
robi RAM a inaczej EE/E/P/ROM/Flash.
Chodzi mi o to że mogą dzielić szynę adresową/danych. BTW. IMO to jest
zaprzeczenie celu w jakim wymyślono architekturę harwardzką.
Regards,
/J.D.
--
Jan Dubiec, jdx_at_nospam_slackware.pl, mobile: +48 506 790442
Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.task.gda.pl!not-for-mai
From: Artur Lipowski <lal_at_nospam_pro.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Mon, 10 May 2004 08:26:26 +0200
Piotr Wyderski wrote:
...
Jak to sobie konkretnie wyobrazasz? Tj. czym rozni sie
const char* p; wskazujace na dane w RAM od
const char* p; wskazujace na dane w ROM?
Mozna oczywiscie dodac do jezyka nowe specyfikatory rodzaju
wskazywanej pamieci i zabronic konwersji miedzy nimi, ale to juz
nie bedzie C. :-)
...
No to Cię zaskoczę, bo to jest C. No może takie jakieś jeszcze młode i
nieopierzone, ale C pełną gębą 8-)
http://std.dkuug.dk/JTC1/SC22/WG14/
Jest duże prawdopodobieństwo, że GCC pójdzie właśnie tą drogą.
Pozdrawiam,
--
Artur Lipowski
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.man.poznan.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Jurek Szczesiul <jerzy.szczesiul_at_nospam_wycin.ep.com.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 9 May 2004 11:59:04 +0200
Sun, 09 May 2004 01:31:17 +0200, na pl.misc.elektronika, J.F. napisał(a):
Ale w tym przypadku mamy konkretna tablice, w ktorejs jakos sie
znalazlo miejsce na atrybut "progmem". Printf czy inna funkcja
mialby problemy z okresleniem o ktora pamiec chodzi po wskazniku - ale
tablica[i] kompilator moglby prawidlowo skompilowac, bo wie gdzie
sie ta tablica miesci.
W zasadzie tak - ja zbyt gleboko tego nie znam, tylko temat czesto wraca na
grupach avrfreaks i tak mniej wiecej 'wiedzacy' wyjasniaja : rozdzielone
obszary sa dla gcc klopotem i zastosowano rozne protezy zeby to obejsc -
wyszlo akurat tak jak jest ( wyglada, ze atrybut obszaru jest raczej
informacja dla binutilsow avr a sam kompilator skorzystac z tego nie umie )
tak ... zmienic procka :-) Bo ten zawsze bedzie sprawial takie
klopoty.
-) Wiec raczej moze kompilator, ile to IAR kosztuje ? ;-)
BTW - jakos IMHO nie pasuje roszczenie zbytnich pretensji do narzedzia GNU
- zawsze odpowiadaja, ze jak cos nie tak to ochotnicy mile widziani :-)
--
Pozdrowienia
Jurek Szczesiul
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.man.poznan.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 09 May 2004 12:10:12 +0200
"J.F." wrote:
tak ... zmienic procka :-) Bo ten zawsze bedzie sprawial takie
klopoty.
Tez wyjscie... a co bys polecal ? Irek promuje H8 Renesansa, ponoc
bardzo przyjemne. Jeszcze sie osobiscie nie przygladalem. Pod wzgledem
obudowania peryferiami atrakcyjny moze byc Cypres z rdzeniem '51 i FPGA,
ale raczej w Polsce malo dostepny.
Swoja droga to moze ktos by sprawdzil jak sie ma kompilacja podobnej
sytacji w innym srodowisku C, np IAR-a czy CodeVision ??
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 09 May 2004 22:53:50 +0200
On Sun, 09 May 2004 12:10:12 +0200, Milosz Skowyra wrote:
"J.F." wrote:
tak ... zmienic procka :-) Bo ten zawsze bedzie sprawial takie
klopoty.
Tez wyjscie... a co bys polecal ? Irek promuje H8 Renesansa, ponoc
bardzo przyjemne. Jeszcze sie osobiscie nie przygladalem. Pod wzgledem
obudowania peryferiami atrakcyjny moze byc Cypres z rdzeniem '51 i FPGA,
ale raczej w Polsce malo dostepny.
51 bedzie sprawiala takich klopotow jeszcze wiecej :-)
Z maluchow to chyba motorolki hc11 i hc05 mialy jednolita adresacje.
J.
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.astercity.net!news.aster.pl!not-for-mai
From: Adam Dybkowski <adybkows_at_nospam_amwaw.edu.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 09 May 2004 23:48:36 +0200
Milosz Skowyra wrote:
tak ... zmienic procka :-) Bo ten zawsze bedzie sprawial takie
klopoty.
Tez wyjscie... a co bys polecal ? Irek promuje H8 Renesansa, ponoc
bardzo przyjemne. Jeszcze sie osobiscie nie przygladalem. Pod wzgledem
obudowania peryferiami atrakcyjny moze byc Cypres z rdzeniem '51 i FPGA,
ale raczej w Polsce malo dostepny.
Najlepiej przejsc od razu na ARMa. Procesory z tym jadrem wytwarza
conajmniej kilkudziesieciu roznych producentow. Znajdziesz je m.in. u
Philipsa, Atmela, OKI, TI, Intela. Kompilator gcc oczywiscie jest i
bardzo ladnie sobie radzi. Przewaga nad AVR'ami jest wspolna przestrzen
danych/programu i praktycznie brak ograniczen w adresowaniu (32 bity).
Oczywiscie jest to szybki RISC.
--
Adam Dybkowski
adybkows_at_nospam_amwaw.edu.pl
http://www.amwaw.edu.pl/~adybkows/
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Mon, 10 May 2004 01:00:27 +0200
On Sun, 09 May 2004 23:48:36 +0200, Adam Dybkowski wrote:
Najlepiej przejsc od razu na ARMa. Procesory z tym jadrem wytwarza
conajmniej kilkudziesieciu roznych producentow. Znajdziesz je m.in. u
Philipsa, Atmela, OKI, TI, Intela.
Adamie, ale moze konktretniej - gdzie w UE kilka sztuk, po ile,
i czemu w BGA ? :-(
J.
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.astercity.net!news.aster.pl!not-for-mai
From: Adam Dybkowski <adybkows_at_nospam_amwaw.edu.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Mon, 10 May 2004 23:40:30 +0200
J.F. wrote:
Najlepiej przejsc od razu na ARMa. Procesory z tym jadrem wytwarza
conajmniej kilkudziesieciu roznych producentow. Znajdziesz je m.in. u
Philipsa, Atmela, OKI, TI, Intela.
Adamie, ale moze konktretniej - gdzie w UE kilka sztuk, po ile,
i czemu w BGA ? :-(
Nie bylo mowy, ze ma miec Flash w srodku. A bez tego w TQFP znalezc ARMy
nie problem. Zapytaj np. w JM Elektronik - moga sprowadzic rozne
atmelowe procki. Ja sie ostatnio w firmie bawie AT91R40008 i jest to
calkiem zacny procek. Ze sprowadzeniem kilku szt. nie mielismy problemu.
--
Adam Dybkowski
adybkows_at_nospam_amwaw.edu.pl
http://www.amwaw.edu.pl/~adybkows/
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.nask.pl!uw.edu.pl!news.pw.edu.pl!not-for-mai
From: Zbych <abuse_at_nospam_onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Mon, 10 May 2004 23:43:10 +0200
Pewnego dnia Adam Dybkowski przemówił ludzkim głosem:
Ze sprowadzeniem kilku szt. nie mielismy problemu.
A możesz zdradzić cenę ?
--
*Warning*: Dates in Calendar are closer than they appear.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.astercity.net!news.aster.pl!not-for-mai
From: Adam Dybkowski <adybkows_at_nospam_amwaw.edu.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 13 May 2004 02:22:11 +0200
Zbych wrote:
Ze sprowadzeniem kilku szt. nie mielismy problemu.
A możesz zdradzić cenę ?
Jakis czas temu pytalem sie o te ARMy w Seguro i dostalem cene AFAIR
kilkanascie USD/szt + VAT. Po przeliczeniu wychodzilo okolo 100 zl, co
jest IMHO super cena w porownaniu do ATmegi128 (za 40-50 zl) - ARM jest
4x szybszy i ma 256KB RAMu w srodku. Jedyna wada to brak Flasha, ale
latwo ja naprawic dodatkowa kostka (kilkanascie zl).
--
Adam Dybkowski
adybkows_at_nospam_amwaw.edu.pl
http://www.amwaw.edu.pl/~adybkows/
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Michal Baszynski <mbaszyns_at_nospam_ga.ze.ta.pl.>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 13 May 2004 12:30:10 +0200
On Thu, 13 May 2004 02:22:11 +0200, Adam Dybkowski
<adybkows_at_nospam_amwaw.edu.pl> wrote:
Jakis czas temu pytalem sie o te ARMy w Seguro i dostalem cene AFAIR
kilkanascie USD/szt + VAT. Po przeliczeniu wychodzilo okolo 100 zl, co
jest IMHO super cena w porownaniu do ATmegi128 (za 40-50 zl) - ARM jest
4x szybszy i ma 256KB RAMu w srodku. Jedyna wada to brak Flasha, ale
latwo ja naprawic dodatkowa kostka (kilkanascie zl).
tylko 4 razy szybszy?
hmmm... chyba sie bede musial TMS320F24xx/28xx zainteresowac..
--
Pozdr
Michal
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!opal.futuro.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!hs001.slackware.pl!new
From: Jan Dubiec <jdx_at_nospam_slackware.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: 13 May 2004 17:33:59 +0200
On Thu, 13 May 2004 02:22:11 +0200, Adam Dybkowski <adybkows_at_nospam_amwaw.edu.pl> wrote:
Zbych wrote:
Ze sprowadzeniem kilku szt. nie mielismy problemu.
A możesz zdradzić cenę ?
Jakis czas temu pytalem sie o te ARMy w Seguro i dostalem cene AFAIR
kilkanascie USD/szt + VAT. Po przeliczeniu wychodzilo okolo 100 zl, co
jest IMHO super cena w porownaniu do ATmegi128 (za 40-50 zl) - ARM
jest 4x szybszy i ma 256KB RAMu w srodku. Jedyna wada to brak Flasha,
ale latwo ja naprawic dodatkowa kostka (kilkanascie zl).
Ja (i nie tylko ja) wspominałem kilka razy na tej grupie o ARM-ach OKI
którymi handluje Memec. Zgodnie z informacjami które od nich dostałem,
taki ML675003 (512KiB Flash, 32KiB RAM, 60MHz, 8KiB cache, LQFP144)
w małych ilościach kosztuje jakieś $14 netto, czyli $17 z VAT, czyli
jakieś 70PLN. I to jest dobra cena w porównaniu do cen ośmiobitowców.
BTW. Jak żeś robił te pomiary(szacunki) że Ci wyszło własnie 4 a nie
np. 2 lub 20. :-)
Regards,
/J.D.
--
Jan Dubiec, jdx_at_nospam_slackware.pl, mobile: +48 506 790442
Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.astercity.net!news.aster.pl!not-for-mai
From: Adam Dybkowski <adybkows_at_nospam_amwaw.edu.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Fri, 14 May 2004 01:25:04 +0200
Jan Dubiec wrote:
jest IMHO super cena w porownaniu do ATmegi128 (za 40-50 zl) - ARM
jest 4x szybszy i ma 256KB RAMu w srodku. Jedyna wada to brak Flasha,
ale latwo ja naprawic dodatkowa kostka (kilkanascie zl).
Ja (i nie tylko ja) wspominałem kilka razy na tej grupie o ARM-ach OKI
którymi handluje Memec. Zgodnie z informacjami które od nich dostałem,
taki ML675003 (512KiB Flash, 32KiB RAM, 60MHz, 8KiB cache, LQFP144)
w małych ilościach kosztuje jakieś $14 netto, czyli $17 z VAT, czyli
jakieś 70PLN. I to jest dobra cena w porównaniu do cen ośmiobitowców.
BTW. Jak żeś robił te pomiary(szacunki) że Ci wyszło własnie 4 a nie
np. 2 lub 20. :-)
Porownalem ATmege 16 MHz z ARMem 66 MHz. I wyszlo 4,125x. Wydajnosc
programow na ARMie moze byc nieco wieksza - ale to zalezy od programu -
z powodu 32-bitowych operacji i lepszego asemblera (m.in. instrukcje
wykonywane warunkowo i opcjonalnie zmieniajace stan flag).
Oczywiscie jezeli chodzi o platforme ARM jako taka, to bez problemu do
porownania mozna wziac intelowe procki XScale z zegarem 400 MHz - beda
25x szybsze niz ATmega128. :-)
BTW: Czy te flashowe ARMy OKI maja jakies bity do zabezpieczenia pamieci
programu przed odczytem z zewnatrz (lub gdy ktos sie podlaczy po JTAGu)?
--
Adam Dybkowski
adybkows_at_nospam_amwaw.edu.pl
http://www.amwaw.edu.pl/~adybkows/
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.itl.waw.pl!not-for-mai
From: "Jacek R. Radzikowski" <jacek_at_nospam_spamer.die.die.die.piranet.org>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Fri, 14 May 2004 01:29:53 +0000 (UTC)
Adam Dybkowski <adybkows_at_nospam_amwaw.edu.pl> wrote:
Porownalem ATmege 16 MHz z ARMem 66 MHz. I wyszlo 4,125x. Wydajnosc
programow na ARMie moze byc nieco wieksza - ale to zalezy od programu -
Tyle wychodzi z porownania zegarow. Czy to oznacza ze arm ma identyczna
wydajnosc na MHz zegara co avr? Wydaje mi sie to neico podejzane
z powodu 32-bitowych operacji i lepszego asemblera (m.in. instrukcje
wykonywane warunkowo i opcjonalnie zmieniajace stan flag).
a takze zersze rejestry, co ulatwia adresowanie, prostsza struktura
pamieci i wiele innych
Oczywiscie jezeli chodzi o platforme ARM jako taka, to bez problemu do
porownania mozna wziac intelowe procki XScale z zegarem 400 MHz - beda
25x szybsze niz ATmega128. :-)
Oj, cos mi sie wydaje ze wiecej. Gdyby to byla tylko roznica w zegarze,
AVR nie pchal by sie w droga licencje a podkrecil zegar w swoich
8-bitowcach
pzdr.
j.
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!hs001.slackware.pl!new
From: Jan Dubiec <jdx_at_nospam_slackware.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: 14 May 2004 17:04:04 +0200
On Fri, 14 May 2004 01:25:04 +0200, Adam Dybkowski <adybkows_at_nospam_amwaw.edu.pl> wrote:
[.....]
Porownalem ATmege 16 MHz z ARMem 66 MHz. I wyszlo 4,125x. Wydajnosc
programow na ARMie moze byc nieco wieksza - ale to zalezy od programu
z powodu 32-bitowych operacji i lepszego asemblera (m.in. instrukcje
wykonywane warunkowo i opcjonalnie zmieniajace stan flag).
Tak podejrzewałem że porównywałeś maksymalne zegary. Ale nawet z tym samym
zegarem ARM powinnien być kilkukrotnie szybszy z powodu cech które wymieniłeś.
Aczkolwiek, tak jak napisałeś, to zależy od aplikacji. Chociaż z drugiej
strony do sterownika wymieniającego dane po RS232 i sterującego dziesięcioma
przekaźnikami prawdopodobnie nie ma sensu wsadzać jakiegoś ARM-a.
[.....]
BTW: Czy te flashowe ARMy OKI maja jakies bity do zabezpieczenia
pamieci programu przed odczytem z zewnatrz (lub gdy ktos sie podlaczy
po JTAGu)?
AFAIK nie mają - nie znalazłem nic na ten temat w dejtaszicie.
Regards,
/J.D.
--
Jan Dubiec, jdx_at_nospam_slackware.pl, mobile: +48 506 790442
Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.astercity.net!news.aster.pl!not-for-mai
From: Adam Dybkowski <adybkows_at_nospam_amwaw.edu.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sun, 16 May 2004 00:15:52 +0200
Jan Dubiec wrote:
BTW: Czy te flashowe ARMy OKI maja jakies bity do zabezpieczenia
pamieci programu przed odczytem z zewnatrz (lub gdy ktos sie podlaczy
po JTAGu)?
AFAIK nie mają - nie znalazłem nic na ten temat w dejtaszicie.
No to dali ciala. Procki z Flashem nijak nie zabezpieczonym odpadaja w
przedbiegach w wielu projektach. Chyba zadna firma nie chce, aby ktos
zrobil podrobke jej sprzetu. Albo wyciagnal z pamieci jakies wazne dane.
Na podobna przypadlosc cierpia flashowe ARMy atmelowe (te w BGA) -
pamiec Flash chyba doczepili "na odczep sie", bo wszystkie piny (kulki)
pamieci sa wyprowadzone na zewnatrz i za pomoca odpowiedniej
przejsciowki mozna ja programowac w zwyklym programatorze Flashy.
Czy jakas firma robi ARMa min. 100-nozkowego (pelne EBI) z sensownie
zabezpieczona pamiecia Flash? Nie mam duzych wymagan, wystarcza lockbity
a'la AVR.
--
Adam Dybkowski
adybkows_at_nospam_amwaw.edu.pl
http://www.amwaw.edu.pl/~adybkows/
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!hs001.slackware.pl!new
From: Jan Dubiec <jdx_at_nospam_slackware.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: 16 May 2004 01:58:01 +0200
On Sun, 16 May 2004 00:15:52 +0200, Adam Dybkowski <adybkows_at_nospam_amwaw.edu.pl> wrote:
[.....]
Na podobna przypadlosc cierpia flashowe ARMy atmelowe (te w BGA) -
pamiec Flash chyba doczepili "na odczep sie", bo wszystkie piny
(kulki) pamieci sa wyprowadzone na zewnatrz i za pomoca odpowiedniej
przejsciowki mozna ja programowac w zwyklym programatorze Flashy.
Bo AFAIK te ARM-y to są dwie struktury w jednej obudowie. Aczkolwiek
podobno Atmel ma wypuścić nowe wersje gdzie wszystko będzie umieszczone
na jednym kawałku krzemu.
Czy jakas firma robi ARMa min. 100-nozkowego (pelne EBI) z sensownie
zabezpieczona pamiecia Flash? Nie mam duzych wymagan, wystarcza
lockbity a'la AVR.
Też bym chciał wiedzieć. Chociaż bardziej z ciekawości niż z potrzeby.
IMO wcale nie jest łatwo (czytaj: tanio) zrobić reverse engineering
jakiegoś większego kawałka kodu. A jak komuś będzie bardzo zależało to
zeszlifuje kość warstwa po warstwie - chociaż niektórzy producenci
przechwalają się że ich kości są na to odporne - np. Actel tak mówi o
swoich ProASIC+.
Regards,
/J.D.
--
Jan Dubiec, jdx_at_nospam_slackware.pl, mobile: +48 506 790442
Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.task.gda.pl!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Mon, 10 May 2004 19:26:22 +0200
Adam Dybkowski wrote:
Najlepiej przejsc od razu na ARMa. Procesory z tym jadrem wytwarza
conajmniej kilkudziesieciu roznych producentow. Znajdziesz je m.in. u
Philipsa, Atmela, OKI, TI, Intela. Kompilator gcc oczywiscie jest i
bardzo ladnie sobie radzi. Przewaga nad AVR'ami jest wspolna przestrzen
danych/programu i praktycznie brak ograniczen w adresowaniu (32 bity).
Oczywiscie jest to szybki RISC.
A mozesz podac jakis modelik ARM-a ktory bylby dostepny (nie w Elfie)
choc ulamkowo tak czesto jak '51 czy AVR-y ?? To w naszym kochanym kraju
chyba najwiekszy problem ;-(
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.astercity.net!news.aster.pl!not-for-mai
From: Adam Dybkowski <adybkows_at_nospam_amwaw.edu.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Mon, 10 May 2004 23:43:37 +0200
Milosz Skowyra wrote:
Najlepiej przejsc od razu na ARMa.
A mozesz podac jakis modelik ARM-a ktory bylby dostepny (nie w Elfie)
choc ulamkowo tak czesto jak '51 czy AVR-y ?? To w naszym kochanym kraju
chyba najwiekszy problem ;-(
Polecam np. AT91R40807 albo od razu nieco wiekszy i szybszy AT91R40008.
Zapytaj sie o nie w JM Elektronik / Seguro. Albo u innego dystrybutora
Atmela.
--
Adam Dybkowski
adybkows_at_nospam_amwaw.edu.pl
http://www.amwaw.edu.pl/~adybkows/
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Tue, 11 May 2004 14:42:58 +0200
Adam Dybkowski wrote:
Polecam np. AT91R40807 albo od razu nieco wiekszy i szybszy AT91R40008.
Zapytaj sie o nie w JM Elektronik / Seguro. Albo u innego dystrybutora
Atmela.
Ehem... a jest cos z flashem na grzbiecie i jakas forma ISP ? Cos
typowego do nauki ??
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.astercity.net!news.aster.pl!not-for-mai
From: Adam Dybkowski <adybkows_at_nospam_amwaw.edu.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 13 May 2004 02:23:07 +0200
Milosz Skowyra wrote:
Polecam np. AT91R40807 albo od razu nieco wiekszy i szybszy AT91R40008.
Zapytaj sie o nie w JM Elektronik / Seguro. Albo u innego dystrybutora
Atmela.
Ehem... a jest cos z flashem na grzbiecie i jakas forma ISP ? Cos
typowego do nauki ??
BTW: ISP nie trzeba, bo kazdy ARM ma interfejs JTAG.
--
Adam Dybkowski
adybkows_at_nospam_amwaw.edu.pl
http://www.amwaw.edu.pl/~adybkows/
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 13 May 2004 11:31:55 +0200
Adam Dybkowski wrote:
Ehem... a jest cos z flashem na grzbiecie i jakas forma ISP ? Cos
typowego do nauki ??
BTW: ISP nie trzeba, bo kazdy ARM ma interfejs JTAG.
No to z ciekawosci zapytam tylko o dostepnosc interfejsow JTAG-a.
Podobnie jak do Atmeli da sie zrobic handmade czy pozostaje tylko kupno.
No jak jest z kompilatorami. Pytam nie dlatego ze nie chce mi sie
szukac, tylko dlatego ze troszke juz w tym siedzisz i chyba lepiej wiesz
co i jak.
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 13 May 2004 13:15:19 +0200
On Thu, 13 May 2004 11:31:55 +0200, Milosz Skowyra wrote:
Adam Dybkowski wrote:
Ehem... a jest cos z flashem na grzbiecie i jakas forma ISP ? Cos
typowego do nauki ??
BTW: ISP nie trzeba, bo kazdy ARM ma interfejs JTAG.
No to z ciekawosci zapytam tylko o dostepnosc interfejsow JTAG-a.
Podobnie jak do Atmeli da sie zrobic handmade czy pozostaje tylko kupno.
Jtag to jest elektrycznie trywialny interfejs, do ktorego chocby LPT
wystarczy.
A oprogramowanie do tego to jest osobna sprawa.
J.
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.astercity.net!news.aster.pl!not-for-mai
From: Adam Dybkowski <adybkows_at_nospam_amwaw.edu.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Fri, 14 May 2004 01:19:25 +0200
Milosz Skowyra wrote:
Ehem... a jest cos z flashem na grzbiecie i jakas forma ISP ? Cos
typowego do nauki ??
BTW: ISP nie trzeba, bo kazdy ARM ma interfejs JTAG.
No to z ciekawosci zapytam tylko o dostepnosc interfejsow JTAG-a.
Akurat ARM to standard jakich malo :-) i interfejs JTAG sklada sie z
bufora podlaczanego do portu drukarki (podobnego do Altera ByteBlaster).
Programowanie i debugowanie przez JTAG jest dobrze opisane, istnieja
programy windozowe i linuxowe. Sam widzialem, jak qmpel w pracy odpalal
pod Linuxem gdb z ARMem. Bez zadnego specjalnego sprzetu.
--
Adam Dybkowski
adybkows_at_nospam_amwaw.edu.pl
http://www.amwaw.edu.pl/~adybkows/
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Fri, 14 May 2004 11:51:49 +0200
Adam Dybkowski wrote:
Akurat ARM to standard jakich malo :-) i interfejs JTAG sklada sie z
bufora podlaczanego do portu drukarki (podobnego do Altera ByteBlaster).
Programowanie i debugowanie przez JTAG jest dobrze opisane, istnieja
programy windozowe i linuxowe. Sam widzialem, jak qmpel w pracy odpalal
pod Linuxem gdb z ARMem. Bez zadnego specjalnego sprzetu.
Jasne. Dzieki bardzo.
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sat, 08 May 2004 18:36:09 +0200
On Sat, 8 May 2004 17:25:03 +0200, Jurek Szczesiul wrote:
To juz nie wiem jak robisz. Taki tu prosty przyklad różnych składni:
const char Tx1[] PROGMEM = "One";
....................
i=1;
x=pgm_read_byte(Tx1);
x=pgm_read_byte(&Tx1[i]);
i=2;
x=pgm_read_byte(Tx1 + i);
generuje :
Wow - popatrzcie jak optymalizator ladnie sledzi jakie stale wpisujemy
do i
i=1;
180: 81 e0 ldi r24, 0x01 ; 1
182: 90 e0 ldi r25, 0x00 ; 0
184: 90 93 70 00 sts 0x0070, r25
188: 80 93 6f 00 sts 0x006F, r24
x=pgm_read_byte(Tx1);
18c: e6 e9 ldi r30, 0x96 ; 150
18e: f0 e0 ldi r31, 0x00 ; 0
190: 84 91 lpm r24, Z
192: 80 93 6c 00 sts 0x006C, r24
x=pgm_read_byte(&Tx1[i]);
196: 31 96 adiw r30, 0x01 ; 1
198: 84 91 lpm r24, Z
19a: 80 93 6c 00 sts 0x006C, r24
i=2;
19e: 82 e0 ldi r24, 0x02 ; 2
1a0: 90 e0 ldi r25, 0x00 ; 0
1a2: 90 93 70 00 sts 0x0070, r25
1a6: 80 93 6f 00 sts 0x006F, r24
x=pgm_read_byte(Tx1 + i);
1aa: 31 96 adiw r30, 0x01 ; 1
1ac: 84 91 lpm r24, Z
1ae: 80 93 6c 00 sts 0x006C, r24
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.internetia.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Sat, 08 May 2004 20:23:58 +0200
"J.F." wrote:
const char Tx1[] PROGMEM = "One";
Wow - popatrzcie jak optymalizator ladnie sledzi jakie stale wpisujemy
do i
Zauwaz rowniez ze wypromowal chara do inta.
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.gazeta.pl!news.dialog.net.pl!not-for-mai
From: "Piotr Wyderski" <piotr.wyderski_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Wed, 5 May 2004 22:08:54 +0200
Milosz Skowyra wrote:
Juz sam wiem, olalem warninga kompilatora i zapomnialem o zrzutowaniu
wskaznika na integera ;-)
Wcale nie, to Ty nie przeczytales tego warninga i nie zamieniles
integera na char*. Przykro mi, dopisujac "brakujace" rzutowanie
Ty nie naprawiles tego programu, Ty zgwalciles kompilator. :->
Pozdrawiam
Piotr Wyderski
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 06 May 2004 12:41:06 +0200
On Wed, 5 May 2004 22:08:54 +0200, Piotr Wyderski wrote:
Milosz Skowyra wrote:
Juz sam wiem, olalem warninga kompilatora i zapomnialem o zrzutowaniu
wskaznika na integera ;-)
Wcale nie, to Ty nie przeczytales tego warninga i nie zamieniles
integera na char*. Przykro mi, dopisujac "brakujace" rzutowanie
Ty nie naprawiles tego programu, Ty zgwalciles kompilator. :->
Nic na sile ... wszystko mlotkiem :-)
J.
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.internetia.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 06 May 2004 15:04:36 +0200
"J.F." wrote:
Wcale nie, to Ty nie przeczytales tego warninga i nie zamieniles
integera na char*. Przykro mi, dopisujac "brakujace" rzutowanie
Ty nie naprawiles tego programu, Ty zgwalciles kompilator. :->
Nic na sile ... wszystko mlotkiem :-)
Nie takie rzeczy my ze Zbysiem po trzech flaszkach ;-)))
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: "Andy" <anokWYTNIJ_at_nospam_ceti.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Wed, 5 May 2004 03:56:01 +0200
Użytkownik "Milosz Skowyra" <mewashek_at_nospam_wp.pl> napisał w wiadomości
news:40982E77.75A88955_at_nospam_wp.pl...
...
static unsigned char _attribute_ ((progmem)) polish_chars[]={
0x0C,0x04,0x06,0x0C,0x04,0x04,0x0E,0x00, //0 - l
[...]
0x00,0x04,0x0E,0x10,0x10,0x11,0x0E,0x00}; //5 = c
for (unsigned char f=1;f<64;f++)
{
lcd_port=pgm_read_byte(&polish_chars+f);
...
a nie mogl bys tej tablicy jakos po ludzku indeksowac ? :-)
polish_chars[ f ]
tak jest chyba najbardziej naturalnie
--
Andrzej
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Wed, 05 May 2004 15:19:30 +0200
Andy wrote:
a nie mogl bys tej tablicy jakos po ludzku indeksowac ? :-)
polish_chars[ f ]
tak jest chyba najbardziej naturalnie
Tylko ze nie bardzo chce dzialac ;-)
W R14 i R15 jest adres poczatku tablicy.
MOV R31,R15
MOV R30,R14 ;to niby poprawnie, do Z wpisuje pocz.tablicy
LD R24,Z+ ;w dziwny sposob zwieksza Z o jeden i czyta
;bajt z RAMU spod adresu poczatku tablicy w ROM
MOV R14,R30 ;zrzuca adres tablicy +1
MOV R15,R31
MOV R30,R24 ;i gdyby nie wykonal tego to LPM odczytalo by
CLR R31 ;poprawna wartosc, a tak dostajemy krzaczki.
LPM
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!news.gazeta.pl!newsfeed.gazeta.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Wed, 05 May 2004 16:59:19 +0200
On Wed, 05 May 2004 15:19:30 +0200, Milosz Skowyra wrote:
Andy wrote:
a nie mogl bys tej tablicy jakos po ludzku indeksowac ? :-)
polish_chars[ f ]
Tylko ze nie bardzo chce dzialac ;-)
W R14 i R15 jest adres poczatku tablicy.
MOV R31,R15
MOV R30,R14 ;to niby poprawnie, do Z wpisuje pocz.tablicy
LD R24,Z+ ;w dziwny sposob zwieksza Z o jeden i czyta
Ta dziwnosc moze byc sprytnoscia - jesli rozpoznal ze w kolejnych
obiegach petli siegasz do kolejnych komorek pamieci, to jest
to prawidlowa kompilacja.
;bajt z RAMU spod adresu poczatku tablicy w ROM
MOV R14,R30 ;zrzuca adres tablicy +1
MOV R15,R31
MOV R30,R24 ;i gdyby nie wykonal tego to LPM odczytalo by
CLR R31 ;poprawna wartosc, a tak dostajemy krzaczki.
LPM
A nie przekombinowales znowu ? Moze masz
lcd_port=pgm_read_byte(polish_chars[f]);
J.
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.onet.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 06 May 2004 11:24:10 +0200
"J.F." wrote:
a nie mogl bys tej tablicy jakos po ludzku indeksowac ? :-)
polish_chars[ f ]
Tylko ze nie bardzo chce dzialac ;-)
W R14 i R15 jest adres poczatku tablicy.
MOV R31,R15
MOV R30,R14 ;to niby poprawnie, do Z wpisuje pocz.tablicy
LD R24,Z+ ;w dziwny sposob zwieksza Z o jeden i czyta
Ta dziwnosc moze byc sprytnoscia - jesli rozpoznal ze w kolejnych
obiegach petli siegasz do kolejnych komorek pamieci, to jest
to prawidlowa kompilacja.
Bez przesady, szybciej bedzie mu zrobic adiw z,1 bo nie bedzie przelewal
Z w rejestry tam i spowrotem.
;bajt z RAMU spod adresu poczatku tablicy w ROM
MOV R14,R30 ;zrzuca adres tablicy +1
MOV R15,R31
MOV R30,R24 ;i gdyby nie wykonal tego to LPM odczytalo by
CLR R31 ;poprawna wartosc, a tak dostajemy krzaczki.
LPM
A nie przekombinowales znowu ? Moze masz
lcd_port=pgm_read_byte(polish_chars[f]);
Dokladnie tak, bo tak sugerowal Andy ;-)
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.atman.pl!not-for-mai
From: Krzysztof Rudnik <rudnik_at_nospam_kki.net.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Wed, 05 May 2004 07:25:06 +0200
Milosz Skowyra wrote:
Ehlo.
Jako ze guru wiedzy na temat C jeszcze nie jestem (ale zamierzam ;-)))
), wynalazlem pewien problem ktory mnie meczy. Mianowicie w programie
definiuje znaki LCD za w nastepujacy sposob:
definicje znakow:
static unsigned char _attribute_ ((progmem)) polish_chars[]={
0x0C,0x04,0x06,0x0C,0x04,0x04,0x0E,0x00, //0 - l
[...]
0x00,0x04,0x0E,0x10,0x10,0x11,0x0E,0x00}; //5 = c
for (unsigned char f=1;f<64;f++)
{
lcd_port=pgm_read_byte(&polish_chars+f);
data_port |= (unsigned char)_BV(rs);
nop();nop();nop();
data_port |= (unsigned char)_BV(en);
nop();nop();nop();
data_port &= (unsigned char)~_BV(en);
data_port &= (unsigned char)~_BV(rs);
lcd_delay_short();
}
No i problem. Mianowicie wartosc wyliczona przez (&polish_chars+f) w
- w takim ukladzie moze ci adrument zwiekszac w sizeof(polish_chars),
wyrzuc ten &. Wtedy argumentami pgm_read_byte beda kolejne adresy
zaczynajac od &polish_chars[f]. Mozna tez tak zapisac. W C
dodanie liczby n do pointera tworzy pointer przesuniety o
n - elementow tablicy. Ty dodajesz liczba do adresu calej tablicy,
a nie do adresu jej pierwszego elementu.
Podsumowujac:
&polish_chars[f] - adres f-tego elementu tablicy
polish_chars+f - tyle samo
&polish_chars+f - adres f-tej tablicy
Krzysiek Rudnik
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.task.gda.pl!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Wed, 05 May 2004 15:23:31 +0200
Krzysztof Rudnik wrote:
No i problem. Mianowicie wartosc wyliczona przez (&polish_chars+f) w
- w takim ukladzie moze ci adrument zwiekszac w sizeof(polish_chars),
wyrzuc ten &. Wtedy argumentami pgm_read_byte beda kolejne adresy
zaczynajac od &polish_chars[f]. Mozna tez tak zapisac. W C
dodanie liczby n do pointera tworzy pointer przesuniety o
n - elementow tablicy. Ty dodajesz liczba do adresu calej tablicy,
a nie do adresu jej pierwszego elementu.
Zgadza sie. Co prawda po przeczytaniu kilku postow mam maly metlik, ale
sprobuje usystematyzowac.
&polish_chars - to adres poczatku tablicy.
Jesli zrobie *x=&polish_chars to wskaznik *x wskazuje na poczatek
tablicy.
Poprawnie ??
Podsumowujac:
&polish_chars[f] - adres f-tego elementu tablicy
polish_chars+f - tyle samo
&polish_chars+f - adres f-tej tablicy
Dzieki... dobrze mysle tylko nie potrafie tego jeszcze dobrze w C
zapisac ;-(
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.dialog.net.pl!not-for-mai
From: "Piotr Wyderski" <piotr.wyderski_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Wed, 5 May 2004 22:08:51 +0200
Milosz Skowyra wrote:
for (unsigned char f=1;f<64;f++)
Wiesz, w C tablice indeksuje sie poczynajac od 0. :-)
Poza tym postinkrementacji nalezy uzywac tylko gdy
naprawde trzeba; w przeciwnym przypadku nalezy
uzyc preinkrementacji: ++f. W tym przypadku nie
ma to znaczenia, ale jesli zaczniesz programowac w
C++, to zobaczysz roznice, gdy sobie przeciazysz ++.
No i problem. Mianowicie wartosc wyliczona przez (&polish_chars+f) w
pierwszym odczycie daje poprawnie wartosc 0x22, jednak w kolejnym kroku
kompilator zwieksza Z nie o jeden jak powinien lecz o 0x31 (cos jakby
wartosc '1' w ASCII). Popelniam jakis blad ??
Scisle rzecz biorac nie popelniasz bledu, ale napisales
kompilatorowi nie ten program o ktorym myslales. :-)
Kazesz mu wziac adres poczatku f-tej tablicy, a
nie adres f-tego elementu tej tablicy. Natomiast to
0x31 do niczego mi nie pasuje: masz 49 elementow w tablicy?
unsigned char f=0;
int g;
g=(&polish_chars);
No chyba zartujesz. :-) Dlaczego nie uzyjesz
const unsigned char* g = polish_chars;
?
Pozdrawiam
Piotr Wyderski
PS. Cos wspominales o przejsciu na uprawe marchewki. ;-)))
========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 06 May 2004 11:20:31 +0200
Piotr Wyderski wrote:
Scisle rzecz biorac nie popelniasz bledu, ale napisales
kompilatorowi nie ten program o ktorym myslales. :-)
Kazesz mu wziac adres poczatku f-tej tablicy, a
nie adres f-tego elementu tej tablicy. Natomiast to
0x31 do niczego mi nie pasuje: masz 49 elementow w tablicy?
Tia, w probnej wersji bylo tylko 49 elementow. Teraz juz kumkam.
PS. Cos wspominales o przejsciu na uprawe marchewki. ;-)))
Wlasnie kombajn do zbiorow konstruuje ;-))
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!not-for-mai
From: J.F. <jfox_nospam_at_nospam_poczta.onet.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 06 May 2004 12:41:06 +0200
On Wed, 5 May 2004 22:08:51 +0200, Piotr Wyderski wrote:
for (unsigned char f=1;f<64;f++)
Poza tym postinkrementacji nalezy uzywac tylko gdy
naprawde trzeba; w przeciwnym przypadku nalezy
uzyc preinkrementacji: ++f. W tym przypadku nie
ma to znaczenia, ale jesli zaczniesz programowac w
C++, to zobaczysz roznice, gdy sobie przeciazysz ++.
Nie bardzo rozumiem ?
int g;
g=(&polish_chars);
No chyba zartujesz. :-) [...]
PS. Cos wspominales o przejsciu na uprawe marchewki. ;-)))
ROTFL :-)
Ale rada dobra - jak sie nie chce czytac podrecznika, to trzeba sie
czym innym zajac :-)
J.
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.dialog.net.pl!not-for-mai
From: "Piotr Wyderski" <piotr.wyderski_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Thu, 6 May 2004 15:23:57 +0200
J.F. wrote:
Nie bardzo rozumiem ?
Roznica jest w definicji wartosci zwracanej przez operator.
W operatorze prefiksowym jest prosto, bo najpierw wykonuje
sie operacje, a dopiero pozniej zwraca zmodyfikowany obiekt.
W przypadku operatora postfiksowego trzeba zwrocic
obiekt opisujacy stan przed wykonaniem operacji, co
pociaga za soba koniecznosc skonstruowania obiektu
tymczasowego. Jesli obiekt jest typu wbudowanego, to
w zasadzie nie ma roznicy, bo kompilator wyrzuci niepotrzebny
obiekt w fazie optymalizacji. Jesli jednak napiszesz wlasny
obiekt implementujacy oba operatory ++, to kompilator nie
bedzie juz mogl tego dokonac. Dlatego warto wyrabiac
sobie nawyk uzywania "tanszych" wersji operatorow, gdy
mozna sobie na to pozwolic. Operator prefiksowy jest tanszy,
bo zazwyczaj zwraca referencje do obiektu, a nie obiekt.
Pozdrawiam
Piotr Wyderski
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!opal.futuro.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai
From: Milosz Skowyra <mewashek_at_nospam_wp.pl>
Subject: Re: Dziwne zachowanie kompilatora w AVRGCC.
Date: Fri, 07 May 2004 16:41:08 +0200
"J.F." wrote:
PS. Cos wspominales o przejsciu na uprawe marchewki. ;-)))
Ale rada dobra - jak sie nie chce czytac podrecznika, to trzeba sie
czym innym zajac :-)
Nie chcial Milosz nosic teczki to ponosi marcheweczki ;-)))
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.internetia.pl!news.ipartners.pl!not-for-mai