W dniu poniedziałek, 11 lutego 2019 14:27:54 UTC+1 użytkownik Mateusz Viste napisał:
> Bo to zaiste nie (ANSI) C. Na co komu deklarowanie zmiennych w środku
> kodu? Jeśli odczuwasz taką potrzebę, to zapewne twój kod wymaga
> refaktoryzacji. Prawdziwe C to C89, wszystko inne to wymysły młodzieży,
> której się nudziło.
Wiem, że rozmawiamy trochę z przymrużeniem oka, więc miałem kiedyś
przygodę, kiedy utrzymywana przeze mnie paczka (co gorsza, w Pythonie)
przestała się budować. Tam był kod w C który był generowany
automatycznie, a narzędzia do współpracy Python - C na pewnym etapie
przestawiły flagi kompilatora z domyślnego "ANSI C z typowymi bajerami"
na "brak wstępu dla młodzieży, wyrzucaj error przy czymkolwiek
czego nie można według C89". Wszystko dzięki temu, że generowany
kod miał "int i;" przed forem a nie na początku funkcji.
Wtedy się dowiedziałem, że tego nie było w standardzie bo wszystkie
kompilatory C jakich w życiu używałem nie miały co do tego
obiekcji;)

> No ok - uczciwie muszę przyznać, że zdarza mi się korzystać z 'long
> long', ale to jedyna rzecz której mi czasem braknie w C89. :)
Ja patrzę z punktu widzenia kogoś, kto czasem napisze coś na
"normalny" komputer i chyba nigdy nie udało mi się napisać programu
w C, który używa poza jakimiś niekrytycznymi pętlami po 100 elementach
któregokolwiek z typów danych z C89. Standard C w tym zakresie jest
spuścizną po czasach Unixa, kiedy starano się zrobić jeden przenośny język
oprogramowania i system operacyjny obejmujący miriadę komputerów.
Efekt jest taki, że w kontekście zwykłego x86-64 windowsowy long
ma 32 bity, a uniksowy 64 i obydwa podejścia są zupełnie koszerne
pod względem standardu. Long long rzeczywiście jest sposobem
na wymuszenie zmiennej, która będzie miała te >= 64 bity ;)

Pozdrawiam,
--
Karol Piotrowski

do góry

On Mon, 11 Feb 2019 17:33:25 -0800, kropelka wrote:
> Ja patrzę z punktu widzenia kogoś, kto czasem napisze coś na "normalny"
> komputer i chyba nigdy nie udało mi się napisać programu w C, który
> używa poza jakimiś niekrytycznymi pętlami po 100 elementach
> któregokolwiek z typów danych z C89.

Ale przecież typy danych w C89 są całkiem normalne: char, short, int,
long... Ich szerokości mogą zmieniać się z jednego komputera na drugi
(np. taki int może mieć raz 16, raz 32, a innym razem 64 bity), ale to
wszystko jest zgodne z C89. long natomiast ma zawsze co najmniej 32 bity
- w jakich zastosowaniach jest potrzeba więcej na "normalnym" komputerze?

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ę :)

Mateusz

do góry

No więc znalazłem chwilę aby podjechać do klienta i popatrzeć dokładnie
w kod.
Na wstępie małe usprawiedliwienie - procedura była napisana na 8051 i
uruchomiona na jednym z pierwszych PLC jakie zrobiłem, w latach 90, ale
stosowana też później*. W tamtych czasach wydawało mi się, że ogarniam
podstawy C :)

W maszynie którą diagnozowałem definicja zmiennej DEL_STEP była o zgrozo
jako unsigned char. Nie zwróciłem na to uwagi, choć zauważyłem, że
sprawdzany jest tylko młodszy - przekazany - bajt zmiennej z którą
wywołano funkcję. Wygląda więc na to, że kompilator miał rację.

Po zmianie definicji na unsigned int kompilator robi OLR na obu
połówkach zmiennej DEL_STEP a następnie sprawdza czy wynik operacji jest
zerowy. Bardzo ładne rozwiązanie moim zdaniem.

