On 2012-05-02 14:52, Andrzej Ekiert wrote:
>> Ja rozumiem to jako podejście w stylu boost::mpl.
> Ładne. Ale szczerze mówiąc to nie bardzo widzę, jaki problem to
> rozwiązuje w przypadku programowania naszego 8-bitowca z 1kB kodu.

Powiedzmy - dopasowanie typu [char|short] licznika w czasie kompilacji.
Policzenie jaki typ nalezy wybrać dla zbioru flag. Policzenie stalej w
czasie kompilacji. Kompilacja warunkowa bez #define. Itd.

> Sprytne i fajnie pokazuje, jak działa destruktor. Ale ja bym po prostu
> napisał:
> cli();
> ... kod krytyczny
> sei();

teraz:

cli()
....
return
...
goto
...
break
...
sei();

I już po tobie. A po mnie nie.

> Lepiej widać w jednym miejscu co się dzieje, bez szukania definicji
> klasy CriticalSection, bez zastanawiania się gdzie jej obiekt wychodzi z
> zasięgu

Nie zastanawiasz sie. Na pewno wszystkie miejsca działają poprawnie. na
tym polega sztuczka. Możesz oderwać się od assemblera i skupić na
algorytmie. nadmierne przejmowanie się szczegółami uniemozliwia pisanie
czytelnego kodu.

>, no i bez ryzyka, że osoba, która nie jest autorem kodu nie
> zauważy, że wsród paru zmiennych lokalnych jest jakiś dziwny pozornie
> nieużywany obiekt.

Jesli "pozornie nieuzywan obiekt" nazywa się SekcjaKrytyczna i on tego
nie zauważy, to pozostawienie w tym miejscu makra, sei, cli nic nie
pomoże - przecież pozornie jest nieużywane. Trudno, nie mówimy tutaj o
programistach basica oddelegowanych do poprawiania C++.

> Ja tam wolę widzieć przebieg programu, a nie musieć ciągle pamiętać, że
> między ostatnią instrukcją funkcji, a '}' uruchomi się jeszcze seria
> niewidzialnych funkcji.

A więc dobrze podejrzewałem - jesteś assemblerowcem. Musisz wiedzieć co
sie dzieje bo nie ufasz kompilatorom. Ja natomiast odwrotnie. Znajduje
zdcecydowanie wiecej bugów we własnym kodzie niż w wygenerowanym przez
kompilator.

> Zresztą, akurat w mojej praktyce programowania
> małych uC potrzeba nietrywialnej destrukcji "obiektu" zachodzi bardzo
> rzadko.

Mam to za darmo. Używam. PICowcy mogą tylko obejśc się smakiem albo
ciągnąć tasiemcowe wywody dlaczego im to nie potrzebne.

>> Moje marzenie to PIC w sensie peryferiów i AVR w sensie rdzenia. Ale
>> sie nie doczekalem bo przyszły ARMy i pozamiatały.
> Architektura 16-bit Microchipa (PIC24, dsPIC33) to właśnie coś takiego.

Co takiego? Ślepą uliczkę sprzętowego stosu? Brak wsparcia poza żalosnym
kompilatorem producenta? Nawt MC sie puknął w czolo i zakopał to cudo
głęboko pod ziemią żeby już nie straszyło. Tylko że ARM jest już za tani
i za dobry.

> Bardzo elegancko zaprojektowana, przyjemnie się z tym pracuje - moim
> zdaniem dużo ładniejsza niż MIPS, którego użyli w PIC32, oraz niż ARM.

Dla mnie nie ma różnicy. Nie pisuje w assemblerze dla niepoznaki nazwanym C.

>> No chyba, że architektura PICów nie da się wmontować w backed gcc.
> gcc zostało przeniesione na architektury 16 i 32 bit. Jeśli chodzi o te
> 32 bit (rdzeń MIPS) to spodziewam się, że prędzej czy później kompilator
> C++ się pojawi.

Jasne. http://www.microchip.com/forums/m544964.aspx

> Do 16-bit też pewnie mogliby to w miarę tanio zrobić -
> mi zupełnie jednak na tym nie zależy.

Słusznie. Nie ma targetu.

do góry

On 02/05/2012 00:28, Sebastian Biały wrote:
> On 2012-05-01 23:35, Andrzej Ekiert wrote:

