Różnice w zachowaniu zmiennych globalnych w AVR-GCC: extern vs static w przerwaniach

Sun Jul 03, 2005 6:54 pm   

Sebastian Bialy wrote:


A co jest złego w klasach, jeśli nie używa się funkcji wirtualnych
i typowania dynamicznego? Przecież one się kompilują w _dokładnie_
taki sam sposób, jak struktury w C, a na poziomie języka dają kilka
dodatkowych możliwości: dziedziczenie implementacji, szczegółowa
kontrola dostępu do składowych itd.


Szczerze mówiąc to dość osobliwa definicja. Dla mnie pisanie
w C++ polega na używaniu mechanizmów C++ -- a tutaj użycie
klas i szablonów nie różni się niczym od tego, czego używa się na
64-bitowcu. Natomiast jeśli chodzi o STL, to go oczywiście na
"maluchach" nie używam, ale nie ma przecież takiego obowiązku.
Nawet standard języka wspomina na ten temat, wyróżniając
środowiska hosted i freestanding.


Nie zawsze, kwestia przemyślenia struktury programu. Natomiast oddalenie
się od maszyny wbrew pozorom bywa pomocne, bo dzięki temu środowiska
uruchomieniowe mogą stosować takie transformacje kodu (zwłaszcza
dynamiczne!), o których sobie w C++ można pomarzyć. Widziałem juz
benchmarki, w których kod w Javie pobił wydajnością program w C++
-- wszystko dzięki optymalizacjom dynamicznym. Nawet mnie to kiedyś
dość mocno interesowało, ale później zmieniłem kurs na specyfikowanie
rozmaitych systemów i ich weryfikację.


Tylko żeby wówczas komuś nie urwało ręki na ten przykład...


Ja również, ale staram się nie przykładać jednej miarki do rozwiązań
służących do zupełnie różnych celów. Są rzeczy, gdzie C++ pozwoli
w doskonały sposób rozwiązać problem, a są i takie, gdzie to będzie
horrorem, natomiast inne narzędzie pozwoli na wygodne zapisanie
rozwiązania. Przyroda jest przebogata i należy z tego korzystać, a
nie ograniczać się do jednego rozwiązania jednego sposobu myślenia.
Liczba istniejących języków programowania jest dowodem, że nie
istnieje coś takiego, jak najlepszy język. Są tylko mniej lub bardziej
dobre do rozwiązywania problemów ze ściśle określonej dziedziny.
Jeśli tą dziedziną jest programowanie niskopoziomowe, to C jest
dobre, a C++ bardzo dobre, więc trochę dziwi mnie, że podchodzisz
do tego ostatniego jak do jeża -- mity o rzekomej złożoności kodu
wynikowego wyprodukowanego przez kompilator C++ skutecznie
rozwiewa zapoznanie się z listingami disasemblera. Wiele kompilatorów
(w tym GCC) ma wspólny optymalizator i generator kodu dla wielu
języków programowania -- w takich przypadkach to nie są nawet
mity, ale zwyczajne bzdury.



Wprost z ust mi to wyjąłeś. ;-P


Zgoda, ale to się robi podczas projektowania programu, a nie jego
implementowania (choć oczywiście te dwie fazy mogą się ze sobą
przeplatać). Gdyby taki przemyślany program zapisać w Bascomie,
to również doskonale zadziała. Programowanie w C albo czymkolwiek
innym żadnej nowej jakości nie dodaje.

Z resztą się zgadzam.

Pozdrawiam
Piotr Wyderski

Sun Jul 03, 2005 8:35 pm   

Piotr Wyderski wrote:

Ależ o te własnie wirtualne chodzi Co mi po klasach, które nie dają w
zasadzie nic ciekawego do kodu poza pewnym porzadkowaniem metod+danych.
Z resztą co do klas - troche głupio ich uzywać nie mając pod ręką
operatorów new/delete, wyjątków czy poprawionych includów (mówie teraz o
AVR-GCC). Na razie AVR-GCC nie jest dobrym pomysłem do pisania w C++.