Zrobiłem jeszcze jedną rzecz. Ponieważ jak zauważyliście, nie ma
gwarancji, że sprawdzenie 16 bitów będzie poprawne w przypadku gdy
przerwanie może je zmienić, podłączyłem oscyloskop, persystencję na
nieskończoną i obserwowałem czas generowany przez procedurę. Zdarzały
się błędnie odliczone interwały, ale nie za często. Zrobiłem jak Mateusz
podpowiedział - flaga w przerwaniu modyfikującym zmienną. Nie złapałem
żadnego błędnego odliczenia.

Tak więc przepraszam, ale wychodzi na to, że sensacji nie ma, kompilator
jednak dawał radę, a ja znowu się czegoś nauczyłem :)

Dzięki wszystkim za pomoc.


Miłego.
Irek.N.
* w późniejszych wersjach kodu (trochę inna wersja PLC) już była
poprawna definicja jako typ 16 bitowy, czyli kiedyś to zauważyłem,
poprawiłem i zapomniałem :(

do góry

> ... kiedyś to zauważyłem, poprawiłem i zapomniałem :(

Przynajmniej jakaś pociecha dla mnie - myślałem, że tylko ja mam sklerozę ;)

do góry

Użytkownik "stary grzyb" <s...@o...pl> napisał w wiadomości
news:q3vfp6$rq6$2@dont-email.me...
> > ... kiedyś to zauważyłem, poprawiłem i zapomniałem :(
>
> Przynajmniej jakaś pociecha dla mnie - myślałem, że tylko ja mam sklerozę
> ;)

Panie, ja tam nie mam sklerozy, odpukać! Puk puk... Kto tam? :):)

Kiedyś mi prawie półtora roku zajęło, aby złapać, dlaczego przy pracy z TC,
wyskakuje mi pewne (niepożądane) okienko. Banał, że śmiać sie chce :)
Czemu tyle? Bo stale zapomniałem wyłapać okoliczności, w jakich się to
staje.

--
Łapy, łapy, cztery łapy,
A na łapach pies kudłaty.
Kto dogoni psa? Kto dogoni psa?
Może ty? Może ty? Może jednak ja...?

do góry

W dniu 2019-02-12 o 23:02, stary grzyb pisze:
> > ... kiedyś to zauważyłem, poprawiłem i zapomniałem :(
>
> Przynajmniej jakaś pociecha dla mnie - myślałem, że tylko ja mam
> sklerozę ;)

Zdarzyło mi się kiedyś, że postanowiłem, że coś muszę zmodyfikować w
jednym programie. Wyszukałem miejsce gdzie to należy poprawić - a tu
"już ktoś to zrobił". Według daty pliku wynikało, że góra miesiąc temu :(
P.G.

do góry

Użytkownik "Irek.N." napisał w wiadomości grup
dyskusyjnych:q3vee4$o74$...@n...news.atman.pl...
>Na wstępie małe usprawiedliwienie - procedura była napisana na 8051 i
>uruchomiona na jednym z pierwszych PLC jakie zrobiłem, w latach 90,
>ale stosowana też później*. W tamtych czasach wydawało mi się, że
>ogarniam podstawy C :)

>W maszynie którą diagnozowałem definicja zmiennej DEL_STEP była o
>zgrozo jako unsigned char. Nie zwróciłem na to uwagi, choć
>zauważyłem, że sprawdzany jest tylko młodszy - przekazany - bajt
>zmiennej z którą wywołano funkcję. Wygląda więc na to, że kompilator
>miał rację.

uzyc niewlasciwy typ - zdarza sie.
Ale nie spojrzec jaki to typ przy sprawdzaniu/szukaniu bledu ... czas
na lecytyne :-)