> Destruktory to cecha która nie wymaga podejścia obiektowego do
> programowania. Najprościej:
>
> struct CriticalSection {
> CriticalSection{ cli(); }
> ~CriticalSection{ sei(); }
> };
>
> To żadne programowanie obiektowe. A destruktor przydatny.

Z tego by wynikalo ze 'ukryte' odblokowanie przerwan na koncu funkcji
(gdy destruktor zostanie wywolany przez kompilator) jest mniej
niebezpieczne niz nieodblokowanie przerwan w ogole? No to powodzenia w
debugowaniu kodu ktory ma 300kB bez OSa w celu znalezienia ktora funkcja
za pozno wlacza przerwania.

>> za to przez swoje "samoczynne" uruchamianie
>> się stanowią niezłą okazję do implementacji subtelnych bugów,
>> szczególnie u niezbyt doświadczonych programistów
>
> Odwrotnie: dzieki swojemu samoczynnemu dzialaniu *ochraniają* przed
> wieloma subtelnymi bugami w stylu "a mi się tu zapomniało zdjąć flagę
> przerwania".

Odwrotnie - pomaga to zamaskowac bug i zrobic go duzo trudniejszym do
wykrycia.

> Moje marzenie to PIC w sensie peryferiów i AVR w sensie rdzenia.

Nie widze przydatnosci...

> Ale sie
> nie doczekalem bo przyszły ARMy i pozamiatały.

Boli, bo nie da sie uzaleznic od jednego dostawcy. W firmie nigdy nie
uzyjemy PICa ani AVRa do niczego co wychodzi na zewnatrz, bo cena za
single-source supply jest za duza.

>> Bardzo ciekawe. Akurat na twoje ulubione AVRy jest kompilator - powstał
>> pewnie tylko dla zabawy. Poza tym, tego twojego nagłego czepienia się
>> Ady nie rozumiem już zupełnie. To dlatego, że ja o niej napisałem, to
>> już musisz być koniecznie przeciw?
>
> Nie muszę. Ada to zacny język, choć obrośnięty legendą jakości która jak
> widać musi walczyć z faktami. Ale stawianie go obok C++ w kontekscie tej
> rozmowy uważam za niepoważne. *Nikt* nie pisze w Ada poza szumem
> statystycznym. Nie zmuszajmy MC żeby pisał kompilator Ady dla 0.01%
> programistow uC.

Taaa... a te wszystkie samoloty co po swiecie lataja to w C++ pisane wg
Ciebie?

To ze nie wiesz/nie slyszales/nie podano do publicznej wiadomosci, nie
daje prawa nikomu mowic ze Ady sie nie uzywa. Uzywa sie w bardzo
powaznych zastosowaniach.


PS: 'crap' to sie tlumaczy jako 'gowno' (z US english), a nie
'beznadzieja'. Sprawdz w slowniku.

--
Jerry1111

do góry

On 2012-05-02 22:32, Jerry1111 wrote:
> Z tego by wynikalo ze 'ukryte' odblokowanie przerwan na koncu funkcji

Na koncu bloku. Jesteś *pewny* że wiedz gdzie strzela destruktor?

> jest mniej
> niebezpieczne niz nieodblokowanie przerwan w ogole?

Obydwa przypadki sa niebezpieczne. Wole ukryte ale *pewne* niż jawne i
podatne na błędy.

> No to powodzenia w
> debugowaniu kodu ktory ma 300kB bez OSa w celu znalezienia ktora funkcja
> za pozno wlacza przerwania.

Wyłacza zawsze przed } kończącym dany blok lub natychmiast po
opuszczeniu bloku inną metoda. W czym problem z tym "za późno" ? Możesz
podać przykład?

Stosowanie techniki "scoped" jest powszechne w świecie C++, choćby
boost::scoped_lock. Stosuje sie bo można. Inne języki nie mają to sie
nie stosuje.

> Odwrotnie - pomaga to zamaskowac bug i zrobic go duzo trudniejszym do
> wykrycia.

Nie zgadzam się. Moje doświadczenia sa zupełnie inne. To działa tak:
implementujesz raz i wiesz że działa. Przechodzisz do dalszych spraw nie
przejmując sie że zapomnisz. Po prostu nie zapomnisz. *Zawsze* zadziała.
Chyba że będzie bug w kompilatorze. Ale on może być też przy 2+2 w C.

> Taaa... a te wszystkie samoloty co po swiecie lataja to w C++ pisane wg
> Ciebie?

