ATNEL tech-forum

Re: Przesunięcie bitowe w prawo - problem

2016-11-19T19:07:55+01:00

Nie raz trafiałem na tę informację o promocji do int i że można się na niej wyłożyć.
Tylko to wredne przyzwyczajenie - wszyscy, ale nie ja.
Dobrze że żeśmy się pozbierali.

Jazio napisał(a):

Chodzi o kwestie zapisu. Zapomnieliśmy chyba o domyślnej promocji do int.

Dzięki Jazio
, to zdanie rozbłysło w moich ciemnych myślach, niczym pochodnia w forumowych lochach.
o.. i znalazłem pigułkę. Dzięki Mirog.

Statystyki: Napisane przez Daro69 — 19 lis 2016, o 19:07

Re: Przesunięcie bitowe w prawo - problem

2016-11-19T18:28:13+01:00

Jazio napisał(a):

Zatem jak kogoś wprowadziłem w błąd to przepraszam.

Nie traktuj tego zbyt dosłownie - bo też nie miałem zamiaru ci dogryzać czy coś ... wręcz przeciwnie, dlatego postarałem się opisać kolejny przykład drobiazgowo ... co chyba świadczy (mam nadzieję) o mojej dobrej woli

Statystyki: Napisane przez mirekk36 — 19 lis 2016, o 18:28

Re: Przesunięcie bitowe w prawo - problem

2016-11-19T18:04:23+01:00

Jazio napisał(a):

Ja myślę, że ten akurat przypadek jest warty zapamiętania, bowiem opisywana przez kol. Mirka sytuacja problemowa z promocją do int dotyczyła głównie spraw, gdzie oczekujemy wyników o zakresie większym niż int.

ZDECYDOWANIE nie piszę tego teraz żeby się z tobą sprzeczać - ale wprowadzasz w błąd i sam siebie i innych.

Domyślna promocja do int wcale nie dotyczy spraw gdzie oczekujemy wyników o zakresie większym niż int więc albo coś źle zrozumiałeś albo ... albo nie wiesz nadal co to znaczy, że kompilator DOMYŚLNIE bez jawnie określonego typu albo w miejscach gdzie nie może sobie zrobić niejawnego rzutowania na mniejszy typ zawsze przyjmie że ktoś działa na liczbie 16 bitowej

i pierwszym lepszym przykładem który pokazuje, że się mylisz jest chociażby użycie zapisu

[syntax=c]uint8_t tab[] = {
64,
~128
};[/syntax]

i co ? Chcę mieć tablicę elementów 8-bitowych ... ale ostatni element chciałbym żeby miał wartość 0b01111111 tylko że wymyśliłem sobie, że zapiszę to w postaci zanegowanej liczby 128 ...

no i proszę BACH!

------------------------ [ Dodano po: 1 minucie ]

ale jeśli wiem że domyślnie stałe dosłowne są również domyślnie promowane do 16 bitów to już zaczynam sobie zdawać sprawę co się stanie po zanegowaniu takiej wartości bez rzutowania ....

Statystyki: Napisane przez mirekk36 — 19 lis 2016, o 18:04

Re: Przesunięcie bitowe w prawo - problem

2016-11-19T18:01:22+01:00

Taka jest niestety "uroda" języka C, że dokonuje on niejawnych konwersji między typami. Często nie powoduje to problemów i wręcz jest wygodne, ale jak widać nie zawsze. W dodatku domyślne opcje kompilatora nie uwzględniają ostrzeżeń w potencjalnie niebezpiecznych sytuacjach.
Dlatego tak nieśmiało zaproponuję, żeby (szczególnie poleciłbym początkującym) dodać kompilatorowi opcję '-Wconversion', dzięki czemu kompilator będzie nas ostrzegał w sytuacjach, kiedy niejawna konwersja może spowodować problemy.
Aby to zrobić należałoby w polu o nazwie "Other flags" dopisać (jeśli już tam jest coś wpisane, najpierw dodać spację):

-Wconversion

Pole to znajduje się w opcjach projektu:

Eclipse
Project->Properties->C/C++ Build->Settings->AVR Compiler->Miscellaneous
Atmel Studio 7 (w wersji 6 jest chyba tak samo)
Project->Properties->Toolchain->AVR/GNU C Compiler->Miscellaneous

