On 10/10/2013 9:49 PM, Sebastian Biały wrote:
> On 2013-10-10 21:43, Marek Borowski wrote:
>>>> Ale to co napisalem odpowiadajac przedpiscy mozna uznac za summary ?
>>> Mniej więcej w wersji lite.
>> A w wersji full ?
>
> Np. statyczny polimorfizm (pomaga unit testować kod na PC bez utraty
To akutrat wymienilem.

> szybkości na uC) bądź obliczenia na szablonach.
>
Czyli metaprograming. Jeszcze cos ?

Pozdrawiam

Marek

do góry

> pamiętać. Podejście typu "muszę mieć wszystko pod kontrolą" niczym się
> nie różni od pisania w asm i świadczy o ubogim warsztacie.
Tu bym się nie zgodził.
Spotkamy się tu za 20 lat i ubogim warsztatem okaże się Twój C++.
Zresztą niektórzy twierdzą, że już tak jest.
Warsztat to chyba nie jest dobre słowo na metody pracy.
Wydaje mi się, że mieszasz. Uznajesz, że wybór języka programowania
wpływa na warsztat.
Na to jest już szereg innych określeń: inteligencja, umiejętność myślenia
przestrzennego,
dobra realizacja zadań. I moim zdaniem nie ma to kompletnie nic wspólnego
z rodzajem języka, którego używasz.
Choć, przyznaję, nauka kolejnego może rozwijać "warsztat".
Zupełnie tak samo, jak nauka budowy kolejnego ukontrolera.
A ja właśnie piszę w ASM tak gdzieś od 28 lat mniej więcej.
Mój warsztat jest bardzo "ubogi":
1) kod jest napisany zwięźle i czytelnie.
2) czysty kod rzadko przekracza kilka kB. Jeśli już, to są to szybkie
tablice LUT.
3) każda linijka ma swój komentarz.
4) nigdy nie analizuje kodu w ASM. Nie używam klawiszy Page Up/Down w tym
celu.
5) strukturę logiczną kodu mam zawartą w przestrzeni 2 wymiarowej w postaci
algorytmu
lub innych form zapisu, takich jak tabela stanów, opis struktur danych itp.
6) samo kodowanie sprowadza się do zamiany bloków logicznych na mnemoniki
konkretnego mikrokontrolera 8,16,32 bitowego
7) kodowanie jest czynnością przyjemną choć dość prymitywną.
8) najprzyjemniejsze jest uruchamianie. IDE mnie interesuje tylko w celu
postawienia Breakpointa i odczytanie stanu procesora.
9) cała analiza opiera się na oglądaniu kolorowych algorytmów.
10) przy moim toku pracy nie interesuje mnie na jaki typ procesora piszę.
Może być to MICROCHIP, Freescale, 8051core, MIPS - cokolwiek.
W szczególności nie interesuje mnie nawet język programowania.
Mógłby to być C++ czy C bez różnicy.
Tylko tak się składa, że asm sprawdza się najlepiej.

I teraz. Twój przykład mnie po prostu zastrzelił.
Nie pamiętam kiedy używałem w ogóle całkowitego blokowania przerwań.
(twoje cli())
Ja je najczęściej tylko włączam na początku kodu po włączeniu zasilania.
Cała reszta oparta jest na logicznym przemyśleniu sposobu wykorzystania
sprzętu.
Ważna jest komunikacja POP (ISR) i programu głównego.
Czasem ważne są priorytety przerwań.

