Witam,

spotkałem się z takim zapisem i nie jestem pewien czy dobrze to rozumiem:



Moje pytanie jak będzie wyglądała wartość wpisana do zmiennej nextbit. Typ unsigned char ma jeden bit, więc podejrzewam, że wynik będzie zapisany binarnie. W związku z tym wyobrażam sobie dwie możliwości:



Nie wiem czy/i któraś jest prawidłowa. Bardzo proszę o pomoc

Coś tu przekombinowałeś.
Typ char to nie jeden bit tylko bajt, a każdy wynik/liczba w komputerach jest zapisywana binarnie.
Natomiast sam wynik operacji logicznej będzie 0 lub 1.

To jeszcze dwa pytania:
1.Zastanawia mnie jak to działa. Bo to są rożne typy. Wynik z typu unsigned long wpisujemy do char, to zachodzi tutaj jakaś niejawna konwersja.
2. Dlaczego np. nie użyto tutaj typu bool jeśli chce się przechować stan 1 lub 0 tylko akurat char jak do stringa?

Bo w C nie ma typu "bool" (No może i jest). A wyniki operacji logicznych zwracane są do typów całkowitych, może to być char, int, uint8_t bez różnicy.

Nie ma żadnej konwersji. Do zmiennej nextbit zwracany jest wynik operacji logicznej != co daje 0 lub 1.

1) Sprawdź jak wygląd plik stdbool.h masz tam coś w tym stylu:
Ponieważ wykonujesz operację logiczną & której wynikiem może być tylko 1 lub 0, kompilator nie mógł by przypisać tam czegoś innego niż 1 lub 0. Tak czy siak zmiennej zostanie przypisany rozmiar równy rozmiarowi komórki pamięci w zależności od procesora czyli w 8 bitowym będzie to 8bit (tyle samo ma char), kompilator nie dzieli jednej komórki pamięci na pojedyncze bity po jednym dla każdego boola, bo procesor nie był by w stanie takich komórek zaadresować (adresowane są 8 bitowe komórki, a nie pojedyncze bity).

2) Ciężko powiedzieć na podstawie 4 liniowego wycinku kodu co autor miał na myśli nadając taki typ. Być może to ma być potem przekazane jako adres do odczytu z tablicy i później jest dalej przeliczane, może jest przekazywane jako argument do funkcji która przyjmuje typ char, albo miał taki kaprys wiedząc że i tak tyle samo pamięci zajmie bool jak i char. W kwestii nazewnictwa zmiennych to nazwa zmiennej powinna sama się tłumaczyć, tak samo nazwa funkcji/metody itp. więc tu zmienna przechowuje 1 bit jak w nazwie nextbit, może to trochę mylące, że nie ma typu bool ale nazwa tłumaczy co będzie w zmiennej.

Akurat tu się nie do końca zgadzam. Są procki które umożliwiają adresowanie bitowe (pewnych obszarów pamięci), jak również mają instrukcje asm do operowania na poszczególnych bitach. To jest bardziej cecha i ograniczenie C niż samych procesorów.

Nie, wartość nextbit = 1 to 1, a nie 255.
Czyli nextbit = 0b00000001;

Jeśli wpiszesz coś takiego
nextbit = 0b11111111;
To będzie tak jak w Twoim przykładzie


Nie spotkałem się z takimi procesorami, adresowanie pojedynczych bitów wydaje mi się w ogóle mocno nietrafionym pomysłem, ponieważ potrzebny jest adres komórki pamięci, która przechowuje sam bit, plus kolejna komórka pamięci na samą maskę bitową. Co daje wolniejszy zapis, wolniejszy odczyt i większe zużycie pamięci, jedyne miejsce gdzie to miało by sens to CPLD i FGPA bo tam bit to po prostu wyjście układu bramek/LUT, wiec operujesz na tylu bitach na ilu trzeba.
Jak masz jakieś info gdzie można poczytać o uC z adresowaniem bitowym będę wdzięczny za link albo cośkolwiek, bo zainteresowałeś mnie tym.

Poczytaj o zamianie liczb dziesiętnych na binarne i odwrotnie bo:
0b11111111 = 255; a nie 1.
0b00000001 = 1;
Reszta Ok, tylko nie wiem czemu ma to służyć, bo na porcie nic się nie zmienia.

------------------------ [ Dodano po: 8 minutach ]


To zajrzyj do noty dowolnej atmegi. Nawet one mają bitowe adresowanie obszaru I/O. A na dowolnym rejestrze możesz wykonać operacje ustawienia/odczytu pojedyńczego bitu.