Podejrzewam, że dodanie tej opcji prędzej naprowadziłoby w tej sytuacji na rozwiązanie problemu

Oczywiście czasami możemy otrzymywać niepotrzebne ostrzeżenia. Można je jednak zlikwidować przez jawne rzutowanie, co pozwoli nam przy okazji zastanowić się, czy to rzutowanie nie wprowadzi nam błędu w wyniku operacji.

Nikogo oczywiście na siłę do tego nie namawiam. Chciałem tylko zwrócić uwagę, że istnieje taka opcja

Statystyki: Napisane przez andrews — 19 lis 2016, o 18:01

Re: Przesunięcie bitowe w prawo - problem

2016-11-19T17:03:36+01:00

Ja to rozumiem tak:
Zakładając, że:
PORTA= 0b01000000;
rozpatrujemy taką operację:
PORTA= ~((~PORTA)>>1);
teraz następuje domyślna promocja do int czyli nie 8 bitów, a 16 bitów:
PORTA= ~((~0000000001000000)>>1);
po dokonaniu negacji:
PORTA= ~(1111111110111111>>1);
po dokonaniu przesunięcia bitowego w prawo:
PORTA= ~(1111111111011111);
a teraz ostatnie 8 bitów "podanych" na port A:
PORTA= 11011111;

------------------------ [ Dodano po: 1 minucie ]

Kolego Mirog no dokładnie!

Statystyki: Napisane przez anshar — 19 lis 2016, o 17:03

Re: Przesunięcie bitowe w prawo - problem

2016-11-19T16:57:45+01:00

Daro69 - dzięki

Wartość początkowa (promocja do int):
0b 00000000 01111111
Negacja:
0b 11111111 10000000
Przesunięcie:
0b 11111111 11000000
Negacja:
0b 00000000 00111111

itd.

To by się zgadzało, faktycznie. Pozwolę sobie jednak być bardziej dociekliwy, kiedy mamy do czynienia z promocją do int? Tzn. rozumiem, że kompilator na czas swoich obliczeń bierze wsio i wrzuca jako int, tylko ciekawi mnie czemu tego nie robi w takim zapisie:

[syntax=c]PORTC = ~PORTC;
PORTC = ~(PORTC>>1);[/syntax]

?

------------------------ [ Dodano po: 5 minutach ]

Wartość początkowa (promocja do int):
0b 00000000 01111111
Negacja:
0b 11111111 10000000

PORTC przyjmuje już wartość: 0b 10000000

Przesunięcie:
0b 00000000 01000000
Negacja:
0b 11111111 10111111

To chyba sobie sam odpowiedziałem

------------------------ [ Dodano po: 5 minutach ]

Panowie, dziękuję serdecznie za pomoc!

Statystyki: Napisane przez Mirog — 19 lis 2016, o 16:57

Re: Przesunięcie bitowe w prawo - problem

2016-11-19T15:57:26+01:00

Mirog napisał(a):

Panie Mirku, to nie tak, że od razu obwiniam kompilator, jednak po paru dniach spędzonych przy tym po prostu zacząłem wymiękać

Rozumiem, ale jeszcze raz powtórzę - gdyby kompilator C miał się wykładać na (proszę mi wybaczyć) tak MEGA PROSTYCH przypadkach - to praktycznie co drugi projekt byłby skopany w setkach miejsc ... w ogóle programy żyłyby własnym życiem. Więc zawsze po prostu proponuję odrobinę pokory - bo ona wg mnie pozwala nieco szybciej się uczyć ... i szukać dobrych rozwiązań. Zaś pośpiech i niecierpliwość jak widać do niczego nie prowadzą ... I tylko o to mi chodzi ....

Jazio napisał(a):

Ja nie zakładam, że kompilator jest idealny

Powtórzę jeszcze raz - błąd przy TAK PROSTEJ operacji w kompilatorze doprowadzałby do GIGANTYCZNEJ ilości błędów w generowanym prawie każdym kodzie

Poza tym moje słowa nie były skierowane do ciebie bo ty zareagowałeś jak dla mnie ... wzorcowo i nie chodzi tu o moją ocenę - tylko o wzór dla całkiem początkujących czytających to forum ... zacytuję twój fragment wypowiedzi:

Jazio napisał(a):