Możesz zacytować moją wypowiedź z której wynika wprost że skoro Ada
spowodował bum rakiety to C++ jest używany jako język firmware
samolotów? Jakieś message id?

> To ze nie wiesz/nie slyszales/nie podano do publicznej wiadomosci, nie
> daje prawa nikomu mowic ze Ady sie nie uzywa. Uzywa sie w bardzo
> powaznych zastosowaniach.

Ktore stanowią szum statystyczny implementacji firmware na procesorach w
ogóle. Co napisałem wydawalo mi się dość wyraźnie. Poza tym szumem - nie
stosuje się.

> PS: 'crap' to sie tlumaczy jako 'gowno' (z US english), a nie
> 'beznadzieja'. Sprawdz w slowniku.

Sprawdzałem. Ostatnio gówno bylo "shit". Ale ten świat idzie do przodu.

do góry

Dnia 02-05-2012 o 21:11:39 Sebastian Biały <h...@p...onet.pl>
napisał(a):

> teraz:
>
> cli()
> ....
> return
> ...
> goto
> ...
> break
> ...
> sei();
>
> I już po tobie. A po mnie nie.

Nie, bo czegoś takiego nie zrobię.

Za to:

CriticalSection critical;

... kod rzeczywiscie krytyczny

... dłuższy kod dopisany rok później

Przerwania zablokowane ciut za długo i sobie możesz szukać błędu przez
nabliższy miesiąc. Tak, można ograniczyć zasięg tego obiektu, ale...

> A więc dobrze podejrzewałem - jesteś assemblerowcem. Musisz wiedzieć co
> sie dzieje bo nie ufasz kompilatorom.

Dobrze się czegoś o sobie dowiedzieć i nawet do psychoanalityka iść nie
trzeba. Jeśli już koniecznie chcesz wiedzieć, to zaczynałem od Pascala
(Basica jako dzieciak nie liczę), potem C++, potem VHDL. Następnie z
wielkim trudem przeszedłem z C++ do C. Faktycznie sporo fragmentów
programuję w assemblerze, ale tylko tam, gdzie jest to absolutnie wymagane
ze względu na wydajność. Normalnie w C, a po stronie komputera głównie w
C++. Po prostu staram się używać młotka do wbijania gwoździ, a śrubokręta
do wkręcania wkrętów.

Nie o to chodzi, że muszę wiedzieć co się dzieje (to że muszę wiedzieć co
kompilator robi, to jest jasne), ale o to, że kod powinien wyglądać tak,
że będę od jednego rzutu oka widział co się dzieje.

>> Architektura 16-bit Microchipa (PIC24, dsPIC33) to właśnie coś takiego.
>
> Co takiego? Ślepą uliczkę sprzętowego stosu?

Jakiego sprzętowego stosu?! Sprzętowy jest w 8-bitowych PICach, a ja tu
piszę o 16-bitowych. Jak już coś krytykujesz, to wypadałoby wiedzieć o tym
cokolwiek.

> Brak wsparcia poza żalosnym kompilatorem producenta?

gcc (oraz HiTech). Bardzo różne od gcc na AVR i od gcc na ARMa, tak?

> Nawt MC sie puknął w czolo i zakopał to cudo głęboko pod ziemią żeby już
> nie straszyło.

Bądźże poważny. Obok PIC32 najsilniej rozwijane rodziny (szczególnie
PIC24F). Najbogatsze peryferia, a do układów XLP mało co może podskoczyć w
kwestii poboru mocy. ARMa w wielu aplikacjach zastępuje z powodzeniem, a
cenowo zwykle łatwo wygrywa.

>> Jeśli chodzi o te
>> 32 bit (rdzeń MIPS) to spodziewam się, że prędzej czy później kompilator
>> C++ się pojawi.
>
> Jasne. http://www.microchip.com/forums/m544964.aspx

Niezły argument :) Ale to jednak ja jeżdzę na te szkolenia dla FAE
Microchipa, a nie ci przypadkowi użytkownicy forum. Nie mówię, że _wiem_
że się pojawi, bo się tym nie interesowałem. Za 2 tygodnie jadę, mogę przy
okazji spytać o oficjalne plany.

ae

do góry

