On 2012-05-03 15:32, mk wrote:
> Natomiast jeśli program jest w C++, to dochodzą wyjątki...

Mała uwaga: W c++ wyjątki są bardzo ciężkie. Poniekąd wlaśnie stąd
pochodzi urban legend dotyczący powiekszania się kodu C++ na uC.
Wystarczy zrobić obiekt z metodą wirtualną i nagle *kolosalnie*
powiększa się kod wynikowy wlasnie ze względu na propagacje wyjątków.
Oczywiście wystarczy zdefiniować pure_virtual_function_call na własny
ktory exceptiona nie rzuca, ale kto by to wiedział, lepiej pisać
nastepnego bloga o nieprzydatnosci C++ na uC :) ...

do góry

On 02/05/2012 22:53, Sebastian Biały wrote:
> 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?

Wiem gdzie, to semantyka.

>> jest mniej
>> niebezpieczne niz nieodblokowanie przerwan w ogole?
>
> Obydwa przypadki sa niebezpieczne. Wole ukryte ale *pewne* niż jawne i
> podatne na błędy.

No wlasnie ukryte jest wg mnie ciezej zdebugowac.

>> 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?

Jesli chce rozlaczyc logicznie wlaczanie i wylaczanie przerwan.

> 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.

Jakbys mnie cytowal: tez sie nie zgadzam i tez moje doswiadczenia sa 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.

Ja nie mowie ze nie dziala. Ja mowie ze mnie by ograniczalo (za przyklad
biore kod do ostatnio robionego urzadzenia, gdzie wlaczanie przerwan
jest zupelnie gdzie indziej niz ich wylaczanie). Zupelnie gdzie indziej
== inny plik.

>> 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?

Wyciales za duzo cytatow to i sens stracilo. Napisales ze: "Ada to jezyk
obrosniety legeda jakosci ktora musi walczyc z faktami". A ja odpowiadam
"crap prawda", Ada to jest jezyk ktory bardzo latwo przechodzi Sil4 i
jest _powszechnie_ uzywany w pewnych galeziach przemyslu. Na pewno nie
musi walczyc z faktami.

Tak, mozesz uzyc MisraC/C++, ale uwierz mi: latwiej bedzie sie na Ade
przestawic...

>> 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ę.

Jak to ze statystyka, zalezy jak policzymy. Jesli cene koncowego
produktu * ich ilosc to nie bedzie to juz szum statystyczny.

>> 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.

shit to tez gowno. Dobrze sprawdziles, tylko za szybko skonczyles sprawdzac.

http://oxforddictionaries.com/definition/crap

--
Jerry1111

do góry

On 03/05/2012 10:19, Sebastian Biały wrote:
> 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*.

Tez mam ciasny kod. Po uplywie 3 roboczomiesiecy gcc zostal skreslony z
listy kompilatorow nadajacych sie do pracy. Wybrany zostal inny (platny)
bijacy gcc na glowe. Poczatkowo po prostu nie wierzylem dla kumpla co
rozlozyl gcc na czynniki pierwsze (nie wierzylem ze gcc ma taki slaby
optimizer) i musialem go potem przepraszac - mial racje i
_bardzo_dokladnie_ podszedl do sprawy.

Tak - w tym przypadku cena kompilatora nie miala znaczenia.

Jaki nie powiem, bo nie moge.

--
Jerry1111

do góry

W dniu 2012-05-03 22:45, Jerry1111 pisze:
> On 03/05/2012 10:19, Sebastian Biały wrote:
>> 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*.
>
> Tez mam ciasny kod. Po uplywie 3 roboczomiesiecy gcc zostal skreslony z
> listy kompilatorow nadajacych sie do pracy. Wybrany zostal inny (platny)
> bijacy gcc na glowe. Poczatkowo po prostu nie wierzylem dla kumpla co
> rozlozyl gcc na czynniki pierwsze (nie wierzylem ze gcc ma taki slaby
> optimizer) i musialem go potem przepraszac - mial racje i
> _bardzo_dokladnie_ podszedl do sprawy.
>
> Tak - w tym przypadku cena kompilatora nie miala znaczenia.
>
> Jaki nie powiem, bo nie moge.
>

Szkoda, bo to grupa techniczna i być może niektórzy chcieliby wiedzieć
jaki kompilator jest bijący na głowę gcc.

--
pozdrawiam
MD

do góry

On 2012-05-03 22:45, Jerry1111 wrote:
> (nie wierzylem ze gcc ma taki slaby
> optimizer)

