RTV forum PL | NewsGroups PL

Zagwozdka w C Keil.

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Zagwozdka w C Keil.

Goto page Previous  1, 2, 3, 4, 5, 6

Irek.N.
Guest

Fri Feb 15, 2019 8:59 pm   



Quote:
Na szczęście co mówi volatile to jest zdefiniowane w standardzie a nie w
czyichś przekonaniach Smile

I całe szczęście Panie, i całe szczęście.
Czy w C ktoś pisze sterowanie do silników samolotów? ;)

Miłego.
Irek.N.

Queequeg
Guest

Sat Feb 16, 2019 11:53 pm   



Irek.N. <tajny_at_jakis.taki.jest.pl> wrote:

Quote:
Na szczęście co mówi volatile to jest zdefiniowane w standardzie a nie w
czyichś przekonaniach :)

I całe szczęście Panie, i całe szczęście.
Czy w C ktoś pisze sterowanie do silników samolotów? Wink

Pisze :)

https://pl.wikipedia.org/wiki/MISRA_C

https://www.aerodefensetech.com/component/content/article/adt/features/articles/17022

--
Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika

Queequeg
Guest

Sun Feb 17, 2019 12:03 am   



Irek.N. <tajny_at_jakis.taki.jest.pl> wrote:

Quote:
Skąd wiesz?

Chociaż by z powodu występowania możliwości błędnego odczytu wartości 0
dla tej zmiennej gdy jest czytana połówkami. Mój przypadek.

No tak, ale volatile przed tym nie chroni.

Quote:
Dlaczego miał by tak zrobić? Ponieważ volatile (w moim przekonaniu) mówi
kompilatorowi, że może się spodziewać problemów z tą zmienną i nie może
zakładać, że uda się ją odczytać etapowo (tak samo jak np. nie ma sensu
ją buforować, tylko za każdym razem trzeba czytać).

To przekonanie to to, co podpowiadałaby intuicja, ale z punktu widzenia
standardu jest błędne.

Zobacz chociażby tutaj:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

Strona 25, punkty 2 i 3, później też strona 121, punkt 6.

Tu nie ma mowy o atomicznym odczycie zmiennej tylko o nieoptymalizowaniu
dostępu do tej zmiennej.

Oczywiście na logikę chcielibyśmy, żeby zmienna nie zmieniła wartości w
trakcie jej odczytu, ale do tego po prostu służą inne mechanizmy niż
modyfikator volatile.

--
Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika

Queequeg
Guest

Sun Feb 17, 2019 12:11 am   



J.F. <jfox_xnospamx_at_poczta.onet.pl> wrote:

Quote:
Taka typowa sekcja krytyczna to jeszcze wymaga systemu operacyjnego, a
przynajmniej czegos na ksztalt, z przelaczaniem procesow ..

Czemu? Na 8-bitowcach zwykle nie mamy OS ani wielu procesów, mamy jedynie
przerwania, więc w sekcji krytycznej chcemy po prostu, żeby funkcje
obsługi przerwań poczekały na koniec sekcji krytycznej. Czyli:

1. Wyłączamy przerwania
2. Odczytujemy jedną połówkę zmiennej
3. Timer zgłasza przerwanie (ustawia flagę)
4. Odczytujemy drugą połówkę zmiennej
5. Włączamy (przywracamy) przerwania
6. Przerwanie zgłoszone przez timer jest obsługiwane

Quote:
Ha, moze i faktycznie C++ trzeba uzyc nawet na 8051 - dostep do
zmiennych obiektu da sie przez wydzielone funkcje, ktore zadbaja o
potrzebne rzeczy Smile

To, czy programujemy obiektowo, czy nie, to zupełnie inny poziom
abstrakcji niż to, o czym tutaj mówimy :)

--
Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika

Queequeg
Guest

Sun Feb 17, 2019 12:26 am   



J.F. <jfox_xnospamx_at_poczta.onet.pl> wrote:

Quote:
W sumie poprawnie - jeszcze nie wie ktore funkcje beda uzyte, to musi
skompilowac poprawnie.
Ale trzeba bylo sprawdzic ze static.

Sprawdziłem, nie ma różnicy w wygenerowanym kodzie.

Diff:

#v+
--- test-no-static.s 2019-02-16 23:19:27.993290080 +0100
+++ test-static.s 2019-02-16 23:19:20.653290321 +0100
@@ -29,7 +29,7 @@
.L6:
.align 2
.L5:
- .word i
+ .word .LANCHOR0
.size fn1, .-fn1
.align 2
.global fn2
@@ -45,8 +45,14 @@
.L9:
.align 2
.L8:
- .word i
+ .word .LANCHOR0
.size fn2, .-fn2
- .comm i,4,4
+ .bss
+ .align 2
+.LANCHOR0 = . + 0
+ .type i, %object
+ .size i, 4
+i:
+ .space 4
.ident "GCC: (Raspbian 4.9.2-10) 4.9.2"
.section .note.GNU-stack,"",%progbits
#v-

Quote:
A potem ...

static void fn2(void) { i = 40; }

i jej nie wywolywac.

Tak, to zmienia postać rzeczy.

Z samym `int i;` fn1 wygląda wtedy:

#v+
ldr r3, .L5
ldr r3, [r3]
..L2:
cmp r3, #42
bne .L2
#v-

A ze statycznym:

#v+
..L2:
b .L2
#v-

Quote:
static void fn2(void) { i = 40; }

main()
{
fn() ;
fn2();
}

Tak... to zrobił ciekawie.

Jeśli main jest niestatyczne, to wygenerował ciało fn1() a jeśli jest
statyczne, to zamienił na nieskończoną pętlę.