On 2012-05-03 01:05, Andrzej Ekiert wrote:
> CriticalSection critical;
> ... kod rzeczywiscie krytyczny
> ... dłuższy kod dopisany rok później
> Przerwania zablokowane ciut za długo i sobie możesz szukać błędu przez
> nabliższy miesiąc. Tak, można ograniczyć zasięg tego obiektu, ale...

Podobnie jak wstawiając return i zapominając sei. Ot, taka robota.
Trzeba być uważnym.

> Faktycznie sporo fragmentów
> programuję w assemblerze, ale tylko tam, gdzie jest to absolutnie
> wymagane ze względu na wydajność.

Kiepski kompilator?

> Normalnie w C, a po stronie komputera
> głównie w C++. Po prostu staram się używać młotka do wbijania gwoździ, a
> śrubokręta do wkręcania wkrętów.

Właśnie. Dlatego używam C++ do uC zamiast wbijać gwoździe plastikowym
młotkiem made in china Microchipa.

>>> Architektura 16-bit Microchipa (PIC24, dsPIC33) to właśnie coś takiego.
>> Co takiego? Ślepą uliczkę sprzętowego stosu?

Przepraszam moja wina, zapędziłem się. PIC24 nie ma. Swoją drogą
Świetnie to potwierdza tezę o slepej uliczce :D

>> Brak wsparcia poza żalosnym kompilatorem producenta?
> gcc (oraz HiTech). Bardzo różne od gcc na AVR i od gcc na ARMa, tak?

Jest jakis gcc? To spaniałe wieści. A gdzie go mogę pobrać? Pytam serio,
jeszcze kilka miesiący temu widziałem w sieci same narzekania na brak
gcc @ pic.

> ARMa w wielu aplikacjach zastępuje z powodzeniem,
> a cenowo zwykle łatwo wygrywa.

Wiadomo. Szczególnie że masa kodu dla arma da się kompilować wprost ...
oh wait... da się ?

> Za 2 tygodnie jadę, mogę
> przy okazji spytać o oficjalne plany.

Pytaj. PICe mnie zawsze intertesowaly ze względu na peryferia. Ale
podejście do programisty jest skandaliczne.

do góry

Dnia 03-05-2012 o 10:27:33 Sebastian Biały <h...@p...onet.pl>
napisał(a):

> Podobnie jak wstawiając return i zapominając sei. Ot, taka robota.
> Trzeba być uważnym.

Święte słowa. Żadna sztuczka panaceum na brak uwagi nie jest.

>> Faktycznie sporo fragmentów
>> programuję w assemblerze, ale tylko tam, gdzie jest to absolutnie
>> wymagane ze względu na wydajność.
>
> Kiepski kompilator?

Nie, kod odpowiadający na zdarzenia w czasie rzeczywistym. Żeby ci
uświadomić o czym mowa: w kawałku, nad którym teraz pracuję jest jeden
wykomentowany "nop" i 5 linijek komentarza kiedy należy go włączyć
(parametry zewnętrznego układu w relacji do oscylatora). Optymalizuję tam
takie rzeczy, jak wykorzystanie rejestrów roboczych w przerwaniu,
skutecznie minimalizując liczbę zachowywanych na stosie i kombinując takie
kodowanie stanów i dobór instrukcji, żeby nie trzeba było z tych rejestrów
korzystać. Gdybym napisał ten kod w języku wyższego poziomu, natychmiast
straciłbym tę kontrolę.

> Jest jakis gcc? To spaniałe wieści. A gdzie go mogę pobrać? Pytam serio,

Skoro serio, to http://www.microchip.com/compilers
gcc był od początku istnienia architektury 16-bit, czyli od 2004 roku, w
którym wprowadzono pierwszego dsPIC30F.

ae

do góry

On 2012-05-03 11:12, Andrzej Ekiert wrote:
> Optymalizuję
> tam takie rzeczy, jak wykorzystanie rejestrów roboczych w przerwaniu,
> skutecznie minimalizując liczbę zachowywanych na stosie i kombinując
> takie kodowanie stanów i dobór instrukcji, żeby nie trzeba było z tych
> rejestrów korzystać.

Dziwne. Przecież to rola kompilatora. Wręcz książkowa.

> Gdybym napisał ten kod w języku wyższego poziomu,
> natychmiast straciłbym tę kontrolę.

Wydaje mi się że tą kontrole musisz utrzymać z powodu kiepskiego
kompilatora.