Wygląda na to że, dokonywana jest jakby analiza kodu i dwie negacje się znoszą. Tylko nie rozumiemdlaczego ignorowane są nawiasy.

... co pokazuje - że SZUKASZ i słusznie DALEJ ... rozwiązania problemu - a nie "ręką w stół" i ... "kompilator zepsuty"

sorki, że tak troszkę jakby nie na temat w tym wątku mówię - ale to ważne dla tych którzy zaczynają się uczyć programowania - i czytać będą to za jakiś czas ... warto szukać a nie obarczać winą kompilatorów szczególnie przy tak błahych operacjach

Na zakończenie dodam, że ów KOMPILATOR - to nie jakieś "zwierzę, które samo się narodziło i ma jakieś błędy genetyczne" .... taki kompilator pisały całe zespoły ludzi i testowały od lat ... OWSZEM - pewnie, że do dzisiaj pojawiają się aktualizacje i usuwanie BUG'ów ... ale proponuję sobie zajrzeć na grupy dyskusyjne na temat obecnych błędów w kompilatorach .... to sądzę, że włosy się zjeżą na głowie - gdy zobaczycie z czym tam się się można spotkać i z jak skomplikowanymi zagadnieniami albo ew z jakimiś błędami dla np nowo wprowadzanych procków czy też dla procków co do których np sam Atmel podał np w nocie złe dane na temat działania niektórych rozkazów asm ....

Jazio napisał(a):

Ja nie zakładam, że kompilator jest idealny To w końcu też program komputerowy. A jak mówią informatycy, każdy program ma jakiś błąd.
Mam kontakt z wieloma programami i niejednokrotnie zgłaszałem do autorów błędy w działaniu. I to nie takie oczywiste, lecz takie które występują w bardzo specyficznych sytuacjach. Zatem nie można zakładać ze kompilator nie ma błędu.

Nikt nie zakłada, że kompilator nie ma błędu ale porównywanie jakiegoś tam .... programu komputerowego i błędów w nim do kompilatora .... to już lekki kosmos delikatnie mówiąc ... Bo "jakiś tam twój program" jest używany załóżmy przez X użytkowników, zaś kompilator przez setki tysięcy razy więcej developerów takich "jakichś programów"

Jazio napisał(a):

A to wszystko wynika z faktu, iż podczas kompilacji występuje optymalizacja i to że my piszemy funkcję przesunięcia bitowego, wcale nie oznacza, iż kompilator użyje takich poleceń ASM (np. LSR).

Bo to jest programowanie w C a nie w Asemblerze - i żaden kompilator C nie zagwarantuje ci że za każdym razem tak samo wygeneruje kod w ASM jeśli nawet zmieni się w okolicy jakaś drobna rzecz. Wystarczy o takiej prostej zasadzie pamiętać/wiedzieć - jak się programuje w C

Jazio napisał(a):

W tym przypadku, po kilku godzinach analiz różnych kodów ASMa udało mi się zobaczyć mechanizm działania dla tego przypadku.

I to jest właśnie cierpienie wszystkich, którzy z kolej przesiadają się z asemlera na C .... wciąż chcą patrzeć na ten język przez pryzmat asemblera ot takie nawyki - które czasem powodują, że długo nie mogą się przesiąść w pełni na C. Ja tu nie mówię tego konkretnie do ciebie - tylko że TAKI właśnie efekt mają zwykle asemblerowcy przechodzący na C

Ale pocieszające, że jeszcze gorzej mają np ci którzy przechodzą z Bascoma na C a długo wcześniej pracowali w Bascomie - wtedy boli jeszcze dłużej ale też da radę.... Podobnie z przechodzeniem z Arduino na C ... choć tu już jest ciut bliżej

------------------------ [ Dodano po: 1 minucie ]

--------------------------------------------------

Na zakończenie powiem, że prawie od początku wątku go sobie obserwowałem - ale z uwagi na to, że moich podpowiedzi na forum typu

PROMOCJA DO INT

są już chyba setki jak nie tysiące - to czekałem kto i kiedy wpadnie tutaj na to ale jak widać się udało i fajnie !

Statystyki: Napisane przez mirekk36 — 19 lis 2016, o 15:57

Re: Przesunięcie bitowe w prawo - problem

2016-11-19T15:37:06+01:00

