SDCC- =?iso-8859-2?Q?boj=F3w=20ci=B1g?= dalszy.
Masz problem? Zapytaj na forum elektroda.pl
From: Marcin Wolcendorf <wolcendo_at_nospam_free.polbox.pl>
Subject: SDCC- =?iso-8859-2?Q?boj=F3w=20ci=B1g?= dalszy.
Date: Sat, 24 Feb 2001 16:12:40 +0100
Witam,
Oto ciąg dalszy moich bojów z SDCC. Jak dotąd kłpoty z SDCC można
było określić mianem 'niedoróbki', tym razem sprawa jest
poważniejsza-
ewidentny błąd. Kompilator ma kłopoty (co ciekawe- nie w każdym
przypadku- kilka linijek wcześniej wykonuje takie samo odejmowanie,
tylko wyniku nie zachowuje i wszystko jes poprawnie- nie wiem, z
czego
to wynika) z odejmowaniem longów- robi to źle.
Poniżej to, co kompilator zrobił z następującego kodu w C:
t_pom[idx] = c_timer - l_timer;
(t_pom jest tablicą longów, c_timer i l_timer są longami, idx- indeks
do
tablicy)
Polskie komentarze są moimi komentarzami do wygenerowanego asemblera.
mov r0,#_idx ;nr elemntu
mov a,_at_nospam_r0
add a,acc ;mnozony przez 4
;bo to przecież tablica longów
add a,acc
; Peephole 105 removed redundant mov
mov r2,a
add a,#_t_pom ;dodajemy do początku tablicy
;tablica jest krótka i w wew. ramie pod SFR-ami
mov r0,a ;no bo inaczej trudno się dostać
;no i tu się zaczyna- próbujemy odjąć dwa longi...
mov r1,#_c_timer
mov r1,#_l_timer
;pierwsze zdziwienie- dlaczego w r1 lądują adresy
;obu (a w rezultacie- drugiej) zmiennych?
;a dalej już konsekwentnie- wszystko jest skopane
clr c
mov a,_at_nospam_r1
subb a,_at_nospam_r1
mov r2,a
inc r1
mov a,_at_nospam_r1
inc r1
subb a,_at_nospam_r1
mov r3,a
inc r1
mov a,_at_nospam_r1
;a tu już jesteśmy poza zmienną l_timer
;w rezultacie gdzieś sobie łazimy po pamięci...
;odejmując- co od czego? diabli wiedzą.
inc r1
subb a,_at_nospam_r1
mov r4,a
inc r1
mov a,_at_nospam_r1
inc r1
subb a,_at_nospam_r1
mov r5,a
;no to sobie 'odjęliśmy'...
;teraz 'wynik' wkładamy do tablicy...
mov _at_nospam_r0,ar2
inc r0
mov _at_nospam_r0,ar3
inc r0
mov _at_nospam_r0,ar4
inc r0
mov _at_nospam_r0,ar5
C$tachog.c$228$3$5 ==.
Koniec.
Pozdrawiam,
Marcin.
--
'My experience is that it is hard to find software producers that aren't
fuzzy.'
From: Grzegorz Redlarski <gred_at_nospam_kki.net.pl>
Subject: =?ISO-8859-2?Q?Re:_SDCC-_boj=F3w_ci=B1g_dalszy.?=
Date: Mon, 26 Feb 2001 00:14:21 +0100
Sat, 24 Feb 2001 16:12:40 +0100 Marcin Wolcendorf
<wolcendo_at_nospam_free.polbox.pl> napisal:
Witam,
Oto ciąg dalszy moich bojów z SDCC. Jak dotąd kłpoty z SDCC można
było określić mianem 'niedoróbki', tym razem sprawa jest
poważniejsza-
ewidentny błąd. Kompilator ma kłopoty (co ciekawe- nie w każdym
przypadku- kilka linijek wcześniej wykonuje takie samo odejmowanie,
tylko wyniku nie zachowuje i wszystko jes poprawnie- nie wiem, z
czego
to wynika) z odejmowaniem longów- robi to źle.
Kompilator C do DSP Motoroli, również GNU (choć źródeł do niego próżno
szukać w Inernecie), też najwięcej głupot robił przy longach, głównie
przy konwersji typów.
W sdcc też jest chyba coś nie tak z konwersjami. Jak znajdę trochę
czasu by dokładniej sprawę wybadać to dam znać. Chyba chodziło o stałe
występujące jako argumenty funkcji - liczby < 256 źle konwertował na
int (zgodnie z ANSI powinien) i z "1" wychodziło 256 + "jakiś
przypadkowy ogon".
Zauważyłem też, że printf_small() (a może też printf() ?) tak
skutecznie obcina początkowe zera, że dla "0" nic mu już nie zostaje.
Poniżej to, co kompilator zrobił z następującego kodu w C:
[...]
Nie będzie to pewnie dużym pocieszeniem, ale komercyjnym programom też
się zdarzają podobne pluskwy :-(
Zwykle pomaga rozbicie wzoru na etapy. Najczęściej nie wydłuża to
zbytnio (lub wcale) kodu i czasu wykonywania programu. Czasem nawet
skraca.
Przy okazji mam pytanko. Czy jest jakiś sprytny sposób efektywnego
"wyłuskania" pojedyńczego bajtu, np. z int-a? Chodzi np. o coś takiego
(typy zmiennych zgodne z ich nazwami):
char1 = int1 >> 8;
Kod z tego jest dość długaśny. W tej chwili robię to poprzez unię:
union uint_uchar
{
unsigned int i;
unsigned char b[2];
};
union uint_uchar x;
char_lo = x.b[0];
char_hi = x.b[1];
Próby podejścia tego na sposób, który stosuję w IAR'ze (tam jest zapis
Big Endian):
#define HI(i) (*(char*)&(i))
#define LO(i) (*((char*)&(i)+1))
char1 = LO(int1);
char2 = HI(int1);
dały wynik koszmarny. Kompilator nie próbuje tu sam wyliczać adresów
(które są w tym przypadku stałe) lecz zostawia to programowi. A ten
korzysta z tasiemcowych procedur "wzkaźnikowych"...
BTW, znalazłem symulator do '51 _działający_ (sprawdzone!) na poziomie
kodu C, darmowy: http://home.t-online.de/home/Jens.Altmann/jsim-e.htm
Piszę o tym również w osobnym wątku bo może będzie więcej
zainteresowanych.
gr
From: "Tomasz Gumny" <anwoz_at_nospam_alpha.net.pl>
Subject: Re: SDCC- bojów ciąg dalszy.
Date: Mon, 26 Feb 2001 01:03:18 +0100
Przy okazji mam pytanko. Czy jest jakiś sprytny sposób efektywnego
"wyłuskania" pojedyńczego bajtu, np. z int-a? Chodzi np. o coś takiego
(typy zmiennych zgodne z ich nazwami):
char1 = int1 >> 8;
Kod z tego jest dość długaśny. W tej chwili robię to poprzez unię:
union uint_uchar
{
unsigned int i;
unsigned char b[2];
};
I to jest chyba najprostszy sposob, chociaz uzalezniony
w pewnym stopniu od tego jak kompilator uklada dane.
Ja uzywam:
union
{
unsigned int i;
struct { char highbyte, lowbyte; } s;
} x;
TG
From: Marcin Wolcendorf <wolcendo_at_nospam_free.polbox.pl>
Subject: Re: SDCC- =?iso-8859-2?Q?boj=F3w=20ci=B1g?= dalszy.
Date: Mon, 26 Feb 2001 06:30:42 +0100
Witam,
Tak jeszcze tytułem wstępu- jeśli pole bitowe struktury kończy się w
pełnym bajcie, to kompilator zajmie dla struktury o jeden bajt za dużo.
Najwyraźniej źle wykonuje obliczenia wielkości i dla 8 bitów wychodzą mu 2
bajty...
Grzegorz Redlarski wrote:
Kompilator C do DSP Motoroli, również GNU (choć źródeł do niego próżno
szukać w Inernecie), też najwięcej głupot robił przy longach, głównie
przy konwersji typów.
Czyżby wspólny przodek???
W sdcc też jest chyba coś nie tak z konwersjami.
Czasami unsigned traktuje jak signed ze wszystkimi skutkami konwersji.
Mnie to nie boli o tyle, że wiem, że zmienne, których używam i tak nie
zostaną potraktowane jako ujemne. Ale oczywiście skutkuje to dłuższym
kodem.
Jak znajdę trochę
czasu by dokładniej sprawę wybadać to dam znać. Chyba chodziło o stałe
występujące jako argumenty funkcji - liczby < 256 źle konwertował na
int (zgodnie z ANSI powinien) i z "1" wychodziło 256 + "jakiś
przypadkowy ogon".
Chętnie się zapoznam.
Zauważyłem też, że printf_small() (a może też printf() ?) tak
skutecznie obcina początkowe zera, że dla "0" nic mu już nie zostaje.
Hmmm... Żeby tak obcinał zmienne tymczasowe...
Nie używam biblioteki zawierającej printfa. Strasznie rozdyma kod, a
mnie uniwersalność printfa do niczego się nie przydaje. Tym bardziej, że
mam swoje własne putc() i prnhex(), co mi absolutnie wystarcza :-). No i
wiem, ile dodatkowych zmiennych jest używają moje funkcje...
Poniżej to, co kompilator zrobił z następującego kodu w C:
[...]
Nie będzie to pewnie dużym pocieszeniem, ale komercyjnym programom też
się zdarzają podobne pluskwy :-(
Wiem, wiem.
Zwykle pomaga rozbicie wzoru na etapy. Najczęściej nie wydłuża to
zbytnio (lub wcale) kodu i czasu wykonywania programu. Czasem nawet
skraca.
Tu nie skróci. Kompilator powoła kolejnych kilka zmiennych
tymczasowych, których nie potrafi nakładkować- szczytem są sekwencje, w
których najpierw rejestr wkłada do zmiennej typu long- rozszerzając chara
do longa, po czym najmłodszy bajt wkłada do następnej zmiennej po czym
wkłada zawartość tej zmiennej z powrotem do rejestru (tego samego, z
którego przed chwilą ją wyjął!) i nigdy więcej tych zmiennych nie używa...
5 bajtów wyrzuconych na śmietnik i kupa niepotrzebnych operacji- co o tyle
jest wkurzające, że kompilator ma 'optymalizację' i co kilka linijek pisze
w asmie 'removed redundant mov'. Jeden mov! A obok tak z 10
niepotrzebnych.
O RPN też twórcy SDCC nie słyszeli... Rozwijanie wyrażeń
arytmetycznych jest tragiczne- zwłaszcza sekwencji zmieniających bazę
systemu liczbowego. Co prawda można, zmieniając kod w C, to (zapewne)
poprawić, ale... To właśnie jest robota dla kompilatora!
W rezultacie i tak piszę w asmie, bo 40 zmiennych użytych ot tak
sobie- po nic, powoduje, że mi zasobów nie starcza. BTW- bo 'dotknięciu'
ręką z tych 40. zmiennych została jedna. Tylko dlatego, że jeszcze nie
wiem, co z nią się dzieje (jej usunięcie nie sprowadza się do skasowania
kilku linijek) i jak ją usunąć, a wyraźnie można to zrobić.
Przy okazji mam pytanko. Czy jest jakiś sprytny sposób efektywnego
"wyłuskania" pojedyńczego bajtu, np. z int-a? Chodzi np. o coś takiego
(typy zmiennych zgodne z ich nazwami):
char1 = int1 >> 8;
Kod z tego jest dość długaśny.
Akurat to w SDCC jest z sensem- po prostu bierze odpowiedni bajt
zmiennej. (oczywiście pomijam, że przy okazji zużywa 10 bajtów RAMu
dodatkowo, więc pewnie lepiej by było trzymać w 3 zmiennych)...
W tej chwili robię to poprzez unię:
Albo w unii :-).
union uint_uchar
{
unsigned int i;
unsigned char b[2];
};
To przecież bardzo dobra metoda. Może tylko trochę zaciemnia kod.
Próby podejścia tego na sposób, który stosuję w IAR'ze (tam jest zapis
Big Endian):
#define HI(i) (*(char*)&(i))
#define LO(i) (*((char*)&(i)+1))
char1 = LO(int1);
char2 = HI(int1);
dały wynik koszmarny. Kompilator nie próbuje tu sam wyliczać adresów
(które są w tym przypadku stałe) lecz zostawia to programowi. A ten
korzysta z tasiemcowych procedur "wzkaźnikowych"...
... Brak optymalizacji.
BTW, znalazłem symulator do '51 _działający_ (sprawdzone!) na poziomie
kodu C, darmowy: http://home.t-online.de/home/Jens.Altmann/jsim-e.htm
Dzięki za info :-).
Pozdrawiam,
Marcin.
--
'My experience is that it is hard to find software producers that aren't
fuzzy.'
From: JK <Janusz_k_at_nospam_um.bielsko.pl>
Subject: Re: SDCC- =?iso-8859-2?Q?boj=F3w=20ci=B1g?= dalszy.
Date: Mon, 26 Feb 2001 09:08:54 +0100
Hej Grupie
Tak czytam tš waszš dyskusję i przypominajš Mi się joby i gromy pod adresem
Bascoma jak kiedyś była dyskusja na jego temat, ale wielokrotnie juz
sprawdzałem
że przydzielanie pamięci, praca na zmiennych jest prawie wzorowa, tak że
koledzy niedoceniany przez Was BAscom oferuje łatwy i przejrzysty język a
jednocześnie ma efektywnš generację kodu
i bardzo dobre zarzšdzanie pamięciš i zmiennymi :))))
Pozdrowienia
Janusz K
From: Marcin Wolcendorf <wolcendo_at_nospam_free.polbox.pl>
Subject: Re: SDCC- =?iso-8859-2?Q?boj=F3w=20ci=B1g?= dalszy.
Date: Mon, 26 Feb 2001 09:53:24 +0100
Witam,
JK wrote:
Tak czytam tš waszš dyskusję i przypominajš Mi się joby i gromy pod adresem
Bascoma jak kiedyś była dyskusja na jego temat, ale wielokrotnie juz
sprawdzałem
że przydzielanie pamięci, praca na zmiennych jest prawie wzorowa, tak że
koledzy niedoceniany przez Was BAscom oferuje łatwy i przejrzysty język a
jednocześnie ma efektywnš generację kodu
i bardzo dobre zarzšdzanie pamięciš i zmiennymi :))))
1) czy jest za darmo?
2) a jak w nim zrobisz unię, albo będziesz tę samą zmienną
widział/traktował raz jako znak, a raz jako pole bitowe albo float-a,
albo
jeszcze co innego? (właśnie teraz tak mam- mam rekord o ustalonej
długości,
który ma w swej strukturze pola o różnych długościach a ma być
transmitowany na zewnątrz jako ciąg bajtów)
3) co z procedurami z dużymi wymaganiami czasowymi?
4) co z wywoływaniem procedury/funkcji przez nią samą?
Wszystko ma swoje zady i walety. To, o czym piszemy, to są błędy w
implementacji/błędy przy tworzeniu kompilatora.
Jeszcze jedna uwaga- algorytm napisany w C można przenieść bez
większych kłopotów (jeli się wie, co się robi :-) ) na inną platformę (a
łatwiej jest zmienić sprzęt, niż napisać od nowa oprogramowanie). Na ilu
platformach masz Bascoma?
Pozdrawiam,
Marcin.
PS. A ja to piszę tylko po to, żeby innym ew. oszczędzić szukania. Bo
tak w zasadzie mógłbym siedzieć cicho i niech się inni martwią :-).
M.
--
'My experience is that it is hard to find software producers that aren't
fuzzy.'
From: Milosz Skowyra <mewash_at_nospam_bet.po.opole.pl>
Subject: Re: SDCC- =?iso-8859-2?Q?boj=F3w=20ci=B1g?= dalszy.
Date: Mon, 26 Feb 2001 17:18:55 +0100
JK wrote:
[...]
że przydzielanie pamięci, praca na zmiennych jest prawie wzorowa, tak że
koledzy niedoceniany przez Was BAscom oferuje łatwy i przejrzysty język a
jednocześnie ma efektywną generację kodu
Buahahahaha... chyba nie wiesz o czym piszesz...
Od kiedy zabranie ~1.2kB programu na obsluge LCD i I2C mozna nazwac
efektywna generacja kodu. Od kiedy napisanie 10 prostych instrukcji w
BASICU musi zajmowac 100kB kodu ?
Wybacz ale poswiecilem dlugie godziny na podgladanie kodu generowanego
przez kompilator BASCOM-a i o ile moge sie zgodzic na calkiem dobre
zarzadzanie zmiennymi to tekst o efektywnej generacji kodu przemilcze...
a raczej przesmieje...
i bardzo dobre zarządzanie pamięcią i zmiennymi :))))
Spokojnie... poczekaj z tym do prima-aprilis.
--
Regards.
|-----------------------------------------------------|
| Milosz Skowyra |
| miloszek_at_nospam_fidonet.org.pl 2:484/2.47 on fidonet |
| GSM Mobile +48608888899 |
|-----------------------------------------------------|
Proscie, a bedziecie prosci.
From: "Martin" <ANTISPAMnitram_at_nospam_pro1.promail.pl>
Subject: Re: SDCC- bojów ciąg dalszy.
Date: Tue, 27 Feb 2001 00:05:55 +0100
Użytkownik "Milosz Skowyra" <mewash_at_nospam_bet.po.opole.pl> napisał w wiadomości
...
JK wrote:
Od kiedy zabranie ~1.2kB programu na obsluge LCD i I2C mozna nazwac
efektywna generacja kodu. Od kiedy napisanie 10 prostych instrukcji w
BASICU musi zajmowac 100kB kodu ?
No offence, ale chyba masz jakas prehistoryczna wersje kompilatora...
Pewnie, ze nie jest idealnie, ale nie wszyscy maja pieniadze na Keil'a lub
czas na nauke asm i wypracowanie wlasnych procedur...
Wg mnie do zastosowan domowo-nieprofesjonalnych w zupelnosci wystarczy...
--
Pozdrawiam
Marcin Łagonda [ martin_at_nospam_rockmetal.art.pl ]
[ http://quovadis.rockmetal.art.pl ]
[ http://we.tuniv.szczecin.pl/~ue ]
[ http://we.tuniv.szczecin.pl/~semi ]
From: Milosz Skowyra <mewash_at_nospam_bet.po.opole.pl>
Subject: Re: SDCC- =?iso-8859-2?Q?boj=F3w=20ci=B1g?= dalszy.
Date: Wed, 28 Feb 2001 20:11:57 +0100
Martin wrote:
No offence, ale chyba masz jakas prehistoryczna wersje kompilatora...
1.2 afair, zreszta i tak nie wazne, jedyne czego uzywam w bascomie to
edytor znakow do lcd, do tego nadaje sie najlepiej...
Pewnie, ze nie jest idealnie, ale nie wszyscy maja pieniadze na Keil'a lub
czas na nauke asm i wypracowanie wlasnych procedur...
Hehe... wg. mnie marnotrawstwem czasu jest pisanie w BASCOM-ie. Poza tym
masz freeware-owe kompilatory C. Nawet kiedys paletal sie po sieci
kompilator Pascala na '51 ale nie moglem go dopasc, wiec i nie
analizowalem jak dziala. Podejrzewam jednak ze nie rozni sie zbyt wiele
od bascom-a.
Suma sumarum predzej czy pozniej dojdziesz do tego ze nie da sie obyc
bez asm-a, tym bardziej jak masz do napisania kawalek kodu ktory jest
krytyczny czasowo i ktorego nawet w Keilu nie da sie optymalnie napisac.
Nie twierdze ze jedynym slusznym jezykiem jest asm czy C, ale wybacz
basic to zabawka, na dodatek odkad pamietam to nigdy nie bylo specjalnie
dobrego kompilatora basica na dowolna platforme... ze juz nie wspomne
BASIC STAMP-a.
Wg mnie do zastosowan domowo-nieprofesjonalnych w zupelnosci wystarczy...
No wlasnie, wystarczy ale dla kogo...? Jezeli chcesz mrugac diodka to
mozesz sobie uzyc dowolnego kompilatora i tak to nie bedzie mialo
znaczenia.
Moge ci zaproponowac napisanie w bascomie programu do procesora
zarzadzajacego moim pokoikiem, 89C2051+LCD+16klawiszy+2KB
EEPROM+termometr I2C+sterowanie 6 triakami.
Do tego 3 poziomowe menu, komunikacja z PC, zegarek, kalendarz,
automatyczne wykrywanie pory dnia i odpowiednie sterowanie oswietleniem.
Jak sie zmiescisz w tych 2048 bajtach piszac w BASICU i BASCOMI-e to
zafunduje ci podroz na Karaiby. Oczywiscie zawsze mozna wziac 4021 ale
po co, skoro 2051 wala mi sie kilkanascie sztuk...
Tu nie chodzi o to co lepsze, tylko o kompromis pomiedzy czasem a
wydajnoscia. Jezeli chcesz na wyswietlaczu wyswietlic Hello world to
moze i prosciej jest napisac to w bascomie, ale przy odpowiednim zbiorze
bibliotek rownie prosto zrobisz to w asmie przy tym samym nakladzie
pracy. Ale jezeli dodatkowo ma to dzialac wydajnie i zajmowac malo
miejsca to niestety pozostaje kombinacja.
--
Regards.
|-----------------------------------------------------|
| Milosz Skowyra |
| miloszek_at_nospam_fidonet.org.pl 2:484/2.47 on fidonet |
| GSM Mobile +48608888899 |
|-----------------------------------------------------|
Niech bedzie tani i dobry......DENATURAT ZOLADKOWY...