On 2013-10-10 20:00, Sylwester Łazar wrote:
> Proszę mnie poprawić jeśli się mylę,
> jednak spróbuję zrozumieć.
> 1) tak jak kolega JDX zauważył, dla foo powinien być typ char, gdyż RETURN
> ma zwrócić wartość z RS-a.

To oczywiste że to czeski błąd, przeciez kod jest z palca i ma tylko
pokazać ideę.

> 2) I teraz w C (drugi przykład) jest problem, gdyż po przepisaniu do
> zmiennej temp,
> zostały ponownie włączone przerwania przez sei() (SEt Interrupt jak sądzę)
> Wtedy temp zwróci wartość odczytaną z UART_D i jest "cool",
> ale zwracając UART_D może być "klopsik", bo w międzyczasie mogło przyjść
> inne przerwanie od RS'a i zmienić wartość rejestru UART_D (UART Data jak
> sądzę)

W tym cały pomysł: żeby uzyskac odczyt w sekcji krytycznej i natychmiast
go zwrócić. W C musisz uzyć zmiennej tymczasowej. W C++ nie, kod jest
znacznie czytelniejszy.

> 3) W C++ jest na tyle wygodnie, że wystarczy wpisać (czy jak to się fachowo
> nazywa w obiektowym języku programowania) na początu, że
> to jest: CriticalSection cs;
> I teraz wiadomo, że jak foo się skończy, to przerwania same się odblokują.

To się nazywa RAII, nie ma nic wspólnego z obiektami poza tym że
akuratnie na nich można ją uzyskać. Wiekszość języków programowania nie
ma RAII choć ma obiekty.

> Czyli chodzi o to, że nie trzeba pamiętać gdzie włączyć sei(), a gdzie
> wyłączyć cli() (CLear Interrupt jak sądzę)
> tylko zapisać, że w foo() nie przejmujemy się przerwaniami, tylko robimy
> swoje?

Owszem, cała sztuka w tym żeby *nie* przejmować się sei. Ono się samo
zrobi tam gdzie powinno. W 99% wypadków poza patologicznymi chcesz mieć
parę cli/sei bez wzgledu na formę wyjścia z funkcji. I o tym nie
pamiętać. Podejście typu "muszę mieć wszystko pod kontrolą" niczym się
nie różni od pisania w asm i świadczy o ubogim warsztacie.

do góry

On 2013-10-10 20:07, JDX wrote:
>> Odróżniasz idiom RAII od kodu natywnego, prawda?
> Ale o co chodzi? Co ma RAII do kodu natywnego? W każdym razie chodziło
> mi jedynie o to, że cli() i sei() to nie są funkcje standardowe C czy
> też C++.

Wyobraź sobie że napiszę ten sam example bez cli/sei. Co on niby miałby
ilustrować? Sam idiom RAII nie jest przydatny, jego konkretna
implementacja już jest.

>> To nie jest prawda. Czasem chcemy mieć pewność że UART_D zostanie
>> odczytany jeszcze w sekcji krytycznej. Efektem czego jest workaround z
>> temp w C. Nie ma rozwiązań załatwiających wszystkie przypadki. To jest
>> rozwiązujące pewna sporą grupę czestych sytuacji w przerwaniach.
> No to przecież sam pokazałeś że w C obudowujemy czytanie w cli()/sei().

Ale musisz uzyć zmiennej tymczasowej i musisz *pamiętac* o sei. kod robi
się podatny na czynnik ludzki.

> A jeśli z jakiegoś powodu w tej samej funkcji potrzebujemy przeczytać
> zasób jeszcze raz, no to jeszcze raz obudujemy operację czytania. Zdaję
> sobie sprawę, że kod się komplikuje i tym samym jest bardziej podatny na
> błędy, ale w sam raz IMO w tak, nomen omen, krytycznych przypadkach jak
> CS lepiej jest sterować ręcznie a nie zdawać się na automatykę.

Dlaczego lepiej zdawać się na czlowieka a nie na automatyke absurdalnie
automatycznej rzeczy? RAII to mechanizm który obecnie jest testowany
biliony razy na sekundę na calym swiecie na wszystkich architekturach i
działa. Dlaczego miałby tu być problematyczny? Znam tylko jeden powód:
gównanie kompilatory na gówniane architektury (PIC < 32).

>> Destruktor nie "czeka" tylko wołany jest natychmiast po return.
>> Dokładnie tak jak chcę.
> Zakładając, że pomiędzy odczytaniem z chronionego zasoby a returnem nie
> ma znaczącego (w sensie czasu wykonania) kodu.

A skąd on miałby się tam wziąść? Nawej najgorsze kompilatory C++ nie
będą robiły zadnego obiektu sc. On nie istnieje w kodzie wynikowym,
zostaje po nim tylko sei w miejscach gdzie wychodzisz z funkcji. Puffff
i cała sekcja krytyczna, klasa, konstruktor itd zamienia się w dwie
instrukcje asm. To jest wlasnie ten moment którego programiści embedded
nie czają. Tam *nie* ma obiektu ani narzutu w kodzie. Kod jest taki sam
jak z C a bywa że lepszy.

>> Taki idiom daje znacznie wieksze gwarancje w dobrze zrobionym kodzie. W
>> kodzie napisanym byle jak czyli z wielkimi funkcjami - nic nie daje
>> gwarancji poza modlitwą. Subiektywnie patrząc: RAII genaruje mniej
>> błedów niż jego ręczna emulacja i miałem w życiu na to milion przykładów.
> W każdym razie ja w podanym przykładzie jakoś nie widzę wyższości C++
> nad C. Zyskujesz większą odporność na błędy ale płacisz za to mniej
> precyzyjną kontrolą nad CS.