O kurczaki.
Promocja do int.
No teraz to się rozumie.
Kol Mirog , zerknij na binarny zapis liczby int. I wszystko jasne.

Statystyki: Napisane przez Daro69 — 19 lis 2016, o 15:37

Re: Przesunięcie bitowe w prawo - problem

2016-11-19T15:24:29+01:00

Panie Mirku, to nie tak, że od razu obwiniam kompilator, jednak po paru dniach spędzonych przy tym po prostu zacząłem wymiękać Panowie, nie za bardzo rozumiem może, jednak, zgodnie z tym co napisał kolega anshar "Przesunięcie w prawo oznacza przemieszczenie wszystkich bitów argumentu w prawo o określoną liczbę miejsc oraz powielenie najstarszego bitu na skrajnej lewej pozycji", gdy mam wartość początkową na porcie C:
011111111
następnie po zanegowaniu:
100000000
i przesunięciu:
110000000
i ponownym zanegowaniu:
001111111
mogłoby tak być. Czy oznacza to, że jeżeli startowałbym od wartości:
101111111
negujemy:
010000000
przesuwamy:
001000000
oraz znowu negujemy :
110111111
powinno być wszystko ok ?
Pytam ponieważ nie działa to prawidłowo, natomiast bardzo mnie to dręczy.

------------------------ [ Dodano po: 5 minutach ]

Czy mógłbym prosić o wyjaśnienie jaki wpływ ma rzutowanie na działanie tego programu?

Statystyki: Napisane przez Mirog — 19 lis 2016, o 15:24

Re: Przesunięcie bitowe w prawo - problem

2016-11-19T15:07:51+01:00

Brawo Jazio!
O to chodzi.
Przesunięcie w lewą stronę oznacza przemieszczenie wszystkich bitów argumentu w lewo o określoną liczbę miejsc oraz wprowadzenie z prawej strony takiej samej ilości zer.
Przesunięcie w prawo oznacza przemieszczenie wszystkich bitów argumentu w prawo o określoną liczbę miejsc oraz powielenie najstarszego bitu na skrajnej lewej pozycji.
Dlatego problem występuje tylko dla przesunięcia w prawo.

Dodam jeszcze, że tą linijkę:
[syntax=c]PORTC = ~((uint8_t)(~PORTC)>>1);[/syntax]
można zastąpić:
[syntax=c]PORTC = ~( (~PORTC & 255)>>1 );[/syntax]
lub nawet:
[syntax=c]PORTC = ~( (255 - PORTC) >> 1);[/syntax]

Sprawdźcie sami!

Statystyki: Napisane przez anshar — 19 lis 2016, o 15:07

Re: Przesunięcie bitowe w prawo - problem

2016-11-19T15:07:01+01:00

Mirog napisał(a):

Czy to jakiś błąd kompilatora ?

Jak ja "kocham" takie wypowiedzi ... masakra .... jak tylko komuś coś nie działa - to zamiast szukać błędu u siebie to od razu "aaaa pewnie to wina kompilatora!" .... procka, scalaka itp itd .... no bo ja WSZYSTKO dobrze przecież zrobiłem ....

Jazio napisał(a):

Zapomnieliśmy chyba o domyślnej promocji do int.

Nie chyba a "na pewno" ... i rzutowanko na (uint8_t) załatwia jak widać sprawę jak należy

Statystyki: Napisane przez mirekk36 — 19 lis 2016, o 15:07

Re: Przesunięcie bitowe w prawo - problem

2016-11-19T11:14:32+01:00

Co ciekawsze przesuwanie w lewo w ten sposób:
[syntax=c]PORTC = ~((~PORTC)<<1);[/syntax]
realizowane jest jako suma wartości na PORTC z wartością PORTC oraz sumy bitowej wyniku z wartością "1", co oczywiście działa poprawnie jeśli chodzi o zamysł programu w C:
[syntax=asm]0000006c