Choć już za chwile, juz za momencik zamierzam zawalczyć z ARM i
rozpasanymi przestrzeniami RAM rzędu 128kB :)


Akurat Java i C++ to żadne różnica, prawie identyczny zapis, prawie
identyczne zastosowanie (poza przenośnym kodem wynikowym). Dla
programisty tak samo się pisze w obydwu. Z resztą teraz mam troche
dłubania w Javie (OpenGL) i jestem pod wrażeniem, że w zasadzie chodzi
tak samo jak kod natywny (jest fajna wersja QuakeII pod Javę .

Jednak ponieważ rozmawiamy o uC w końcu, to dalej nie wiem, czy jest
sens stosowania języków _za wysokiego_ poziomu do uC. Tam często trzeba
dlubac po rejestracj/pamięci albo liczyć cykle czy stosować sztuczki
przedziwne żeby zmniejszyć ilość instrukcji asm. Chyba nie ma chwilowo
nic lepszego niż C do pisania programów na uC. Mam na mysli jakies
większe projekty, a nie miganie diodą w BASCOMIE w delach dydaktycznych.
Oczywiście BASCOM rulez ale czy ktoś napisal w nim obsługe FAT na MMC
czy jakiś algorytm szyfrujący ?


No bez przesady takie błędy też można znaleźć w sofcie każdym. Z
resztą jakoś ludzie piszą w C aplikacjie bardzo powazne i nie ma kłopotu :)


Jestem ciekawy co wypluje gcc po kompilaci kodu z obiektami i metodami
wirtualnymi Trzeba będzie się poświęcić dla sztuki i pobawić
obiektami na ATTiny ... Swoją drogą od dawna pisze obiektowo i czuje się
troche jak bez ręki przy dłubaniu w czystym C ...


Jasne, że każdy problem można zapisać równie dobrze w każdym języku,
jednak nie w każdym optymalnie i nie w każdym jest baza gotowych
rozwiązań. Z resztą BASCOM chyba nie powstał po to, aby pisać w nim
wielkie projekty na uC, widać to po składni.


A to ja już nic nie pisze wobec tego w tej odnodze. EOT Pozdrawiam.

--
Sebastian Bialy - heby@poczta.onet.pl

Sun Jul 03, 2005 10:42 pm   

On Sun, 03 Jul 2005 18:41:13 +0200, Sebastian Bialy wrote:

Niemozliwe - 'SIGNAL' nie jest wbudowane w kompilator.
Przynajmniej w wersji 20050214.
Bez io.h masz nawet niezdefiniowane nazwy przerwan - to gdzie ma
wstawic wektor ?


Jest to mozliwe. Ale nie powinno miec wiekszego wplywu na dzialanie.

J.

Mon Jul 04, 2005 1:15 pm   

On Sun, 03 Jul 2005 23:35:09 +0200, Sebastian Bialy wrote:

No - trzeba przyznac ze Piotr swego czasu podal kilka rzeczowych
argumentow, ktore imho nie mialy wiekszego znaczenia praktycznego ..
ale chyba wlasnie sie na dwa z nich nadziales ))

J.

Mon Jul 04, 2005 1:15 pm   

On Sun, 03 Jul 2005 20:49:55 +0200, Wojtek Kaniewski wrote:

Nie bardzo - nie zrozumiales dokladnie o co chodzi.
a) wpisujemy w zrodlo czestotliwosc kwarcu, w #define
b) kompilator na jej podstawie sam wylicza potrzebne wartosci
c) w zaleznosci od tego co wyjdzie uzywa w kodzie arytmetyki
typu int lub long.

Tymczasem u ciebie:
0) i tak nie wyliczysz tej wartosci, bo to ponad mozliwosci
preprocesora C.
1) nie zadeklarujesz potrzebnych zmiennych roznych typow w zaleznosci
od wynikow obliczen.
2) o ile zadziala to na zmiennych, to na stalych nie.
sizeof(1000*500) wynosi .. 2

J.

Mon Jul 04, 2005 1:29 pm   

J.F. wrote:


W C++ to proste do zrobienia, jeśli się zna pare sztuczek z szablonami.
Natomiast w C nie da się czegoś takiego uzyskać. No cóż, ale jeśli ktoś
sobie sam nakłada kaganiec, a później narzeka, że nie może gryźć, to
już jego problem... :-)

Pozdrawiam
Piotr Wyderski

Mon Jul 04, 2005 1:40 pm   

Piotr Wyderski wrote:

No ładnie :/ Chyba musze jednak poćwiczyc c++ na AVRach ... skoro tak
namiawiasz strasznie :)

--
Sebastian Bialy - heby@poczta.onet.pl

Mon Jul 04, 2005 2:07 pm   

Sebastian Bialy wrote:


Szczerze mówiąc to nie widzę większej potrzeby intensywnego
używania metod wirtualnych na mikrokontrolerach. A jesli jednak
ich trzeba, to też dużo nie kosztują: jeden dodatkowy wskaźnik
w klasie, a w kodzie to jedna dereferencja i jeden skok pośredni.
Problemy ze złożonością pojawiają się, gdy korzysta się z metod
wirtualnych w hierarchii klas z dziedziczeniem wielobazowym, ale
tego rzadko kiedy potrzeba na "prawdziwych" komputerach.


Właśnie o to porządkowanie chodzi, żebyś się w większym
projekcie nie zabił zaplątując we własne spodnie. ;-)


A dlaczego na mikrokontrolerze masz ich nie mieć? Są za darmo.
Oprócz tego masz idiom "placement new", na mikrokontrolerach
również bardzo przydatny i zupełnie darmowy.


Wyjątki są za drogie w obsłudze, maluchy mają za mało RAMu na stos.
Każdy znany mi kompilator pozwala wyłączyć ich obsługę.


A co Ty chcesz inkludować na mikrokontrolerze, gdzie
wszystko jest wysoce niestandardowe? :-)


Jest bardzo dobrym pomysłem, tylko przed pisaniem trzeba
skończyć z wiarą w mity. ;-)


Szablony w Javie działają na zupełne innej zasadzie niż w C++ -- tam
nie tylko składnia, ale cała filozofia za nimi stojąca jest zupełnie inna.


Oprócz wspomnianych już szablonów w C++ masz dziedziczenie
wielobazowe, dziedziczenie wirtualne, zupełnie inne zasady wiązania
nazwy obiektu z obiektem (m.in. lookup Koeniga -- to chyba jedyny
język, który implementuję ten wynalazek) i przestrzenie nazw. W C++
się pisze zupełnie inaczej niż w Javie, no chyba, że ktoś zna C++
na poziomie "C z klasami" i w takim zakresie go używa -- wówczas
zgoda, ale czuję się w obowiązku donieść, że to zaledwie ułamek
dostępnych możliwości i daje się zapisać w tym języku takie cuda,
że mało kto zdaje sobie sprawę, że to w ogóle możliwe. Ot, choćby
takie sprawdzanie w czasie kompilacji hierarchii dziedziczenia za
pomocą bardzo pokrętnie skonstruowanego szablonu i niecodziennego
wykorzystania operatora sizeof. Majstersztyk.


Jeśli oferowane przez nie możliwości przekładają się w łatwy sposób
na kod wynikowy, to oczywiście, że tak. W C++ większość nowych
możliwości jest dostępna zupełnie za darmo.


To jest nieosiągalne nawet w C, potrzeba wstawki asemblerowej.
A to się robi równie łatwo w C++.


C++ nie różni się pod tym względem od C.


Do tego też trzeba wstawki asemblerowej.


Będzie ich tyle samo w C++, co w C.


Jest, C++.


A niby czemu miałoby się nie dać, i to nawet wydajnie? Znowu jakieś mity.
;-)


Nie przesadzam, w różnych miejscach takie programy są stosowane.
W jednym program się zawiesi i będzie odtwarzał tę samą piosenkę,
w innym bank straci kilkadziesiąt tysięcy dolarów, a w jeszcze innym
trzeba się będzie zastanawiać, co zrobić z denatem...