------------------------ [ Dodano po: 42 minutach ]

Dodam jeszcze, że takie obszary pamięci adresowane bitowo były dostępne na takich dziadkach jak 8051 i są dostępne na współczesnych 32 bitowcach.
Poczytaj np. o bitbanding'u.
Tak, że z tym nietrafionym pomysłem niestety ale nietrafiłeś. Jest to bardzo wydajne rozwiązanie.

Mówisz o operacjach bitowych na SFR, to nie jest adresowanie pojedynczych bitów, masz po prostu w OPCODE instrukcji zaszyty adres komórki pamięci i numer bitu, ewentualnie ustawiasz maskę na numer bitu w rejestrze. Zastanów się dlaczego instrukcja SBI (Set Bit in I/O Register) wymaga 2 cykli zegara, a instrukcja MOV (Move Between Registers) oraz MOVW(Copy Register Word) wymagają tylko po jednym cyklu, pomimo że MOVW przenosi 16b w 8 bitowym procku.

No ale tak to jest realizowane, jest obszar adresowy bitowo, a takie same adresy ma również standardowo adresowana pamięć.
Aby było jednoznaczne do czego się odwołujesz, używa się różnych instrukcji asm.

------------------------ [ Dodano po: 16 minutach ]

Masz link np. do architektury 8051 który ma obszar adresowany bitowo:
http://staff.uz.zgora.pl/mkoziol/mcs51/budowa51/pamiec.html
Natomiast jak zajrzysz do listy rozkazów avr, są tam instrukcje:
SBR, CBR, SBRS, SBRC.
Nic nie stoi na przeszkodzie aby tworzyć zmienne/flagi typu bool które będą zajmowały w pamięci tylko jeden bit.

Nie stworzysz zmiennych które zajmują tylko jeden bit ponieważ:
1) Pamięć jest adresowana co 8 bitów, więc musisz zaadresować CAŁY bajt
2) Dopiero w bajcie możesz ustawiać/kasować bit.
Z tego wynika, że musisz zająć 2 bajty żeby zaadresować pojedynczy bit albo możesz zająć 1 bajt robiąc to tak jak teraz się to robi.

Jeśli masz blok pamięci jak niżej

Jak chciał byś zaadresować 5 bit w komórce 0x1 wykorzystując 1 bit ?
SBR 0x01, #5 ; już masz 8 bitów na ustawienie 1 (nie wiem czy w AVR będzie dokładnie tak wyglądała składnia asm)

Żeby stworzyć pamięć "adresowaną" bitowo musiał byś najpierw zaadresować bajt na dane, a później dla każdego bitu wykorzystać cały kolejny bajt na numer bitu lub maskę (gdzieś trzeba zapisać numer bitu dla instrukcji SBR, CBR, SBRS, SBRC), w ten sposób otrzymujesz boola który zajmuje 2 bajty... rezultat jest gorszy niż aktualne rozwiązanie w C. Jak byś chciał sterować wykonywaniem kodu dla odczytania 1 boola, to miał byś 1-3 cykle zegara na sam SBRS/SBRC, nie wspominając o zajęciu co najmniej 2 bajtów pamięci programu na instrukcję i pomijaną instrukcję plus 1 bajt na wartość domyślną, w sumie masz 3 bajty progmem + 1 bajt w ramie i 3-5 cykli zegara, nie wspominając że taka zmienna była by po prostu małym podprogramem więc jeszcze instrukcja skoku, albo powielanie tych kilu instrukcji w każdym odwołaniu do zmiennej.
Natomiast stary dobry MOV zajmuje 1 bajt i przenosi 8/16 bit za jednym cyklem zegara.
Podobnie działają pola bitowe w strukturach, masz dane na jednym bajcie, a przesunięcia bitowe kompilator przypisuje w czasie kompilacji - w dalszym ciągu adresuje 1 bajt i porównuje go z maską/przesunięciem bitowym.

Tak na chłopski rozum, jak mi to jeszcze w technikum tłumaczył nauczyciel. Bajt to jak szuflada z 8 przegródkami, najpierw kompilator musi wiedzieć która szufladę ma wysunąć, a później z której przegrody coś Ci podać. Jeśli ktoś by Tobie powiedział podaj mi coś z 2 przegrody, w sytuacji kiedy masz 1000 szuflad to byś spojrzał na takiego delikwenta z politowaniem i tyle. Właśnie tak działa pamięć w uC; w 8051 czyli architekturze Harvardzkiej masz jeszcze banki pamięci w których są umieszczone SFR jak i ogólny RAM, do przykładu powyżej każdy bank to szafka z szufladami.

Pozwolę się nie zgodzić z tobą. Lata temu pisałem w asm zarówno na 8051 jak i na AVR kiedy jeszcze nawet atmeg nie było.
Wykorzystywałem pojedyncze bity na flagi o ile były mi potrzebne. Nikomu wówczas nie przyszło do głowy, aby na jeden bit tracić cały bajt. Ale to były inne czasy.
Po przesiadce na C byłem "w szoku", że tego nie oferuje.
Wiadomo, że jak masz tylko 1 bit to i tak tracisz cały bajt. Ale przy 8 bitach możesz spokojnie wykorzystać jeden bajt na 8 różnych flag.
W C też się to da uzyskać, ale musisz albo zadeklarować unię, albo maskować. I uzyskasz wówczas dostęp do poszczególnych bitów. Czyli się da, tylko kompilator C wprost sam z siebie tego nie oferuje.
Aby to uzyskać nie rezerwuje się w pamięci dla osobnych adresów na bajt i nr bitu, tylko tworzysz odpowiedni kod który odpowiednio odczytuje/zapisuje dane tam gdzie chcesz.
Dla zobrazowania przykład:

i Jak chcesz coś zapisać do flagi to w asm byłoby:

a teraz wyzerowanie drugiej flagi:


I ile pamięci zostało wykorzystane. I myślisz, że kompilator nie byłby wstanie tego ogarnąć?

------------------------ [ Dodano po: 20 minutach ]

Moim zdaniem jeżeli chodzi o C, to niestety kuleje jeżeli chodzi o operacje 1 bitowe.
Najprostszy przykład skasowanie jednego bitu na wyjściu PORT'u.
W asm jedna linijka:

A w C pobierz stan portu, zaneguj maskę, zrób AND, dopiero ustaw port.
Kompilator długo nie wiedział o instrukcjach sbi, cbi, na szczęście od jakiegoś czasu już to ogarnia.
Aby była jasność odkąd przesiadłem się na C już nie wróciłem do asm (i większość rzeczy zapomniałem).
Nie ma porównania jeżeli chodzi o szybkość tworzenia kod, jego czytelność itd.
Z jego brakami można żyć i po przyzwyczajeniu się, nawet się tego nie odczuwa.
Natomiast nie jest to język idealny i część rzeczy których w nim nie ma, nie wynika z tego że procesory tego nie oferują tylko, taka specyfika języka.

Potrzebne jest 8bit na rejestr przechowujący flagi - tu się zgadzamy
Powiedz mi jak odczytasz te flagi bez 8b maski albo kilku zbędnych instrukcji ASM

Ta lektura bynajmniej nie potwierdza Twojej tezy.

_________________
Think for yourself and question authority.

Tak zgadzam się, przy 1 bicie i tak trzeba zająć cały bajt, ale przy większej ilości flag, ma to sens.

Tak jak pisałem wyżej, już całe lata nie pisałem w asm, ale spróbuję.
Najczęściej flaga jest po to aby sygnalizowała jakiś stan.
Czyli nie musimy jej odczytywać po to aby zapisać do innej zmiennej, tylko sprawdzamy jej status i wykonujemy jakiś kod.
Czyli używamy instrukcji do testowania stanu bitu:
w c

w asm,

I bez narzutu w dodatkowych operacjach, czy cyklach.
Natomiast jak już chcesz odczytać stan bitu i go gdzieś zapisać to:

Czyli w sumie 2 cykle zegara.
Widzisz, ja tu problemu z wydajnością nie widzę.
Owszem czasami będą dodatkowe instrukcje ale to specyfika procesorów RISC które jednak mają tych instrukcji mniej.
Z drugiej strony czasami ważniejsza jest optymalizacja pamięci, lub np. atomowość niż sama wydajność kodu .
Wszytko zależy od zastosowania.

------------------------ [ Dodano po: 8 minutach ]


Nie wiem czy chcesz się czegoś dowiedzieć, czy coś mi chcesz udowodnić.
Jeżeli punk 1 to mogę jeszcze Ci coś napisać.
Jeżeli 2 to zakończmy tą dyskusję i każdy niech pozostanie przy swoim zdaniu.
Każdy ma prawo do swojej opini.
Twierdziłeś,że procesory nie mogą adresować poszczególnych bitów.
Podesłałem Ci mapę 8051 gdzie tam jest wprost adresowanie bitowe.
Podesłałem Ci informację o bitbandingu który się stosuje właśnie po to aby bezpośrednio operować na bitach a ty Ciągle, że to nie potwierdza mojej tezy.

------------------------ [ Dodano po: 10 minutach ]

Sorry nie zwróciłem uwagi, że to kto inny.

------------------------ [ Dodano po: 11 minutach ]


To niby jakiej tezy?

Na wstępie, żeby rozwiać ewentualne wątpliwości, jestem zwolennikiem kulturalnej dyskusji na argumenty, a takową zwykle obie strony kończą zadowolone, nawet jeśli nie uda się uzyskać konsensusu.

W kwestii wspomnianego wcześniej bitbanding'u, domyślam się, że chodzi o PMP (Parell Master Port) i podłączanie np. zewnętrznej pamięci do całego portu, co umożliwia równoległą transmisję danych z względnie duża prędkością. Rozwiązanie to nie daje nagle bitowi własnego adresu na magistrali, w dalszym ciągu operuje się na porcie (bajcie SFR) i numerach bitów. Budowa procesorów nie pozwala i nie pozwalała na adresowanie pojedynczego bitu, pozwala na adresowanie całego bajtu i wyłuskanie bitu po numerze i ta kwestia się raczej nie zmieni w najbliższym czasie.


Przyznam, że "zintegrowanie" bitu rejestru z kodem programu, znacząco poprawia sytuację w kwestii marnowania pamięci jak i cykli zegara.
Ciekawe rozwiązanie, umieścił bym je obok ztablicowanych wartości np. sin/cos (w gruncie rzeczy bardzo podobnie to działa), w niewielkim stopniu ogranicza możliwości operacji na zmiennej (trudniej ustawić takiego boola jako element operacji matematycznej) ale z pewnością oszczędza miejsce.

O ile z samym nazwaniem tego adresowaniem bitowym się nie zgodzę, ponieważ adres ma komórka pamięci, a bit ma numer, to muszę oddać koledze, że udowodnił sensowność tego pomysłu.

Tylko, że to nie ja wymyśliłem takie określenie. Po prostu takie się znajduje w różnych materiałach. To tylko określenie pewnego mechanizmu.
Nie da się ukryć, że procesory mogą wykonywać operacje na poszczególnych bitach i to robią, natomiast nie każdy kompilator wykorzystuje wszystkie te możliwości.
Jak przeczytasz to co pisałem, to zwróć uwagę, że nigdzie nie napisałem, że taka możliwość obejmuje pełną przestrzeń adresową.
Co do przykładu z umieszczeniem takich flag w przestrzeni rejestrów. Tak będzie to szybkie i skuteczne a przy tym można zaoszczędzić RAM.
Z tym, że nic nie stoi na przeszkodzie, aby tak zorganizowane flagi umieścić poza obszarem rejestrów.
Dojdzie operacja załadowania danej do rejestru, ale zauważ, że generalnie tak to działa. Na przykład jeżeli dodajesz dwie zmienne typu bajt,
to najpierw te zmienne są wczytywane do rejestrów a potem dodawanie odbywa się już na rejestrach (instrukcja ADD). Wynik dopiero z rejestru jest wrzucany z powrotem do RAM. I jakoś nikt nie krzyczy, że to jest nieefektywne. Po prostu tak to działa i już. No w C może jest jeszcze inaczej bo tam jest jeszcze domyślna promocja do int, ale nigdy nie analizowałem, co tak naprawdę kompilator tworzy.
Co do samego pakowania kilku flag do jednego bajtu, może i to nie ma wielkiego sensu w przypadku dużych procesorów.
Ale w przypadku maluchów jest o co walczyć. Każdy bajt ma znaczenie. Zajmowanie ram'u po 1 bajcie na każdą 1 bitową flagę jest moim zdaniem marnotrawstwem.
I dla mnie jest to "ograniczenie" C, a nie brak fizycznych możliwości procesorów w tym zakresie. Pisząc w asm nie stanowi to problemu.
Jasne jest taki wybór procesorów, że w ogóle nie ma problemu, dobiera się procesor odpowiedni do zadania i można wziąć większy.
Zwrócę uwagę na jeszcze jedną istotna sprawę. Operowanie bezpośrednio na bitach daje atomowość.
W C poprzez maskowanie i sekwencje odczytaj, modyfikuj zapisz tą atomowość się traci. Można się przez to wpakować w tarapaty, a przyczynę znaleźć ciężko.

------------------------ [ Dodano po: 32 minutach ]


Nie tu chodzi o zupełnie inny mechanizm:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/Behcjiic.html