elvis napisał(a):
Po pierwsze używasz liczb 16-bitowych,
Ło matko - a to kolega jak rozumiem, na prockach 8-bitowych używa liczb tylko 8-bitowych? Na prockach 16-bitowych tylko liczb 16-bitowych, zaś na prockach 32-bitowych tylko liczb 32-bitowych ?
Sorki ale takie wrażenie można odnieść już po tej części wypowiedzi
elvis napisał(a):
po drugie przesunięć o wiele bitów.
Ło żesz w mordkę, czy mam rozumieć, że po wielu latach coś się zmieniło w zakresie programowania i lepiej jest używać przesunięć tylko o kilka bitów zamiast wielu bitów ? Poważnie ? to jest problem dla 8-bitowca ?
Panie kochany - 4-bitowiec sobie by z tym świetnie poradził a nawet 1-bitowy mikrokontroler
a co dopiero 8-bitowy ...
elvis napisał(a):
Optymalizator stara się zmniejszyć liczbę koniecznych instrukcji i jeśli wykona to źle, program chociaż napisany poprawnie, może działać błędnie.
No no - to blady strach powinien paść na wszystkich którzy używają 8-bitowców - co to też te optymalizatory wyprawiają ? No włosy dęba stają na głowie ! ... nie do wiary .... eeeeeh takie błędy - i cóż my programiści mamy począć ? a szczególnie na 8-bitowchach ...
elvis napisał(a):
Oczywiście kompilatory na układy 32-bitowe też mogą mieć błędy, ale wspomniany kod nie wymagałby karkołomnej optymalizacji.
Qurczę - jeszcze lepiej - no to nawet nie ma co się przesiadać na 32-bitowe procki - skoro też wszystkie kompilatory przy TAK POWAŻNYCH jak kolega twierdzi i BARDZO SKOMPLIKOWANYCH operacjach żeby nie powiedzieć KARKOŁOMNYCH - mylą się .... no to chyba trza porzucić w ogóle programowanie - toż to zgroza - same błędy kompilatorów ... ojo jooooj .... ło la boga !
Teraz już na poważnie
elvis napisał(a):
Najlepiej byłoby sprawdzić, jaki kod maszynowy jest generowany przez kompilator. Testowałem na wersji 4.8.1 avr-gcc i program wynikowy wyglądał poprawnie, zarówno z volatile, jak i bez.
I od tego warto zaczynać - zamiast wypisywać takie steki bzdur jak wcześniej
Sorki ale już dawno nie widziałem tak karkołomnych wyjaśnień problemu - żeby jak się czegoś nie wie - to zwalać już nie tylko na kompilator ale i na 8-bitowce a do tego - jeszcze i 32-bitowe kompilatory batem przejechać
Gdyby kompilatory miały się mylić w TAK PODSTAWOWYCH - zaznaczam TAK PODSTAWOWYCH operacjach .... to lepiej byłoby wyrzucić je wszystkie do kosza i pisać w ogóle od razu w kodach HEX nawet bez używania asemblera
wtedy byłoby najpewniej ?
elvis napisał(a):
O zmianie mikrokontrolera nawet nie wspomnę, ale może w przyszłości też warto.
Panie Panie no ale po co ? skoro 32-bitowe kompilatory też zawierają błędy
... wszędzie błędy, same błędy ... błąd błędem pogania - wszyscy robią dokoła źle tylko nie ja
No istny popis (przepraszam kolegę za określenie) ignorancji
zamiast próbować wyjaśnić problem to popisówka o tym, że biedny czarny, słaby, wątły chudy 8-bituś ze spierniczonym kompilatorem, nie potrafi nawet byle przesunięć bitowych zrobić - więc wyrzucić trzeba go do kosza na śmieci i wziąć 32-bitowca - wtedy też będzie spierniczony kompilator ale może dzięki 32-bitom zdarzy się kompilatorowi mniej błędów przecież ... no ba! ...
Sory za ten ton - ale na tym forum będę piętnował i pokazywał kompletny NONSENS takiego podejścia a szczególnie brednie o wyższości jednych mikrokontrolerów nad drugimi i nie ważne o jakie rodziny chodzi czy 8bit vs 32-bit, czy Microchip vs Atmel chociaż teraz to już jedno
czy STM vs coś tam coś tam. Od takich dywagacji masz pan inne fora ok ? i tam zapraszam do dyskusji na takie tematy jeśli tolerują.
---------------------------------------------------------
do autora wątku - OCZYWIŚCIE że musi działać bez volatile dla zmiennej a, bo nawet tak jak czarnowidz kompilatorów wyżej powiedział - kod się kompiluje poprawnie
bez volatile i działa poprawnie
dlatego szukałbym dalej rozwiązania tej zagadki bo pewnie gdzieś popełniasz błąd - ale jaki ? któż to wie ?
nie wiemy właśnie ani z jakiej wersji kompilatora korzystasz, ani z jakich w nim przełączników kompilacji, ustawień - choćby ustawień samej optymalizacji - czy np -Os ?