Są kłopoty, czasami w postaci ofiar śmiertelnych i kalek.


Więc je wywal i przejdź na jego następcę, w czym -- oprócz
mitów -- widzisz problem?


Nie, nie równie dobrze. W jednych lepiej, w innych gorzej i dlatego
jest ich tyle.


A jak definiujesz kryterium optymalności i w jaki sposób chcesz
sprawdzać jego spełnialność? Chyba nadużywasz tego słowa. ;-)


Szkoda.

Pozdrawiam
Piotr Wyderski

Mon Jul 04, 2005 2:43 pm   

J.F. napisał(a):

to może coś takiego?

#define F_CPU 10000000L
#define CYCLES F_CPU/100

#if CYCLES > 65535
#warning "unsigned long"
unsigned long cnt;
#else
#warning "unsigned short"
unsigned short cnt;
#endif

int main(void)
{
return 0;
}

taki kod zadeklaruje unsigned long, bo cykli mamy 100000. jeśli zmienisz
stałą F_CPU na 5000000, zadeklaruje unsigned short. o to chodziło?


preprocesor gcc nie poradzi sobie ze stałymi zmiennnoprzecinkowymi, ale
większość rzeczy można policzyć na stałoprzecinkowych przy odpowiednim
przesunięciu wartości.


kod wyżej radzi sobie ze stałymi.

zaznaczam, że cały czas mowa o gcc. inne kompilatory faktycznie mogą
ignorować obliczenia w preprocesorze i zrzucać je na kompilator, ale nie
wiem czy to rozszerzenie gcc czy nowość w C99.

w.

Mon Jul 04, 2005 2:54 pm   

Wojtek Kaniewski wrote:


Na przykład najmniejszą wspólną wielokrotność? :-)

Pozdrawiam
Piotr Wyderski

Mon Jul 04, 2005 3:16 pm   

Piotr Wyderski wrote:

[Soko nie chcesz EOT ...]


Widzisz, mamy zupełnie inne podejście do programowania obiektowego - w
moim przypadku, kiedy już decyduje się na C++ to zycze sobie PEŁNEGO c++
włacznie z STL, metodami wirtualnymi, wyjątkami i cała masą innych
fajnych rzeczy. Jesli natomiast za pomocą kompilatora C++ składam proste
programy to nie uważam tego za pisanie w C++ a jedyne za używanie
kompilatora C++.

Chyba się tutaj nie zgodzimy, bo to po prostu nasze indywidualne zdania
na temat "definicji C++".


Owszem, dlatego tak bardzo cenie C++, jednak z drugiej strony: co to
znaczy większy projekt ? Jesteś ograniczony dostępnym ram/rom w uC i w
zasadzie kazdy większy projekt na taki uC da się objąć i zapanowac nad
nim. Co innego pisanie duzych aplikacji na peceta. Po prostu ilośc kodu
jaki można wrzucić do przeciętnego AVRa nie jest moim zdaniem "dużym"
projektem. Fakt - C++ ładnie pozwala odciązyć programistę od myślenia o
róznych pierdołach, ale z drugiej strony pisząc na 90S2313 w zasadzie
jesteś w stanie zapamiętać wszystkie zmienne jakie używasz i w jakim
pliku ;)

To nie znaczy że nie należy pisać w C++ na uC - tylko że imho argument
komplikacji jest tu troche nie w tej skali.


Zwróć uwagę na masę kłopotów, które się "robią same" takie jak tworzenie
tymczasowych obiektów przy arytmetyce przeciążonych operatorów (które
tak lubie stosować , konstruktory kopiujące (często niepotrzebne) i
tym podobne rzeczy, których IMHO kompilator raczej nie zoptymalizuje
(może się mylę ?). Przy <1kB pamięci RAM może się okazać, że stworzenie
tymczasowego obiektu w RAM jest niewykonalne. Można powiedziec, że o ile
C++ ułatwia pewne rzeczy składniowo, to czasami potrafi wygenerować kod
nadmiarowy wynikający z samej definicji obiektu przez programistę.


Szkoda Czyli "-" dla C++ ? :)