Albo ma taki slaby na konkretną platformę, albo to inny gcc ;) Ogromna
ilośc softu komercyjnego nie potwierdza tej tezy. To nie jest idealny
kompilator, ale nie jest też zły. Choć niektóre wybryki optymalizatora
na AVR czasami mnie zadziwiają.

do góry

On 2012-05-03 22:39, Jerry1111 wrote:
> No wlasnie ukryte jest wg mnie ciezej zdebugowac.

Po co debugować coś co na pewno działa? To troche jak argument klepaczy
w C: Wole nie używać std::vector bo cięzko debugować. A ja się pytam, po
co do cholery debugować *pewny* i *działajcy* kod? Bo może sie tam
trafić bug w kompilatorze? Wszędzie się może trafić. To nie powód do
braku zaufania do kompilatora i pisania wszystkiego w asm licząc na
własną nieomylność.

> > 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?
> Jesli chce rozlaczyc logicznie wlaczanie i wylaczanie przerwan.

To wtedy wpadasz w podobne bagno co rozłączne wlaczanie i wylaczanie
mutexa. Po co chcesz to robić rozłacznie? Masz aż tak daleko jedno od
drugiego? Może design jest mizerny skoro sekcja krytyczna ciągnie sie
przez wiele funkcji i bloków?

> Ja nie mowie ze nie dziala. Ja mowie ze mnie by ograniczalo (za przyklad
> biore kod do ostatnio robionego urzadzenia, gdzie wlaczanie przerwan
> jest zupelnie gdzie indziej niz ich wylaczanie). Zupelnie gdzie indziej
> == inny plik.

Dlaczego tak to jest zrobione? Istnieje jakiś argument? Z chęcia go
poznam. Pytam, bo ostatnio widziałem kilka kawałków kodu na PC w których
nie dało się zrobić boost::scoped_lock. I nie wynikało to z przemyślenia
bądź rozsądnej potrzeby. Po prostu tak "sie napisało". Mogło sie napisać
inaczej, ale programista nie wiedział.

Mała uwaga: zawsze możesz zrobić coś na kształt move_lock jeśli
*naprawdę* musisz gdzie indziej uwolnić przerwania. Masz dwa w jednym:
nie jesteś ograniczony w scope i masz pewność że ktoś to gdzieś uwolni.

do góry

W dniu 03.05.2012 23:32, Mario pisze:
> W dniu 2012-05-03 22:45, Jerry1111 pisze:
>> On 03/05/2012 10:19, Sebastian Biały wrote:
>>> 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*.
>>
>> Tez mam ciasny kod. Po uplywie 3 roboczomiesiecy gcc zostal skreslony z
>> listy kompilatorow nadajacych sie do pracy. Wybrany zostal inny (platny)
>> bijacy gcc na glowe. Poczatkowo po prostu nie wierzylem dla kumpla co
>> rozlozyl gcc na czynniki pierwsze (nie wierzylem ze gcc ma taki slaby
>> optimizer) i musialem go potem przepraszac - mial racje i
>> _bardzo_dokladnie_ podszedl do sprawy.
>>
>> Tak - w tym przypadku cena kompilatora nie miala znaczenia.
>>
>> Jaki nie powiem, bo nie moge.
>>
>
> Szkoda, bo to grupa techniczna i być może niektórzy chcieliby wiedzieć
> jaki kompilator jest bijący na głowę gcc.

Daleko nie trzeba szukać: avr-IAR, arm-rvds, h8-renesas. Pewnie więcej
przykładów by się znalazło.

do góry

On 03/05/2012 22:34, Sebastian Biały wrote:
> On 2012-05-03 22:45, Jerry1111 wrote:
>> (nie wierzylem ze gcc ma taki slaby
>> optimizer)
>
> Albo ma taki slaby na konkretną platformę, albo to inny gcc ;)

Mainstream gcc na dosc popularna platforme. Sorry - chcialbym wywolac te
komentarze "ale to przeciez niemozliwe", tylko nie moge.

Nie ma nic wspolnego z Intelem, tyle moge powiedziec.

--
Jerry1111

do góry

On 03/05/2012 22:49, Sebastian Biały wrote:
> On 2012-05-03 22:39, Jerry1111 wrote:
>> No wlasnie ukryte jest wg mnie ciezej zdebugowac.
>
> Po co debugować coś co na pewno działa? To troche jak argument klepaczy
> w C: Wole nie używać std::vector bo cięzko debugować. A ja się pytam, po
> co do cholery debugować *pewny* i *działajcy* kod?

Jak juz kod bedzie pewny i dzialajacy to idzie do biblioteki i mi wisi w
czym jest pisany. Na pewnym etapie zycia ten kod jest 'wrogi',
'niepewny' i 3x spowodowal wyciagniecie gasnicy ;-(

> Bo może sie tam
> trafić bug w kompilatorze?

Oj, moze... ale moze tak samo dla C jak i dla C++.

>> > 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?
>> Jesli chce rozlaczyc logicznie wlaczanie i wylaczanie przerwan.
>
> To wtedy wpadasz w podobne bagno co rozłączne wlaczanie i wylaczanie
> mutexa. Po co chcesz to robić rozłacznie? Masz aż tak daleko jedno od
> drugiego? Może design jest mizerny skoro sekcja krytyczna ciągnie sie
> przez wiele funkcji i bloków?

Mysle ze design nie jest mizerny. Starczy powiedziec ze procek ma <5%
wolnego czasu, ok. 10% spedza w RTOS i reszta w przerwaniach. Ot, taki
sprytniejszy kontroler PWM do przetwornicy.

>> Ja nie mowie ze nie dziala. Ja mowie ze mnie by ograniczalo (za przyklad
>> biore kod do ostatnio robionego urzadzenia, gdzie wlaczanie przerwan
>> jest zupelnie gdzie indziej niz ich wylaczanie). Zupelnie gdzie indziej
>> == inny plik.
>
> Dlaczego tak to jest zrobione? Istnieje jakiś argument? Z chęcia go
> poznam. Pytam, bo ostatnio widziałem kilka kawałków kodu na PC w których
> nie dało się zrobić boost::scoped_lock. I nie wynikało to z przemyślenia
> bądź rozsądnej potrzeby. Po prostu tak "sie napisało". Mogło sie napisać
> inaczej, ale programista nie wiedział.

Jak wczesniej napisalem: czas wykonania programu. W taki sposob mam
bardzo ladna kontrole nad wlaczaniem/wylaczaniem z priorytetami. Wiem,
mozna inaczej zrobic ale u mnie kazda us kosztuje duzo. Poza tym
kompilator glupi i nie zawsze wypelni pipeline procka tak dobrze, jak ja
to zrobie recznie.

> Mała uwaga: zawsze możesz zrobić coś na kształt move_lock jeśli
> *naprawdę* musisz gdzie indziej uwolnić przerwania. Masz dwa w jednym:
> nie jesteś ograniczony w scope i masz pewność że ktoś to gdzieś uwolni.

Ja wiem ze moge. Po prostu pokazuje ze dla roznych zastosowan sa rozne
rozwiazania. Zaczelo sie od tego ze C++ jest lepsze od C - owszem,
_czasami_ dla _niektorych_ zastosowan.


--
Jerry1111

do góry

On 2012-05-04 20:35, Jerry1111 wrote:
> Jak juz kod bedzie pewny i dzialajacy to idzie do biblioteki i mi wisi w
> czym jest pisany.

Więc kod na destruktorach gwarantuje że jest ok pod warunkiem braku
bugow w kompilatorze. *Tego* nie gwarantuje, ale nie przypominam sobie
takowego w gcc. Przypuszczam jednak że wiekszą masz szanse na dowolnego
innego buga w C który też będzie wymagał wyjęcia gaśnicy. Taki zawód, co
poradzisz.

> Mysle ze design nie jest mizerny. Starczy powiedziec ze procek ma <5%
> wolnego czasu, ok. 10% spedza w RTOS i reszta w przerwaniach. Ot, taki
> sprytniejszy kontroler PWM do przetwornicy.

To nijak nie tłumaczy rozłacznych punktów sekcji krytycznej.

> Jak wczesniej napisalem: czas wykonania programu. W taki sposob mam
> bardzo ladna kontrole nad wlaczaniem/wylaczaniem z priorytetami.

To nijak nie tłumaczy rozłacznych punktów sekcji krytycznej.

Pokaż syntetyczny przykład w którym sekcja krytyczna *musi* być
rozwałkowana.

> Zaczelo sie od tego ze C++ jest lepsze od C

Bzdua. Zaczeło się od tego że Microchip dostarcza rozwiązania z lat 80
dla lemmingów. Pomimo tego że moze dostarczyć darmowe ciastko nie robi
tego. A potem już poleciała standardowa dyskusja broniąca
"wystarczającego C" jakie już wiele razy widziałem.

do góry