Quote:
No i ciekawe, na ile dobrze zoptymalizuje Smile

Nie wiem czemu to:

#v+
static int i;
void fn1(void) { while (i != 42) ; }
static void fn2(void) { i = 40; }
void fn3(void) { fn1(); fn2(); }
#v-

spowodowało wygenerowanie ciała fn1:

#v+
ldr r3, .L5
ldr r3, [r3]
..L2:
cmp r3, #42
bne .L2
#v-

--
Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika

Guest

Sun Feb 17, 2019 4:55 am   



W dniu wtorek, 12 lutego 2019 09:31:35 UTC+1 użytkownik Mateusz Viste napisał:
Quote:
Mi zdarza się (rzadko, ale jednak) użyć uint64_t do liczenia jakichś
naprawdę dużych wielkości, np. do zliczania cykli CPU, a czasem nawet po
_uint128_t (gcc) sięgnę jak potrzebuję popracować na adresach IPv6. Ale
to naprawdę sporadyczne przypadki, stąd ciekaw jestem co takiego piszesz
że w C89 nie da się Smile
Ostatni raz, kiedy musiałem, to był algorytm dekompozycji funkcji

boolowskich (czyli z grubsza rozkładu dużej funkcji boolowskiej na małe
które się da zaimplementować w LUTach), w praktyce oznaczało to masowe
robienie operacji logicznych na długich ciągach bitów. Do tego cały
proces trwał parę dni i chcieliśmy z tego zrobić jakieś statystyki,
więc by się przydało, żeby, mówiąc językiem młodzieży, zserializować
obiekt ze stanem pośrednim. Ostatnią rzeczą, na którą człowiek ma
ochotę, jest rzeźbienie czegoś, co zapisuje ciągi bajtów tak, żeby
działało na tzw. wszystkim niezależnie od długości największego
ciągu bitów który mieście się w rejestrze i umiał to odczytać i
przerobić tak jak trzeba na innej maszynie w razie potrzeby;)

Na całe szczęście już nie pracuję na uczelni i na dostęp do klastra
obliczeniowego nie trzeba się zapisywać z półrocznym wyprzedzeniem,
teraz pewnie bym to napisał w tzw. czymkolwiek względnie równolegle,
wrzucił do jakiejś komercyjnej usługi która robi obliczenia rozproszone
za parędziesiąt dolarów miesięcznie i miał wyniki w 15 minut.

Najbardziej zadziwiali mnie moi poprzednicy, bo mimo konieczności
rzeźbienia i z praktycznie zerowym budżetem ich algorytmy potrafiły zrobić w kilka godzin np. sprzętową implementację DES z dwucyfrowo% mniejszą liczbą bramek niż takie powiedzmy oprogramowanie od Altery :)

Pozdrawiam,
--
Karol Piotrowski

Mateusz Viste
Guest

Sun Feb 17, 2019 9:16 am   



On Sat, 16 Feb 2019 18:55:58 -0800, kropelka wrote:
Quote:
Ostatni raz, kiedy musiałem, to był algorytm dekompozycji funkcji
boolowskich (czyli z grubsza rozkładu dużej funkcji boolowskiej na małe
które się da zaimplementować w LUTach), w praktyce oznaczało to masowe
robienie operacji logicznych na długich ciągach bitów.

No ok, urzekające - ale z tego co rozumiem to była to misja pokroju
"akademicka masturbacja", czyli bardzo słaby przykład "typowego
programowania na normalny komputer" :)

Mateusz

J.F.
Guest

Sun Feb 17, 2019 11:57 am   



Dnia Sat, 16 Feb 2019 22:11:47 +0000 (UTC), Queequeg napisał(a):
Quote:
J.F. <jfox_xnospamx_at_poczta.onet.pl> wrote:
Taka typowa sekcja krytyczna to jeszcze wymaga systemu operacyjnego, a
przynajmniej czegos na ksztalt, z przelaczaniem procesow ..

Czemu? Na 8-bitowcach zwykle nie mamy OS ani wielu procesów, mamy jedynie
przerwania, więc w sekcji krytycznej chcemy po prostu, żeby funkcje
obsługi przerwań poczekały na koniec sekcji krytycznej. Czyli:

1. Wyłączamy przerwania

No wlasnie - zwykle wylaczenie przerwan, a nie szumna "sekcja
krytyczna" :-)

Quote:
Ha, moze i faktycznie C++ trzeba uzyc nawet na 8051 - dostep do
zmiennych obiektu da sie przez wydzielone funkcje, ktore zadbaja o
potrzebne rzeczy :-)

To, czy programujemy obiektowo, czy nie, to zupełnie inny poziom
abstrakcji niż to, o czym tutaj mówimy Smile

Ale rozwiazaloby pare problemow z zapominalskimi :-)

J.

Queequeg
Guest

Tue Feb 19, 2019 2:14 pm   



J.F. <jfox_xnospamx_at_poczta.onet.pl> wrote:

Quote:
1. Wyłączamy przerwania

No wlasnie - zwykle wylaczenie przerwan, a nie szumna "sekcja
krytyczna" Smile

Bo w tym konkretnym przypadku sekcja krytyczna sprowadza się do wyłączenia
przerwań :)

"In concurrent programming, concurrent accesses to shared resources can
lead to unexpected or erroneous behavior, so parts of the program where
the shared resource is accessed are protected. This protected section is
the critical section or critical region."

Jakby nie było, jest to sekcja krytyczna.

--
Eksperymentalnie: http://facebook.com/groups/pl.misc.elektronika

Goto page Previous  1, 2, 3, 4, 5, 6

elektroda NewsGroups Forum Index - Elektronika Polska - Zagwozdka w C Keil.

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map