Jesli poczytasz helpa do WinAVR to dowiesz się, że w ostatniej wersji
jaką dałem radę ściągnąć częśc plików jest "not C++ safe" a konkretnie
nie mają 'extern "C"'. Czyli raczej nie da się korzystać swobodnie (choć
mam nadzieje, to nie będzie wiele dla twórców poprawić).


I ostro zacisnąć pasa w tym C++ :)


Oj, wiadomo że kazdy język ma spore róznice, ale chodzi o to, że
większośc programistów Java jest w stanie pisać w C++ i na odwrót. To są
języki _BARDZO_ podobne, że wręcz wspomne o samej składni, która jest
prawie identyczna. A to że są szczegóły rózne (brak destruktorów w Javie
mnie dobił, choć rozumiem dlaczego ich nie ma) to wiadomo. Co do
filozofi to nie wiem czy mówisz o całym jezyku czy tylko o jego częsci,
ale dla mnie nie było zadnych kłopotów w pare dni przegryźć się przez
róznice Java-C++ i pisac programy w Javie, więc filozofia nie jest aż
taka rózna. Acz daleko mi do miana programisty javy.


Jakie ma znaczenie majsteresztyk, skoro można badać typy/rzutować z
użyciem mechanizmów w C++ ? Tzn jestem wrogiem sztuczek
programistycznych, bo to zamiast ułatwiać zycie - zaciemnia tak, że
komuś rękę urwie kiedyś :P

Co do przestrzeni nazw - ile to programów w C wyrosło bez tego "bajeru"
i jakoś nikt specjelnie nie płakał... Fajno ze jest ale można się było
obejść bez. To troche tak, że brak "for" byłby bolesny, ale brak
"namespace" jakoś nie spowodował zastoju C (dalej jajko linuxa w nim
skrobią, choć istniało by wiele lepszych języków).


Hmmm ok. Zakładam, że teoretycznie masz rację. Jednak jestem przekonany
że przeciętny dobry programista C++ na dużych pecetach wybije sobie zęby
od razu o mały RAM/mały stos w uC. Pisanie na uC jednak rózni się od
pisania na duże komputery. Dużo zależy od umiejśtności programisty,
jednak jesli wykastrujemy C++ z STL, wyjątków i paru innych duperelek to
okaże się, że w zasadzie pozostał C + troche "bajerów składniowych" typu
szablony. To dla mnie nie C++ (ale to wyjasniłem, że to kwestia definicji).


Hmmm moment, nie chodzi mi o rejestry uC tylko o rejestry specjalne, z
resztą chodziło mi o języki odległe od sprzętu a nie o C++ który
oczywiście jest "lepszym C" choć zdaje sobie sprawę, że wiele osób mogło
by mnie zamordować za to stwierdzenie :)


J/w.


Łomatko No dobra, C++ wykastrowany, robocza nazwa "1/2C++" może byc ? :)


Heh, no ja się nie podejmuje, chyba że dobrze zapłacisz A
potrzebujesz FAT w BASCOMIE ? Cos mi się zdaje że BASCOM nie powstał
do takich zastosowań (co nie zienia faktum że można).