W związku z powyższym proponuję zmienić przykład, gdyż usiłuje on udowodnić,
że:
1) wyższość jednego sposobu komunikacji (tutaj niby C++) nad drugim
(C )polega na tym, że wygodniej jest wyłączać przerwania, co jest po prostu
dość śmieszne.
Poniekąd wskazał to też kolega, który twierdzi, jeśli dobrze zrozumiałem,
że woli sobie sam decydować, gdzie włączyć, a gdzie wyłaczyć przerwania.
A okazuje się, że nikt się nie zastanawia: W jakim celu w ogóle je wyłączać?
Mogła by paść odpowiedź: bo mój kod nie zdąży, gdyż jest obiektowy :-)
2) Twoja argumentacja:
"W C musisz uzyć zmiennej tymczasowej. W C++ nie, kod jest
znacznie czytelniejszy"
Czy ja wiem?
Toż przecież - spójrz w swój kod po kompilacji.
Jestem ciekaw, jak niby to Twój destruktor przekazuje UART_D, czyli fizyczny
rejestr,
bez pośrednictwa nawet rejestru?
3) Jeden z tu obecnych kolegów, powiedział mi przed laty, że on pisze w C, a
potem podgląda skompilowany kod i poprawia idiotyzmy kompilatora.
Ja uważam, że ta metoda jest dobra. Sam próbowałem, ale...
Czas leci do przodu, a kompilatory operują już na wysokiej klasie
abstrakcji.
Po skompilowaniu powstają tak niebosiężne bzdury, że poprawianie zajmowałoby
mi mnóstwo czasu, więc jest to dla mnie zbyt kosztowne.
No bo jak poprawiać kod asm wygenerowany przez kompilator,
który odczytuje timer w przerwaniu i zachowuje na stosie 20 rejestrów
procesora,
wykonuje jedno podstawienie i przywraca te rejestry.
Niestety zwiększając częstotliwość przerwań, okazuje się, że szybki procesor
spędza swój żywot na zapisywaniu stosu w tą i z powrotem, tracąc głupio
swoją moc obliczeniową
oraz potencjalną gotowość do błyskawicznej reakcji na inne zmienne
środowiskowe.

--
-- .
pozdrawiam
Sylwester Łazar
http://www.alpro.pl Systemy elektroniczne.
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB.

do góry

On 2013-10-10 22:49, Marek Borowski wrote:
>>>> Mniej więcej w wersji lite.
>>> A w wersji full ?
>> Np. statyczny polimorfizm (pomaga unit testować kod na PC bez utraty
> To akutrat wymienilem.
>> szybkości na uC) bądź obliczenia na szablonach.
> Czyli metaprograming. Jeszcze cos ?

Rzadziej:

Programowanie obiektowe (ze względu na heap raczej arm7 i więcej). Sporo
SFINAE w różnych postaciach. Obciętą wersję template expressions w
jednym z projektów. Silnie typowane flagi bitowe. Namespaces
powszechnie, często anonimowe. Type traits. Inicjalizacja przed main
(szczególnie peryferiów).

Natomiast latwiej będzie czego nie używam:

Smart pointerów, bo fragrmentują pamięć, boosta (tylko dlatego że nie ma
zazwyczaj na mniejsze uC), stla ze względu na fragmentacje. Boosta
żałuję najbardziej.

do góry

On 2013-10-11 00:11, Sylwester Łazar wrote:
>> pamiętać. Podejście typu "muszę mieć wszystko pod kontrolą" niczym się
>> nie różni od pisania w asm i świadczy o ubogim warsztacie.
> Tu bym się nie zgodził.
> Spotkamy się tu za 20 lat i ubogim warsztatem okaże się Twój C++.

Zauważ ciekawostkę. Każdy programista C powie, że u niego też się da "bo
tu panie, można takie makro zrobić i już". Trudno się z tym nie zgodzić,
skoro oba języki są identyczne w sensie Turinga. Tylko co z tego wynika?
Wymyslanie kwadratowych kół. Takich jak "przecież gcc ma destruktory w
C". Absurd. C++ ma destruktory i jest wspierany *wszędzie* poza niszami.
I cały problem sprawadza się do wymiany gcc na g++ w makefile. Jeśli
"wszystko też się da zrobić w C" to masz ubogi warsztat. Bo masz tylko
młotek i wkręcasz nim śrubki.

> A ja właśnie piszę w ASM tak gdzieś od 28 lat mniej więcej.
> Mój warsztat jest bardzo "ubogi":
> 1) kod jest napisany zwięźle i czytelnie.

Asm jest językiem write-only i 100% nie przenośnym. I turing complete,
bez wątpienia. Meta assemblery które robią abstrakcję na cpu muszą i tak
robić jakieś założenia ktore sa nieprzenośne.

> 2) czysty kod rzadko przekracza kilka kB. Jeśli już, to są to szybkie
> tablice LUT.

Mój kod ma taki rozmia jaki jest w nim algorytm. Twierdzenie że asm
magicznie zmniejsza rozmiar jest nadużyciem. LUT (w jakiejkolwiek
formie) w C++ jest jakims problemem?

> 3) każda linijka ma swój komentarz.

No właśnie, kod jest tak nieczytelny że bez komentarzy nie da rady. Tak,
wiem że to co teraz napisałem powoduje skok ciśnienia. Dobrze się
zastanów czy obecnośc komentarzy świadczy o czytelności *kodu*, czyli
punkt 1. Niektórzy twierdzą że *kod* prawidłowo napisany nie zawiera
komentarzy. Sa zbędne i nie zawsze synchroniczne względem kodu czesto
wproawadzają w bład.

> 4) nigdy nie analizuje kodu w ASM. Nie używam klawiszy Page Up/Down w tym
> celu.

Trudno mi się zgodzić z hipotezą że każdy komentarz jest aktualny do
każdego kawałka kodu. Zazwyczaj nie jest. Jesli trzymasz to w ryzach to
gratuluje. Nikt nie dałby rady. Widziałem wiele prób.

> 5) strukturę logiczną kodu mam zawartą w przestrzeni 2 wymiarowej w postaci
> algorytmu
> lub innych form zapisu, takich jak tabela stanów, opis struktur
danych itp.

Strukturę logiczną masz porozmywaną na detalach obsługi stosu, rolowania
bitów i tym podobnych elementarnych operacji ktore ukrywają sens
algorytmu skupiając sie na emulacji mnożenia. Jesli istnieje
wysokopoziomowy opis to naduzyciem jest twierdzenie że to jest assembler.

> 6) samo kodowanie sprowadza się do zamiany bloków logicznych na mnemoniki
> konkretnego mikrokontrolera 8,16,32 bitowego

Oczywiście o ile ilośc rejestrów się zgadza. Albo Neumann zamienil się w
Harvard. Wiem że można sporo zrobić w ten sposób ale po co skoro po to
powstal C i masa innych jezyków?

> 7) kodowanie jest czynnością przyjemną choć dość prymitywną.

Bo kazdy język write-only przyjemnie się koduje. Zapytaj programistów
perla. Oni kochają pisać. Czytać nienawidzą.

> 8) najprzyjemniejsze jest uruchamianie. IDE mnie interesuje tylko w celu
> postawienia Breakpointa i odczytanie stanu procesora.

To dośc interesujące bo wiekszość moich projektów nie ma ani kawałka
IDE. Makefile, konsola, edytor. Ponadto polemizowalbym że odczytywanie
stanu procesora jest wygodniejsze niż chodzący po ekranie IDE kursor i
podgląd zmiennych pod myszką.

> 9) cała analiza opiera się na oglądaniu kolorowych algorytmów.

Z chęcią zobacze jak wygląda taki zapis w *assemblerze*.

> 10) przy moim toku pracy nie interesuje mnie na jaki typ procesora piszę.
> Może być to MICROCHIP, Freescale, 8051core, MIPS - cokolwiek.
> W szczególności nie interesuje mnie nawet język programowania.
> Mógłby to być C++ czy C bez różnicy.
> Tylko tak się składa, że asm sprawdza się najlepiej.

Piszesz najprawdopodobniej dość określone algorytmy, gdzie metoda się
sprawdza.

Ja też nie jestem zainteresowany na co piszę. Co gorsza kod zazwyczaj
jest przetestowany w sporym stopniu przed pierwsza wrzutą w uC. I nie
chodzi tutaj o emulatory, tylko o unit testy.

> I teraz. Twój przykład mnie po prostu zastrzelił.
> Nie pamiętam kiedy używałem w ogóle całkowitego blokowania przerwań.
> (twoje cli())

Ja pamiętam. Wtedy gdy to konieczne. Na przykład wczoraj musiałem w
ciągu 5 cykli zegara coś wystawić na piny. Nie mam czasu na obslugę timera.

> Ja je najczęściej tylko włączam na początku kodu po włączeniu zasilania.
> Cała reszta oparta jest na logicznym przemyśleniu sposobu wykorzystania
> sprzętu.

Co czasem wymaga wylaczenia przerwań. O takich drobnostkach jak atomowe
operacje na typach > niż slowo maszynowe ciezko mi wspominać.

> W związku z powyższym proponuję zmienić przykład, gdyż usiłuje on udowodnić,
> że:
> 1) wyższość jednego sposobu komunikacji (tutaj niby C++) nad drugim
> (C )polega na tym, że wygodniej jest wyłączać przerwania, co jest po prostu
> dość śmieszne.

Nie znasz kontekstu więc śmieszne jest twierdzenie że jest o
nieprzydatny. A kontekst co gorsza jest niepotrzebny bo to po prostu
czesto spotykany idiom.

Pamietaj że to nie jest *jedyny* przykład. To tylko najprostsza rzecz
jaką programista embedded może uzyć po zamianie gcc na g++. Jest tego od
groma.

> Poniekąd wskazał to też kolega, który twierdzi, jeśli dobrze zrozumiałem,
> że woli sobie sam decydować, gdzie włączyć, a gdzie wyłaczyć przerwania.

Zazwyczaj robi to w parach i upiera się że robienie pary ręcznie jest
lepsze niż automatycznie. Nie wiem dlaczego.

> A okazuje się, że nikt się nie zastanawia: W jakim celu w ogóle je wyłączać?

Jest wiele celów. Zazwyczaj sprawdzają się do RT albo atomowych
operacji. Przykladow jest tak wiele że aż cieżko coś wybrać. jęsli nie
napotykasz na takie zastosowania gdzie jest to konieczne to być może nie
miałeś do dzisiaj okazji.

> Mogła by paść odpowiedź: bo mój kod nie zdąży, gdyż jest obiektowy :-)

Kod nie jest ani troche obiektowy. ANI TROCHĘ. Dlaczego każdy kto widzi
C++ od razu wrzeszczy obiektowość!? Przeciez to ficzer zazwyczaj bez
znaczenia dla uC.

> 2) Twoja argumentacja:
> "W C musisz uzyć zmiennej tymczasowej. W C++ nie, kod jest
> znacznie czytelniejszy"
> Czy ja wiem?
> Toż przecież - spójrz w swój kod po kompilacji.

Jest identyczny z C. Tak sama ilośc instrukcji kodu maszynowego.

> Jestem ciekaw, jak niby to Twój destruktor przekazuje UART_D, czyli fizyczny
> rejestr,
> bez pośrednictwa nawet rejestru?

Przecież czytelnośc nie dotyczy asm. Czytelnośc dotyczy kodu źrodłowego.
kod maszynowy wygeneruje się w obu wypadkach taki sam.

> 3) Jeden z tu obecnych kolegów, powiedział mi przed laty, że on pisze w C, a
> potem podgląda skompilowany kod i poprawia idiotyzmy kompilatora.

Jaki kompilator takie efekty.

> Ja uważam, że ta metoda jest dobra. Sam próbowałem, ale...
> Czas leci do przodu, a kompilatory operują już na wysokiej klasie
> abstrakcji.
> Po skompilowaniu powstają tak niebosiężne bzdury, że poprawianie zajmowałoby
> mi mnóstwo czasu, więc jest to dla mnie zbyt kosztowne.

Stajesz okrakiem w stosunku do faktów. Kompilatory stosują wysokie
poziomy abstrakcji aby poprawnie korzystając z C++ móc generować kod
lepszy niż ręcznie wydziobany w C. Niestety to wymaga dużego
doświadczenia w znajomosci architektury, języka i idiotyzmów c++.
Ogólnie twierdzenie ze kompilatory C++ generują marny kod jest
absurdalne. To jest prostu nieprawda. Natomiast niektóre z nich tak
robią z róznych przyczyn wlaczając w to debilizm programisty czy bledy
projektowe samego kompilatora a sytuacji nie poprawia fakt że z tego
powodu nikt ich nie chce używać, szczególnie w embedded.

> No bo jak poprawiać kod asm wygenerowany przez kompilator,
> który odczytuje timer w przerwaniu i zachowuje na stosie 20 rejestrów
> procesora,

A używa 20 rejestów? Mój odkłada tyle ile użyje. Ponadto temat RT jest
delikatny: tam nalezy uzyć czasem asm, czasem C, czasem C++. Zależy.
Jesli wydaje Ci się że C+ jest w/g mnie dobry na wszystko to się mylisz.
Mam setki wstawek assemblerowych bo muszę rozkladać cykle *perfekcyjnie*
i żaden język wysokiego poziomu do tego sie nie nada.

> wykonuje jedno podstawienie i przywraca te rejestry.

Masz popsuty kompilator. Weź lepszy.

do góry

On Fri, 11 Oct 2013 00:11:51 +0200, Sylwester Łazar<i...@a...pl>
wrote:
> 1) kod jest napisany zwięźle i czytelnie.
> 2) czysty kod rzadko przekracza kilka kB. Jeśli już, to są to
szybkie
> 3) każda linijka ma swój komentarz.

Tak się zastanawiam ile czasu Ci zajmuje realizacja jakiegoś
zadania/projektu, czy sa to projekty rozwojowe czy jednorazowe
zadania, które po realizacji nie są dalej rozwijane.

--
Marek

do góry

W dniu 10.10.2013 18:18, Sebastian Biały pisze:
> On 2013-10-10 18:13, Zbych wrote:
>> Słaby przykład, w gcc można zrobić destruktor w C.
>
> I wtedy mamy jaki język?