PS. Tak, też mam ciasny kod. Jednak z wyników optymalizacji gcc jestem
zadowolony, w *ostateczności* biorę asm, jak każdy. Jednak nie trafia mi
się to codziennie żeby warunkowało dobór kompilatora do *wszystkiego*.

> > gcc był od początku istnienia architektury 16-bit, czyli od 2004 roku, w
> którym wprowadzono pierwszego dsPIC30F.

full-featured ANSI compliant C. A c++ ?

do góry

Dnia 03-05-2012 o 11:19:17 Sebastian Biały <h...@p...onet.pl>
napisał(a):

>> Gdybym napisał ten kod w języku wyższego poziomu,
>> natychmiast straciłbym tę kontrolę.
>
> Wydaje mi się że tą kontrole musisz utrzymać z powodu kiepskiego
> kompilatora.

Uparłeś się utrzymywać, że kompilator, o którego istnieniu nie wiedziałeś
jeszcze wczoraj, z całą pewnością jest do niczego. Pewnie z powodu
wbudowanych wad architektury, której kompletnie nie znasz.

Przyjmij do wiadomości, że to jest przypadek w którym można albo zejść do
asm, albo zająć się czym innym.

> full-featured ANSI compliant C. A c++ ?

Toż zaczęliśmy od tego, że c++ nie ma. Proponuję też na tym skończyć, bo
mi się już nie chce dłużej.

ae

do góry

On 2012-05-03 11:50, Andrzej Ekiert wrote:
> Proponuję też na tym skończyć, bo
> mi się już nie chce dłużej.

Zgoda. EOT.

do góry

W dniu 2012-05-02 14:52, Andrzej Ekiert pisze:

>> Destruktory to cecha która nie wymaga podejścia obiektowego do
>> programowania. Najprościej:
>>
>> struct CriticalSection {
>> CriticalSection{ cli(); }
>> ~CriticalSection{ sei(); }
>> };
>
> Sprytne i fajnie pokazuje, jak działa destruktor. Ale ja bym po prostu
> napisał:
>
> cli();
> .... kod krytyczny
> sei();
>
> Lepiej widać w jednym miejscu co się dzieje, bez szukania definicji
> klasy CriticalSection,

Tak argumentując to można powiedzieć, że bez szukania definicji cli i
sei też słabo widać co się dzieje (w szczególności: nie widać tu czy
jest jakiś związek między funkcjami cli i sei).

> bez zastanawiania się gdzie jej obiekt wychodzi z
> zasięgu, no i bez ryzyka, że osoba, która nie jest autorem kodu nie
> zauważy, że wsród paru zmiennych lokalnych jest jakiś dziwny pozornie
> nieużywany obiekt.

Jeśli użytkownik (programista) tak stwierdzi, to jest to wynik braku
znajomości języka czy braku znajomości projektu w którym przyszło mu
pracować.
Opisany mechanizm jest jasny i prosty -- nie przekonuje mnie tutaj
argumentacja, że mamy do czynienia z jakąś ezoteryką (włączając w to
debugowanie). Ostatecznie można opatrzyć kod odpowiednimi komentarzami.

>> Odwrotnie: dzieki swojemu samoczynnemu dzialaniu *ochraniają* przed
>> wieloma subtelnymi bugami w stylu "a mi się tu zapomniało zdjąć flagę
>> przerwania".
>
> Ja tam wolę widzieć przebieg programu, a nie musieć ciągle pamiętać, że
> między ostatnią instrukcją funkcji, a '}' uruchomi się jeszcze seria
> niewidzialnych funkcji.

W C lub w programowaniu C podobnym: IMO jeden diabeł.
Natomiast jeśli program jest w C++, to dochodzą wyjątki... wtedy dopiero
jest problem, gdy właśnie trzeba pamiętać, gdzie tu jeszcze wyjątek może
polecieć i ręcznie wywoływać odpowiednie finalizacje (pamiętając o
odpowiedniej kolejności i czy daną akcję sprzątania rzeczywiście należy
przeprowadzić).

Pisząc w C, czyli nie mając do dyspozycji mechanizmu wyjątków i
automagicznego wołania destruktorów, obsługa sytuacji nietypowych
(różnych błędów itp.) jest czasami naprawdę upierdliwa. Wyjątki w C++ to
IMO jedna z ważniejszych i bardziej użytecznych cech różniących ten
język od C (tak, ma to swoją cenę).

pzdr
mk

do góry