Dziwnym trafem nie przeszkadzają te negatywne doświadczenia na całym
swiecie stosować windowsa do obsługi szaf muzycznych (zaliczyłem już 4
sztuki wesoło zawieszone na niebieskim ekranie), bankomatów ze znakiem
zachęty C:> na ekranie (przoduje tu PKO, 2 trafienia) tudzież
informatorów turystycznych nie mogących znaleźć pliku "xxxx.dll" (chyba
wszystkie jakie widziałem miały jakiś mankament typu "programista dał
dupy"). Jakoś nikt się nie przejmuje stabilnoscią bankomatu, bo
przeciętny klient jest mało znaczacy. Co do aparatury medycznej - mysle
że zakładając odpowiedni poziom kontroli - kazdy jezyk nalezy
gruntownie przetestowac, a im wyżej się wspinasz w łatwości
programowania, tym mniej rzeczy zalezy od programisty a więcej od
dostawcy bibliotek/kompilatora/etc. Ciekawe czy takie aplikacje dla .NET
na ten przykład można stosować w medycynie ? W sumie ja bym nie zaufał
tym gotowcom z MS.


Podobnie jak piszących w C++/BASCOMie/whatever, ale nie mam statystyk
więc nie mam odwagi wyrokowac, czy więcej ...


We wszystkim o czym dyskutujemy, co praktycznie zawsze ma źródło w
"małej ilości RAMu" co wymusza kastrację.


"Równie dobrze" w tym przypadku oznaczało, że można napisac każdy
program w kazdym języku, ale:


Optymalnie: szybki kod, mało zajetości RAMu (w szczególności na pierdoły
typu obiekty tymczasowe), zwarty kod. Każdemu przypisuje wage w
zalezności od projektu i tak pisze, aby zoptymalizowac funkcję celu .
W C/C++ mam pod kontrolą bardzo wiele elementów. W wyższych językach
coraz mniej. Dlatego w przypadku uC raczej nie chce pisać w BASCOMie, bo
mam mniejszy wpływ na generowany przez niego kod.


No dobra, ale się rozpisujemy, ja proponuje powoli kończyć, choć z
przyjemnością sie dyskutuje.

--
Sebastian Bialy - heby@poczta.onet.pl

Mon Jul 04, 2005 3:24 pm   

Piotr Wyderski napisał(a):

teraz to już szukasz dziury w całym (;

a na poważnie, to jak na podstawie wyniku czegoś w stylu
boost::math::static_lcm<x,y> zadeklarować zmienną? czy może trzeba
własne szablony tworzyć?

w.

Mon Jul 04, 2005 4:00 pm   

Wojtek Kaniewski wrote:


Nie, pokazuję tylko, że nie da się w ten sposób zapisać nawet
najprostszej rekurencyjnej zależności, bo w preprocesorze rekursji
nie ma. W obliczeniach za pomocą szablonów jest.


Tj. jak wybrać typ zmiennej? Na przykład tak (rozwiązanie ogólne):

template <bool, typename T, typename F> struct select_type {
typedef T type; };
template <typename T, typename F> struct select_type<false,T,F> {
typedef F type; };

I użycie:

select_type<(2*2 == 4), char, double>::type zmienna;

Oczywiście warunek może być dowolnie bardziej skomplikowany, być
wyznaczany przez zależność rekurencyjną itd. -- ogranicza fantazja.

Na podobnej zasadzie (tj. za pomocą częściowej specjalizacji szablonu)
można sobie zrobić odpowiednik instrukcji case (zamiast if), jeśli komuś
jest potrzebna -- tylko parametryzacja powinna wówczas korzystać
z typu unsigned int, a nie bool.


Tak, ale -- jak widzisz -- bardzo proste i do tego uniwersalne. Ja
sobie dziesiątki tego typu rzeczy zamknąłem we własną biblioteczkę
i korzystam z niej od paru lat, od czasu do czasu dopisując do niej
coś wartego uwagi.

Pozdrawiam
Piotr Wyderski

Mon Jul 04, 2005 4:31 pm   

Piotr Wyderski napisał(a):

widzę, że pora zainwestować w jakąś sensowną książkę o C++. do tej pory
miałem nieszczęście przeglądać takie, które skupiały się na klasach, a o
szablonach wspominały po łebkach.

tak czy inaczej wielkie dzięki za wyjaśnienia.

w.

Mon Jul 04, 2005 5:03 pm   

Wojtek Kaniewski wrote:


Polecam Andrei Alexandrescu, "Modern C++ design".

http://www.amazon.com/exec/obidos/tg/sim-explorer/explore-items/-/0201704315
/0/101/1/none/purchase/ref%3Dpd%5Fsxp%5Fr0/103-0547055-5611007

I zapiąć pasy, bo jazda będzie ostra.

Pozdrawiam
Piotr Wyderski