Użytkownik "T.M.F." <t...@n...mp.pl> napisał w wiadomości
news:hb9q8a$s99$1@atlantis.news.neostrada.pl...
> Nie pamietam assemblera '51, ale tam takie operacje jak sadze tez nie sa
> atomowe? Zreszta nawet jesli sa to pisanie takich rzeczy w C wcale nie
> gwarantuje, ze kompilator to skompiluje zgodnie z intencja autora.
> Chociazby stopien optymalizacji bedzie mial wplyw na koncowa sekwencje
> rozkazow.

Sprawdziłem. Niektóre są: CPL bit; MOV bit,C.
Nic więcej nie wiem, poza tym, co napisałem - że gdzieś dzwoni.
Rozumiałem, że program główny robił jakąś operację na jednej fladze bitowej
wymagającą dwu rozkazów (może ją negował), a przerwanie pisało na inną flagę
w tym samym bajcie, co podobno na 51 jest OK, a na AVR nie da się.
P.G.

do góry

Użytkownik "Konop" <k...@g...pl> napisał w wiadomości
news:hb9vjg$dls$1@inews.gazeta.pl...
> Pisząc program trzeba uważać na takie rzeczy ;)... czasem taka sytuacja
> jest po prostu niegroźna. W innym wypadku trzeba rozdzielić zmienne
> aktualizowane w programie od tych aktualizowanych w przerwaniach, albo
> stosować CLI i SEI ;)...
Czyli jest rozwiązanie.
Jeśli kompilatory wykrywają taką sytuację (co wydaje się logiczne) i
otaczają modyfikację wykonaną w programie głównym przez CLI, SEI to
rozumiem, że można sobie swobodnie łączyć flagi i krytykowanie tamtego
przykładu było bezpodstawne. Jedyny problem to nieco mniej optymalny
program.
P.G.

do góry

> Czyli jest rozwiązanie.
> Jeśli kompilatory wykrywają taką sytuację (co wydaje się logiczne) i
> otaczają modyfikację wykonaną w programie głównym przez CLI, SEI to
> rozumiem, że można sobie swobodnie łączyć flagi i krytykowanie tamtego
> przykładu było bezpodstawne. Jedyny problem to nieco mniej optymalny
> program.

Tylko, ze kompilatory nie wykrywaja takiej sytuacji i programista musi o
to zadbac sam. W avr-gcc libc jest stosowne makro - ATOMIC_BLOCK.
Ja sie jednak bede upieral przy tym, ze jesli ktos robil takie cuda w C
(swoja droga ciekawe jak w C dobral sie do flag i rejestru stanu
procesora) to sam sie prosi o problemy - kompilator kompilujac taki blok
wcale nie musi tego zamienic na jedna instrukcje.

--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.

do góry

Użytkownik "T.M.F." <t...@n...mp.pl> napisał w wiadomości
news:hba3mb$lvp$1@nemesis.news.neostrada.pl...
>> Czyli jest rozwiązanie.
>> Jeśli kompilatory wykrywają taką sytuację (co wydaje się logiczne) i
>> otaczają modyfikację wykonaną w programie głównym przez CLI, SEI to
>> rozumiem, że można sobie swobodnie łączyć flagi i krytykowanie tamtego
>> przykładu było bezpodstawne. Jedyny problem to nieco mniej optymalny
>> program.
>
> Tylko, ze kompilatory nie wykrywaja takiej sytuacji i programista musi o
> to zadbac sam. W avr-gcc libc jest stosowne makro - ATOMIC_BLOCK.
> Ja sie jednak bede upieral przy tym, ze jesli ktos robil takie cuda w C
> (swoja droga ciekawe jak w C dobral sie do flag i rejestru stanu
> procesora) to sam sie prosi o problemy - kompilator kompilujac taki blok
> wcale nie musi tego zamienic na jedna instrukcje.

Takie rzeczy robi sie gdy noz na gardle - trzeba zdazyc, a nie ma juz na
czym zaoszczedzic.