>Po zmianie definicji na unsigned int kompilator robi OLR na obu
>połówkach zmiennej DEL_STEP a następnie sprawdza czy wynik operacji
>jest zerowy. Bardzo ładne rozwiązanie moim zdaniem.

Typowe.

>Zrobiłem jeszcze jedną rzecz. Ponieważ jak zauważyliście, nie ma
>gwarancji, że sprawdzenie 16 bitów będzie poprawne w przypadku gdy
>przerwanie może je zmienić, podłączyłem oscyloskop, persystencję na
>nieskończoną i obserwowałem czas generowany przez procedurę. Zdarzały
>się błędnie odliczone interwały, ale nie za często.

Czyli potrafi przerwanie trafic miedzy dwie instrukcje ?
No w sumie - zawsze miedzy dwie trafia, tylko kwestia
prawdopodobienstwa, kiedy trafi miedzy dwie istotne.

A tych instrukcji przy ORL byc moze nawet wiecej.

>Zrobiłem jak Mateusz podpowiedział - flaga w przerwaniu modyfikującym
>zmienną. Nie złapałem żadnego błędnego odliczenia.

Rozumiem, ze najpierw zmieniles typ zmiennej na int ?

Ale nie bardzo rozumiem - przerwanie ustawia flage, modyfikuje
zmienna, gasi flage ?
na przetwarzanie w procesie głownym nie ma to znaczenia - sprawdzi
sobie, ze flagi nie ma, zacznie czytac zmienna ... i tu przerwanie
przychodzi.
Co innego gdy uzywa zmiennej przerwanie wyzszego poziomu.

Ja bym tam wylaczyl przerwania na czas sprawdzenia, to raptem kilka
instrukcji, ale w pojedynczym while zaprogramowac to trudno.

A swoja droga - czy Keil sam ich nie wylacza ? Dla zmiennych volatile
powinien.

>* w późniejszych wersjach kodu (trochę inna wersja PLC) już była
>poprawna definicja jako typ 16 bitowy, czyli kiedyś to zauważyłem,
>poprawiłem i zapomniałem :(

Ale o co chodzi - powiekszyles wartosc opoznienia ponad 255, i sie
okazalo, ze nie czeka tyle co powinien ?

J.

do góry

W dniu 2019-02-13 o 11:28, J.F. pisze:
> Użytkownik "Irek.N."  napisał w wiadomości grup
> dyskusyjnych:q3vee4$o74$...@n...news.atman.pl...
>> Na wstępie małe usprawiedliwienie - procedura była napisana na 8051 i
>> uruchomiona na jednym z pierwszych PLC jakie zrobiłem, w latach 90,
>> ale stosowana też później*. W tamtych czasach wydawało mi się, że
>> ogarniam podstawy C :)
>
>> W maszynie którą diagnozowałem definicja zmiennej DEL_STEP była o
>> zgrozo jako unsigned char. Nie zwróciłem na to uwagi, choć zauważyłem,
>> że sprawdzany jest tylko młodszy - przekazany - bajt zmiennej z którą
>> wywołano funkcję. Wygląda więc na to, że kompilator miał rację.
>
> uzyc niewlasciwy typ - zdarza sie.
> Ale nie spojrzec jaki to typ przy sprawdzaniu/szukaniu bledu ... czas na
> lecytyne :-)
>
>> Po zmianie definicji na unsigned int kompilator robi OLR na obu
>> połówkach zmiennej DEL_STEP a następnie sprawdza czy wynik operacji
>> jest zerowy. Bardzo ładne rozwiązanie moim zdaniem.
>
> Typowe.
>
>> Zrobiłem jeszcze jedną rzecz. Ponieważ jak zauważyliście, nie ma
>> gwarancji, że sprawdzenie 16 bitów będzie poprawne w przypadku gdy
>> przerwanie może je zmienić, podłączyłem oscyloskop, persystencję na
>> nieskończoną i obserwowałem czas generowany przez procedurę. Zdarzały
>> się błędnie odliczone interwały, ale nie za często.
>
> Czyli potrafi przerwanie trafic miedzy dwie instrukcje ?
> No w sumie - zawsze miedzy dwie trafia, tylko kwestia
> prawdopodobienstwa, kiedy trafi miedzy dwie istotne.
>
> A tych instrukcji przy ORL byc moze nawet wiecej.
>
>> Zrobiłem jak Mateusz podpowiedział - flaga w przerwaniu modyfikującym
>> zmienną. Nie złapałem żadnego błędnego odliczenia.
>
> Rozumiem, ze najpierw zmieniles typ zmiennej na int ?
>
> Ale nie bardzo rozumiem - przerwanie ustawia flage, modyfikuje zmienna,
> gasi flage ?
> na przetwarzanie w procesie głownym nie ma to znaczenia - sprawdzi
> sobie, ze flagi nie ma, zacznie czytac zmienna ... i tu przerwanie
> przychodzi.
> Co innego gdy uzywa zmiennej przerwanie wyzszego poziomu.
>
> Ja bym tam wylaczyl przerwania na czas sprawdzenia, to raptem kilka
> instrukcji, ale w pojedynczym while zaprogramowac to trudno.
>
> A swoja droga - czy Keil sam ich nie wylacza ? Dla zmiennych volatile
> powinien.
W avr studio nie wyłącza, i keil pewnie też,
w gcc jest do tego osobna sekcja, atomic block się nazywa
i w niej sie takie porównania robi.


--
Pozdr
Janusz

do góry

>> Przynajmniej jakaś pociecha dla mnie - myślałem, że tylko ja mam
>> sklerozę ;)
>
> Kiedyś mi prawie półtora roku zajęło, aby złapać, dlaczego przy pracy z
> TC, wyskakuje mi pewne (niepożądane) okienko. Banał, że śmiać sie chce :)
> Czemu tyle? Bo stale zapomniałem wyłapać okoliczności, w jakich się to
> staje.

Ja mam nawet tabletki na poprawę pamięci, ale co z tego, skoro ...
zapominam je brać :)

do góry

>> Po zmianie definicji na unsigned int kompilator robi OLR na obu
>> połówkach zmiennej DEL_STEP a następnie sprawdza czy wynik operacji
>> jest zerowy. Bardzo ładne rozwiązanie moim zdaniem.
>
> Typowe.

Dla mnie bardzo eleganckie :)

> Rozumiem, ze najpierw zmieniles typ zmiennej na int ?

W * pisałem, że już kiedyś to znalazłem. Oczywiście że poprawiłem :)

> Ale nie bardzo rozumiem - przerwanie ustawia flage, modyfikuje zmienna,
> gasi flage ?
> na przetwarzanie w procesie głownym nie ma to znaczenia - sprawdzi
> sobie, ze flagi nie ma, zacznie czytac zmienna ... i tu przerwanie
> przychodzi.
> Co innego gdy uzywa zmiennej przerwanie wyzszego poziomu.

Procedura ustawiająca zmienną modyfikowaną w przerwaniu ustawia flagę i
czeka na jej zgaszenie. Przerwanie odlicza i jak doliczy to gasi flagę.

> Ja bym tam wylaczyl przerwania na czas sprawdzenia, to raptem kilka
> instrukcji, ale w pojedynczym while zaprogramowac to trudno.

Niepotrzebna zabawa. Poza tym wprowadzasz dodatkowy jitter ;)

> A swoja droga - czy Keil sam ich nie wylacza ? Dla zmiennych volatile
> powinien.

Niestety ale ignoruje zupełnie volatile, a nie powinien moim zdaniem.


> Ale o co chodzi - powiekszyles wartosc opoznienia ponad 255, i sie
> okazalo, ze nie czeka tyle co powinien ?


No ba, dajesz operatorowi możliwość ustawiania parametru w zakresie
100-500, a tu zonk, czasami maszyna się buntuje :)

Miłego.
Irek.N.

do góry