Jesli potrzebujesz precyzyjniejszej kontroli nad cs to mozna taką zrobić
bez rezygnacji z RAII.

> Nie twierdzę, że C++ jest gorsze od C w
> zastosowaniach embedded. Twierdzę jedynie, że przykład jest słaby.

Bo miał być jakikolwiek. Np. często liczę na szablonach rozmiary typów
co pozwala mi kod przenieść między różnymi procesorami. Często
specjalizuję generyczną funckję za pomocą obiektu co pozwala mi kod z uC
testować na PC używając mocków. Jest sporo zastosowań. Żadne nie ma nic
wspólnego z obiektowością.

>> To jest coś chronione przez sekcję krytyczna. Nie ma znaczenia co to
>> jest. Probolemem wielu programistów embedded jest wlasnie to że *musza*
>> wiedzieć co to jest, choć wiedza taka zazwyczaj kończy się pisaniem
>> nieprzenośnego kodu.
> No nie wiem, mi w sam raz wystarczyłaby informacja, że to jest coś co ma
> być chronione za pomocą CS. Tak, abym nie musiał snuć domysłów. :-)

Przecież właśnie w tym kodzie to doskonale widać.

do góry

JDX <j...@o...pl> napisał(a):
> W każdym razie chodziło
> mi jedynie o to, że cli() i sei() to nie są funkcje standardowe C czy
> też C++.

Standardowość tych funkcji w żadnym stopniu nie zmienia sensowności tego
przykładu.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 1 day, 22 hours, 16 minutes and 13 seconds

do góry

On 10/10/2013 5:19 PM, Sebastian Biały wrote:
> On 2013-10-10 10:09, Marek Borowski wrote:
>>> Zdarłem już klawiaturę wyjasniając w kilku wątkach w ostatnich kilku
>>> latach :)
>> Ale to co napisalem odpowiadajac przedpiscy mozna uznac za summary ?
>
> Mniej więcej w wersji lite.
>
A w wersji full ?

Pozdrawiam

Marek

do góry

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
szybkości na uC) bądź obliczenia na szablonach.

do góry

On 2013-10-10 20:46, Sebastian Biały wrote:
[...]
> On 2013-10-10 20:07, JDX wrote:
>>> Destruktor nie "czeka" tylko wołany jest natychmiast po return.
>>> Dokładnie tak jak chcę.
>> Zakładając, że pomiędzy odczytaniem z chronionego zasoby a returnem nie
>> ma znaczącego (w sensie czasu wykonania) kodu.
>
> A skąd on miałby się tam wziąść? Nawej najgorsze kompilatory C++ nie
> będą robiły zadnego obiektu sc. On nie istnieje w kodzie wynikowym,
> zostaje po nim tylko sei w miejscach gdzie wychodzisz z funkcji. Puffff
> i cała sekcja krytyczna, klasa, konstruktor itd zamienia się w dwie
> instrukcje asm. To jest wlasnie ten moment którego programiści embedded
> nie czają. Tam *nie* ma obiektu ani narzutu w kodzie. Kod jest taki sam
> jak z C a bywa że lepszy.
Nie, nie, zupełnie nie zrozumiałeś o co mi chodzi. A chodzi mi o coś w
tym stylu:
struct CriticalSection{ CriticalSection() { cli(); } ~CriticalSection()
{ sei(); } };

void foo()
{
CriticalSection cs;
char tmp = UART_D;
do_some_very_time_consuming_stuff();
}

Przydałoby się opuścić CS zaraz po odczycie z chronionego zasobu a się
nie da. No chyba że zastosujemy trick w postaci jawnego zawołania cli(). :-D

do góry

On 2013-10-10 20:57, Grzegorz Niemirowski wrote:
> JDX <j...@o...pl> napisał(a):
>> W każdym razie chodziło
>> mi jedynie o to, że cli() i sei() to nie są funkcje standardowe C czy
>> też C++.
>
> Standardowość tych funkcji w żadnym stopniu nie zmienia sensowności tego
> przykładu.
Ech, to taki żart był...

do góry

On 2013-10-10 22:05, JDX wrote:
> Nie, nie, zupełnie nie zrozumiałeś o co mi chodzi. A chodzi mi o coś w
> tym stylu:
> struct CriticalSection{ CriticalSection() { cli(); } ~CriticalSection()
> { sei(); } };
>
> void foo()
> {
> CriticalSection cs;
> char tmp = UART_D;
> do_some_very_time_consuming_stuff();
> }
>

void foo()
{
chat tmp;
{
CriticalSection cs;
tmp = UART_D;
}
do_stuff();
}

do góry

On 2013-10-10 22:11, Sebastian Biały wrote:
[...]
> void foo()
> {
> chat tmp;
> {
> CriticalSection cs;
> tmp = UART_D;
> }
> do_stuff();
> }
Znaczy się de facto jawnie wołamy cli()/sei(). Tak jak w przykładzie w
C. :-)

do góry

On 2013-10-10 22:26, JDX wrote:
>> void foo()
>> {
>> chat tmp;
>> {
>> CriticalSection cs;
>> tmp = UART_D;
>> }
>> do_stuff();
>> }
> Znaczy się de facto jawnie wołamy cli()/sei(). Tak jak w przykładzie w
> C. :-)

Ponieważ przy skrajnym uproszczeniu nie ma oczywistych zalet. Teraz
zamiast tmp=UART_D; wsadź dwupoziomowy case w pętli i wtedy zobaczysz
różnicę. Zadaniem RAII jest pomoc w przypadkach skomplikowanych a nie
trywialnych.

do góry