do góry

Użytkownik "T.M.F." <t...@n...mp.pl> napisał w wiadomości
news:hba3mb$lvp$1@nemesis.news.neostrada.pl...
> Tylko, ze kompilatory nie wykrywaja takiej sytuacji i programista musi o
> to zadbac sam. W avr-gcc libc jest stosowne makro - ATOMIC_BLOCK.
> Ja sie jednak bede upieral przy tym, ze jesli ktos robil takie cuda w C
> (swoja droga ciekawe jak w C dobral sie do flag i rejestru stanu
> procesora)
Tego nie twierdziłem.
Najpierw myślałem tylko o fagach bitowych w danych.
Potem jak była informacja, że są takie rejestry, w których się da atomowo,
to pomyślałem, że może tam były jakieś inne operacje.
Ja tego nie czytałem, tylko słyszałem krytykę przykładu i było to kilka lat
temu, a sam nic na procesory nie piszę.
P.G.

do góry

> A zwracaae procedura powinna tylko char lub int syknalizuj?cego OK lub

Czepiając się :-) procedura nic nie zwraca, a funkcja to i owszem :-)

Pozdrawiam
ELP

do góry

Użytkownik "ELP" <e...@p...neostrada.pl> napisał w wiadomości
news:op.u1ws3daazxema2@rafal...
>> A zwracaae procedura powinna tylko char lub int syknalizuj?cego OK lub
>
> Czepiając się :-) procedura nic nie zwraca, a funkcja to i owszem :-)

W C procedury sa funkcjami, w SQL procedry zwracaja - ja trzepac to trzepac.

do góry

> Tylko, ze kompilatory nie wykrywaja takiej sytuacji i programista musi o
> to zadbac sam. W avr-gcc libc jest stosowne makro - ATOMIC_BLOCK.
> Ja sie jednak bede upieral przy tym, ze jesli ktos robil takie cuda w C
> (swoja droga ciekawe jak w C dobral sie do flag i rejestru stanu
> procesora) to sam sie prosi o problemy - kompilator kompilujac taki blok
> wcale nie musi tego zamienic na jedna instrukcje.

No ale wydaje mi się, że informacja o "dobieraniu się" do rejestru FLAG
jest małą dezinformacją... chodziło o flagi "własne", trzymane w jakiś
zmiennych ;)...

Pozdrawiam
Konop

do góry

W dniu 16.10.2009 23:26, Konop pisze:
>> Tylko, ze kompilatory nie wykrywaja takiej sytuacji i programista musi
>> o to zadbac sam. W avr-gcc libc jest stosowne makro - ATOMIC_BLOCK.
>> Ja sie jednak bede upieral przy tym, ze jesli ktos robil takie cuda w
>> C (swoja droga ciekawe jak w C dobral sie do flag i rejestru stanu
>> procesora) to sam sie prosi o problemy - kompilator kompilujac taki
>> blok wcale nie musi tego zamienic na jedna instrukcje.
>
> No ale wydaje mi się, że informacja o "dobieraniu się" do rejestru FLAG
> jest małą dezinformacją... chodziło o flagi "własne", trzymane w jakiś
> zmiennych ;)...

To o flagach to z innej galezi tego watku, gdzie PG pisal o fladze Carry
z rejestru stanu.
--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.

do góry

ELP pisze:

>> A zwracaae procedura powinna tylko char lub int syknalizuj?cego OK lub
>
> Czepiając się :-) procedura nic nie zwraca, a funkcja to i owszem :-)

Tak to paaanie było w Pascalu. W C++ w klasach to nawet nie są funkcje
tylko metody. I mogą coś zwracać albo nie. A w zwykłym C wszystko o czym
mowa to funkcje. Tyle że niektóre zwracają daną typu void (podobnie jak
niektórych jedyny argument jest typu void, a czasem wiele argumentów
jest wskazaniami na typ void i nikt z tego powodu nie płacze).

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry