Użytkownik "T.M.F." snipped-for-privacy@nospam.mp.pl> napisał w wiadomości news:hb790t$bbg$ snipped-for-privacy@nemesis.news.neostrada.pl...
Dokladnie, a warunkowego uzylem moze trzy razy w zyciu - kwestia wprawy.
To pisz tak dalej, przeciwskazań nie ma. K.
T.M.F. pisze:
Nie no, w MOIM ;) rozwiązaniu kolejność łatwo zmienić i jest ona "pewna", a w polach bitowych też łatwo zmienić, ale jest ona niepewna...
Poszukam gdzieś informacji, bo na pewno gdzieś to czytałem... ale czy to było wiarygodne źródło, to nie wiem... ale tak swoją drogą, robisz strukturę (zapis skrócony): Pole1 : 3 Pole2 : 4 Pole3 : 6 Pole4 : 1 Pole5 : 2
Proc o dostępie do pamięci bajtowym... jak pamięć przydzieli kompilator?? Jak wrzuci jak leci, to Pole3 będzie podzielone pomiędzy dwa bajty?? Czy może najstarszy bit zostanie "pusty" i Pole3 zacznie się od drugiego bajtu - wówczas całość zajmie 3 bajty... a może kompilator w ten 1 wolny bit pierwszego bajtu wrzuci Pole4??
Pozdrawiam Konop
man gcc
-mbit-align
Raczej orginalny pytacz pomylil sie z wyborem zawodu. Moja rada brzmi :
Nie zaleca się korzystać z pól bitowych jeżeli soft ma być kompilowany pod różnymi platformami gdyż standard NIE DEFINIUJE kolejności przypisania bitów.
W niektórych sytuacjach jest to bardzo istotna przeszkoda.
Pozdrawiam MiSter
In the darkest hour on Thu, 15 Oct 2009 14:47:53 +0200, T.M.F. snipped-for-privacy@nospam.mp.pl> screamed:
Zależnie od architektury CPU i od kompilatora. Jeśli zapiszesz strukturę z polem bitowym do pliku, taki plik nie będzie przenośny.
In the darkest hour on Wed, 14 Oct 2009 23:49:13 +0200, Adam Dybkowski snipped-for-privacy@45wp.pl screamed:
Bez przesady znowu z tą wydajnością. Różnice nieistotne zwłaszcza w przypadku programów z GUI. Dużo programów napisałem w Pythonie, dla Ciebie pewnie taki program stoi w miejscu i ani piśnie... ;) A dlaczego w nim? Szybciej, zwięźlej, czytelniej, przenośniej. Ale to już na jakieś advocacy.
In the darkest hour on Wed, 14 Oct 2009 15:17:47 +0200, Konop snipped-for-privacy@gazeta.pl screamed:
Z punktu widzenia programisty piszącego program w C jest to jedynie upierdliwe (mam tu na myśli tablice z const char *).
Zużywa na ARV niepotrzebnie RAM dla vtable w przypadku C++.
Użytkownik "Artur M. Piwko" snipped-for-privacy@buziaczek.pl napisał w wiadomości news: snipped-for-privacy@buziaczek.pl...
Podobnie jak swobodny strumien swiadomosci jest slabo przenosny, ale przeciez zdajemy sobie z tego sprawe, wiec bez przesady.
W dniu 15.10.2009 20:11, MiSTER pisze:
Ale to jak sadze jest raczej kwestia big/little-endian. Dla programu nie ma to znaczenia - o ile wlasnie nie przenosze pomiedzy architekturami danych wygenerowanych na innej. Bo w samym programie odwolanie do pola struktury zawsze bedzie jednoznaczne.
To akurat jest wada implementacji AVR w gcc i nie ma nic wspolnego z typami - implementacja funkcji wirtualnych i pokrewnych tematow jest calkowicie w gestii kompilatora. Nawet w jakims akcie desperacji probowalem wygenerowac stosowny patch dla gcc ale ciagle umieram w gaszczu kodu zrodlowego, poza tym w przyszlych wersjach ma to byc poprawione.
In the darkest hour on Thu, 15 Oct 2009 22:36:27 +0200, Ghost snipped-for-privacy@everywhere.pl screamed:
Nie wszyscy sobie z tego zdają sprawę. Usenet to nie tylko Ty i ja.
Użytkownik "T.M.F." snipped-for-privacy@nospam.mp.pl> napisał w wiadomości news:hb4gsl$bd$ snipped-for-privacy@atlantis.news.neostrada.pl...
Przepraszam, że się odzywam w temacie na którym się kompletnie nie znam. Na temat flag w postaci bitów w bajtach w AVR omawianych w kursie C na AVR w EP usłyszałem przed kilku laty mniej więcej taką wypowiedź: "Jak można podawać takie przykłady! Przecież trzeba znać maszynę, na której program będzie chodził. Widać, że ktoś bezmyślnie przepisał przykład z 51 na AVR. Potem ludzie tak napiszą i mamy to co mamy." Z tego co pamiętam to chodziło o to, że przestawienie bitu w bajcie na AVR wymaga więcej niż jednego rozkazu. No i w przykładzie przyjście przerwania miedzy tymi rozkazami prowadziło do błędu. Liczę na to, że ktoś piszący na AVR wypowie się na ten temat (bo nawet nie jestem pewien, czy te pretensje były uzasadnione). Z przebiegu wątku wygląda, że jego autor być może powstawia flagi do bajtów co być może doprowadzi do nowych błędów. No i chęć zapobiegnięcia temu skłoniła mnie do tej dość mętnej wypowiedzi. P.G.
To kompilator ustala kolejnosc bitwo we bajcie, np GCC vs propriety compiler: typedef union { unsigned short word; #ifndef __GNUC__ struct { unsigned short :1; /* reserved */ unsigned short CodeAssertLine :13; unsigned short EventOverflowTrigger :1; unsigned short EventCodeAssertTrigger :1; } bit; #else struct { unsigned short EventCodeAssertTrigger :1; unsigned short EventOverflowTrigger :1; unsigned short CodeAssertLine :13; unsigned short :1; /* reserved */ } bit; #endif
aczkolwiek GCC dostarcza makra __BIG_ENDIAN_BITFIELD oraz __LITTLE_ENDIAN_BITFIELD informujace o ukladzie bitow w slowie
struct atapi_mechstat_header { #if defined(__BIG_ENDIAN_BITFIELD) __u8 fault : 1; __u8 changer_state : 2; __u8 curslot : 5; #elif defined(__LITTLE_ENDIAN_BITFIELD) __u8 curslot : 5; __u8 changer_state : 2; __u8 fault : 1; #else #error "Please fix <asm/byteorder.h>" #endif
#if defined(__BIG_ENDIAN_BITFIELD) __u8 mech_state : 3; __u8 door_open : 1; __u8 reserved1 : 4; #elif defined(__LITTLE_ENDIAN_BITFIELD) __u8 reserved1 : 4; __u8 door_open : 1; __u8 mech_state : 3; #else #error "Please fix <asm/byteorder.h>" #endif
byte curlba[3]; byte nslots; __u8 short slot_tablelen; };
Nie endian mowi o kolejnosi bajtow w slowie :
Oczywiscie dopoki nie jest to unia i odwolujesz sie do niej zarowno przez pola bitowe jak i slowa ;)
AVR ma pewne wydzielone obszary pamieci na ktorych dzialaja instrukcje umozliwiajace atomowe ustawienie lub wyzerowanie bitu, tylko, ze nie mozna tego zrobic w SRAM, tylko w niektorych rejestrach IO. Niektore AVRy maja w tej przestrzeni rejestry, ktore nie maja zadnej funkcji, poza wlasnie przechowywaniem flag. Wiec da sie to zrobic atomowo, tyle, ze to juz nie jest standardowe C.
W dniu 16.10.2009 13:24, cepu69 pisze:
Dokladnie, a to w przypadku pol bitowych o dlugosci wiekszej niz bajt powoduje, ze np. bity 8-15 moga byc przed lub za bitami 0-7. Natomiast w ramach bajtu kolejnosc bedzie zachowana i w konsekwencji w programie rowniez.
Owszem, zawsze znajdziesz przyklad, ktory cos zamiesza. Z tym, ze jesli to bedzie unia pola bitowego i slowa to endian nie ma znaczenia - wplywa tak samo na kolejnosc przechowywania bitow jak i kolejnosc przechowywania bajtow w slowie. Gorzej, gdybys mial unie pola bitowego i bajtow - tu juz by powstalo zamieszanie. Z drugiej strony sa biblioteki standardowe umozliwiajace rozwiazanie tego typu problemow. Poza tym o czym dyskutowac - programowanie nie jest dla idiotow i ktos kto robi takie rzeczy musi sobie zdawac sprawe z konsekwencji. Standard C definiuje kolejnosc bitow pola bitowego, co wiecej uzycie pola bitowego :0 wyrownuje kolejne do granicy okreslanej przez design procesora.
Użytkownik "T.M.F." snipped-for-privacy@nospam.mp.pl> napisał w wiadomości news:hb9lor$hs6$ snipped-for-privacy@atlantis.news.neostrada.pl...
A da się atomowo zapamiętać w bicie flagę przeniesienia, zrobić and czy or bitu z tą flagą czy odwrócić bit rejestru, bo to mogło też o takie rzeczy chodzić ? P.G.
Da sie zapamietac przeniesienie atomowo w szczegolnych przypadkach - stosujac operacje przesuniecia z przeniesieniem, lub dodawania, odejmowania - to jak w kazdym procesorze. Co do OR, AND, XOR flagi C z innym rejestrem to sie nie da atomowo. Znaczy XOR to by sie nawet dalo, z zastrzezeniem, ze w szczegolnych przypadkach. 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.
Niekoniecznie prowadzi do błędu... wszystko zależy od tego, co się z tym rejestrem w międzyczasie stanie... Typowo ustawianie bitu w jakiejś zmiennej (która siedzi w RAMie) wygląda tak:
-pobieranie zmiennej do rejestru
-operacja na rejestrze
-zapis zmiennej do RAMu
Jeśli po pobraniu i przed zapisaniem wystąpi przerwanie, które ZMIENI tę zmienną, wówczas po powrocie z przerwania program główny skasuje zmianę dokonaną w przerwaniu... 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 ;)...
Pozdrawiam Konop
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.