:
6c:8f ef ldir24, 0xFF; 255
6e:84 bb out0x14, r24; 20
70:8e ef ldir24, 0xFE; 254
72:85 bb out0x15, r24; 21
74:85 b3 inr24, 0x15; 21
76:88 0f addr24, r24
78:81 60 orir24, 0x01; 1
7a:fb cf rjmp.-10 ; 0x72 [/syntax]
kiedy przesuwanie w prawo:
[syntax=c]PORTC = ~((~PORTC)>>1);[/syntax]
wykonywane jest już instrukcją Logical Shift Right (LSR) i faktycznie jak kolega Jazio zauważył brakuje tam instrukcji negacji bitów - COM (tak jakby dwie negacje w języku C się niwelowały). W przypadku:
[syntax=c]PORTC = ~PORTC;
PORTC = ~((PORTC)>>1);[/syntax]
oraz [syntax=c]PORTC = ~((PORTC = ~PORTC)>>1);[/syntax]
instrukcja negacji w kodzie ASM występuje podwójnie i wszystko działa jak należy.
Czy to jakiś błąd kompilatora ?

Statystyki: Napisane przez Mirog — 19 lis 2016, o 11:14

Re: Przesunięcie bitowe w prawo - problem

2016-11-18T19:25:45+01:00

Kopiuję prosto z Eclipsa. Reasumując, przesuwanie w lewo działa:

[syntax=c]int main(void)
{
DDRC = 0b11111111;
PORTC = 0b11111110;
_delay_ms(500);
while(1)
{
PORTC = ~((~PORTC)<<1);
_delay_ms(200);
}
}[/syntax]
W prawo nie chce:

[syntax=c]int main(void)
{
DDRC = 0b11111111;
PORTC = 0b01111111;
_delay_ms(500);
while(1)
{
PORTC = ~((~PORTC)>>1);
_delay_ms(200);
}
}[/syntax]

Chyba, że z zapisem:

[syntax=c]PORTC = ~PORTC;
PORTC = ~((PORTC)>>1);[/syntax]

lub jak kolega anshar podpowiedział:

[syntax=c]PORTC = ~((PORTC = ~PORTC)>>1);[/syntax]

Na zmiennej również próbowałem i nie działa nawet w takim zapisie:
[syntax=c]int main(void)
{
DDRC = 0b11111111;
uint8_t zm = 0b01111111;
_delay_ms(500);
while(1)
{
zm = ~((~zm)>>1);
PORTC = zm;
_delay_ms(200);
}
}[/syntax]

------------------------ [ Dodano po: 14 minutach ]

Na temat priorytetów również się zastanawiałem, jednak miałoby to sens, gdyby w obu przypadkach (przesuwanie w lewo i w prawo) nie działało. Jedyna różnica w sumie jaka jest to różnica w operatorach "<<" --> ">>". To tak jakby przesuwanie w prawo powodowało dopełnienie jedynkami gdzieś po drodze, no ale jak, dlaczego ?

Statystyki: Napisane przez Mirog — 18 lis 2016, o 19:25

Re: Przesunięcie bitowe w prawo - problem

2016-11-18T19:23:12+01:00

Chodzi tutaj o priorytety i łączność operatorów. Operatory "<<" i ">>" mają łączność lewostronną i mają wyższy priorytet niż operator przypisania "=", który ma łączność prawostronną. Dlatego stosuje się nawiasy, by to zmienić tak jak sobie programista życzy.

------------------------ [ Dodano po: 1 minucie ]

Zobaczcie w BB (strona 107).

Statystyki: Napisane przez anshar — 18 lis 2016, o 19:23

Re: Przesunięcie bitowe w prawo - problem

2016-11-18T19:10:11+01:00

Daro69, na zmiennej już próbowałem i jest to samo.

Statystyki: Napisane przez Mirog — 18 lis 2016, o 19:10

Re: Przesunięcie bitowe w prawo - problem

2016-11-18T19:09:20+01:00

myślę że na zmiennej, zamiast na PORTC - by się udało.
Może trzeba by się zagłębić w makro PORTC ?

Statystyki: Napisane przez Daro69 — 18 lis 2016, o 19:09

Re: Przesunięcie bitowe w prawo - problem

2016-11-18T19:09:27+01:00

Panowie, program oczywiście niczemu nie służy, po prostu trafiłem na niezrozumiałą dla mnie rzecz.

anshar, ten zapis:

[syntax=c]PORTC = ~((PORTC = ~PORTC)>>1);[/syntax]

działa poprawnie, jaka zatem jest różnica ? No i dlaczego przesuwanie w lewo z takim zapisem:

[syntax=c]PORTC = ~((~PORTC)<<1);[/syntax]

działa, natomiast w prawą stronę nie ?