Jeśli pijesz do tego, że nie jest to czyste C, to argument jest
chybiony. Przerwań też nie masz w C (ani w C++).

do góry

On Fri, 11 Oct 2013 00:53:30 +0200, Sebastian
Biały<h...@p...onet.pl> wrote:
> Asm jest językiem write-only i 100% nie przenośnym. I turing
complete,
> bez wątpienia. Meta assemblery które robią abstrakcję na cpu muszą
i tak
> robić jakieś założenia ktore sa nieprzenośne.

Trudno się nie zgodzić z Twoimi argumentami.
Sam osobiście nie jestem entuzjastą programowania obiektowego, ale
pewnie to wynika z przyzwyczajenia i uprzedzeń.

Natomiast jako pracodawca zatrudniający kilkunastu programistów
obecnie (nie embeded), a w skali kilkunastu lat kilkudziesięciu się
przewinęło, zauważyłem ciekawą statystykę:
1. Najwięcej poroblemów jest z kodem progranistów, którzy deklarują
się jako programiści jedynie w c++ lub (najczęściej) java. Głównie
problemy jakie mam na myśli to brak nawyków testowania tego co piszą.

2.Najczęściej programiści (z tymi ci miałem do czynienia) "obiektowi"
nie maja wyobrażenia jak działa procesor czy jakie są różnice w arch.
Neumann/Harvard. Kompletnie nie zastanawiają się nad kwestia jak
będzie wyglądał kod wynikowy tego ci piszą.
Chodzi mi o sytuacje, w których można czasami trochę "pomóc"
kompilatorowi aby nie wygenerował jakiegoś potworka. Ale ok,
powiedzmy, że to raczej cecha języka, że nie muszą się o to martwić.

3. Mimo deklaracji, że jest się programistą obiektowym programują
strukturalnie (sic!), nie wykorzystując zalet/cech deklarowanego
języka.

4. Ogromne problemy z bezpieczeństwem. Pierdyliąt zewnętrznych
"gotowców" (biblioteki, frameworki, konektory i inne dziwactwa)
powoduje nawyk korzystania z nich i mamy oprócz błędów w "własnym"
kodzie błędy innych.

Natomiast najmniej problemów jest tymi, którzy deklarują się jako
"multi-kulti" z naciskiem na C, lizneli kiedyś embeded i uwaga, nie
stosują żadnych IDE tylko sam vim lub emacs + makefile (!).

--
Marek

do góry

Hello Marek,

Friday, October 11, 2013, 8:56:17 AM, you wrote:

[...]

> Natomiast najmniej problemów jest tymi, którzy deklarują się jako
> "multi-kulti" z naciskiem na C, lizneli kiedyś embeded i uwaga, nie
> stosują żadnych IDE tylko sam vim lub emacs + makefile (!).

Ale stać Cię na takich?


--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

On Fri, 11 Oct 2013 09:51:52 +0200, RoMan Mandziejewicz
<r...@p...pl.invalid> wrote:
> > stosują żadnych IDE tylko sam vim lub emacs + makefile (!).
> Ale stać Cię na takich?

Dobre pytanie, tylko na kilku takich, niestety. Ale muszą być, aby
pilnować resztę (głowinie jako team leaderzy). Trzeba uważać bo, jak
mawiał Jobs, kiepski programista przyciąga do siebie innych
kiepskich. W końcu możesz się ocknąć, że firmie masz samych
kiepskich. Inwestując w tych kilku najlepszych udaje się na razie
uniknąć takiej sytuacji. Ale bywało że nie było stać i faktycznie to
powiedzenie się sprawdzało.

--
Marek

do góry

Hello Marek,

Friday, October 11, 2013, 10:18:12 AM, you wrote:

>> > stosują żadnych IDE tylko sam vim lub emacs + makefile (!).
>> Ale stać Cię na takich?
> Dobre pytanie, tylko na kilku takich, niestety.

Albo jesteś bardzo bogaty albo jednak ci programiści nie są tak
dobrzy...

> Ale muszą być, aby pilnować resztę (głowinie jako team leaderzy).
> Trzeba uważać bo, jak mawiał Jobs, kiepski programista przyciąga do
> siebie innych kiepskich. W końcu możesz się ocknąć, że firmie masz
> samych kiepskich. Inwestując w tych kilku najlepszych udaje się na
> razie uniknąć takiej sytuacji. Ale bywało że nie było stać i
> faktycznie to powiedzenie się sprawdzało.

:(

--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry