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.