Statystyki: Napisane przez Mirog — 18 lis 2016, o 19:06

Re: Przesunięcie bitowe w prawo - problem

2016-11-18T19:06:04+01:00

O kurczaki,
I mi się już pokićkało.

No bo to wydaje się logiczne.
zamiast pisać:
[syntax=c]PORTC = ~PORTC;
PORTC = ~(PORTC>>1);[/syntax]
To napisać:
[syntax=c]PORTC = ~((~PORTC)>>1);[/syntax]
Gdzie tu chochlik ?
Czy wartość PORTC pobierana jest do obliczeń tylko raz? czy co ?

Statystyki: Napisane przez Daro69 — 18 lis 2016, o 19:06

Re: Przesunięcie bitowe w prawo - problem

2016-11-18T18:59:57+01:00

Squeez, nie wiem jak pytający kolega, ale ja nie widzę. Zafiksowałem się czy cóś
Wg mnie to dokładnie to samo, biorąc pod uwagę negację portu we wcześniejszym wierszu:
[syntax=c]PORTC = ~PORTC;
PORTC = ~(PORTC>>1);[/syntax]

Statystyki: Napisane przez jerrylu — 18 lis 2016, o 18:59

Re: Przesunięcie bitowe w prawo - problem

2016-11-18T18:55:33+01:00

[syntax=c]#include
#include

int main(void)
{
DDRC = 0b11111111;
PORTC = 0b01111111;

while(1)
{

PORTC = ~((PORTC = ~PORTC)>>1);

_delay_ms(200);
}
}[/syntax]

Statystyki: Napisane przez anshar — 18 lis 2016, o 18:55

Re: Przesunięcie bitowe w prawo - problem

2016-11-18T18:47:56+01:00

Ciekawe zachowanie. W obydwu przypadkach PORTC jest i tak negowany przed przesuwaniem. Albo czegoś nie dostrzegam...
Nie mogę przetestować teraz na "żywym organizmie".
Tak, czy inaczej skoro i tak sam wpisujesz zawartość portu C,
to dlaczego wpisujesz w sposób wymagający negowania?
Dla uzyskania tego efektu wpisujesz odwrócone bity i nie negujesz ich już w kodzie przed przesuwaniem.

Statystyki: Napisane przez jerrylu — 18 lis 2016, o 18:47

Przesunięcie bitowe w prawo - problem

2016-11-18T18:07:25+01:00

Witam wszystkich bardzo serdecznie! Zaczynam dopiero swoją przygodę z programowaniem w języku C, dlatego proszę o wyrozumiałość. Posiadam zestaw ATB rev. 1.04b, podłączam diody LED do całego portu i próbuję "przesuwać" zapaloną diodę w lewo:

[syntax=c]int main(void)
{

DDRC = 0b11111111;
PORTC = 0b11111110;
_delay_ms(200);

while(1)
{
PORTC = ~((~PORTC)<<1);
_delay_ms(200);
}
}[/syntax]

w efekcie czego zapalona dioda "przesuwa" się z prawej do lewej. Podczas gdy próbuję "przesuwać" w drugim kierunku - w prawo:

[syntax=c]int main(void)
{

DDRC = 0b11111111;
PORTC = 0b01111111;
_delay_ms(200);

while(1)
{
PORTC = ~((~PORTC)>>1);
_delay_ms(200);
}
}[/syntax]

, diody kolejno mi się zapalają od lewej, wygląda to tak:
01111111
00111111
00011111
00001111
00000111
00000011
00000001
00000000

Co ciekawe, kiedy program wygląda tak:

[syntax=c]int main(void)
{

DDRC = 0b11111111;
PORTC = 0b01111111;
_delay_ms(200);

while(1)
{
PORTC = ~PORTC;
PORTC = ~(PORTC>>1);
_delay_ms(200);
}
}[/syntax]

wszystko działa jak należy, tzn. zapalona dioda "przesuwa" się:
01111111
10111111
11011111
11101111
11110111
11111011
11111101
11111110
11111111

w takiej sytuacji, postanowiłem napisać na forum z zapytanie czy ktoś z Państwa wie jak zinterpretować działanie programu przypadku, gdy stosujemy negację w jednym wyrażeniu?

Statystyki: Napisane przez Mirog — 18 lis 2016, o 18:07