W dniu 15.10.2009 20:11, MiSTER pisze:
>> Cos sie zapetliles, to w koncu te pola bitowe sa rozmieszczane dowolnie
>> czy nie?
>> IMHO kompilator rozmieszcza je w kolejnosci w jakiej sa zdefiniowane - w
>> koncu to struktura, a elementy struktury wystepuja w kolejnosci zgodnej z
>> definicja.
>
> 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.

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.

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

do góry

>> jest jak zwykła zmienna. W komputerach klasy PC stałe (const) trzymane
>> są w pamięci RAM, bo nie ma innego wyjścia. W ARMach trafiają do pamięci
>> Flash z reguły, bo jest jedna przestrzeń adresowa. Czemu dla AVRów
>> miałby być wyjątek??
>
> Zużywa na ARV niepotrzebnie RAM dla vtable w przypadku C++.

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.

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

do góry

In the darkest hour on Thu, 15 Oct 2009 22:36:27 +0200,
Ghost <g...@e...pl> screamed:
>>> Cos sie zapetliles, to w koncu te pola bitowe sa rozmieszczane dowolnie
>>> czy nie?
>>
>> Zależnie od architektury CPU i od kompilatora. Jeśli zapiszesz strukturę
>> z polem bitowym do pliku, taki plik nie będzie przenośny.
>
> Podobnie jak swobodny strumien swiadomosci jest slabo przenosny, ale
> przeciez zdajemy sobie z tego sprawe, wiec bez przesady.
>

Nie wszyscy sobie z tego zdają sprawę. Usenet to nie tylko Ty i ja.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:237B ]
[ 08:31:25 user up 12227 days, 20:26, 1 user, load average: 0.18, 0.04, 0.45 ]

Bigamy is having one wife too many. Monogamy is the same. -- Oscar Wilde

do góry

Użytkownik "T.M.F." <t...@n...mp.pl> napisał w wiadomości
news:hb4gsl$bd$1@atlantis.news.neostrada.pl...
>> A za to jest bardzo fajna właściwość, bo można zadeklarować zmienne
>> pełniące rolę dwustanowych flag jako "bool". Podejrzewam, że nie zajmują
>> wtedy całego bajtu. Jeśli tak , to przydało by się coś takiego w
>> programowaniu ATmegi. Kupę RAM-u zajmują flagi. Duże marnotrawstwo.
>> Bawienie się w maski, to znów przystosowywanie się do kaprysów komputera.
>
> Przejrzyj liste instrukcji AVR i nie bedziesz mial zludzen. Mozesz
> zadeklarowac zmienna bool, mozesz wykorzystac pola bitowe, ale to ciagle
> bedzie tlumaczone na operacje na bitach typu ustawianie, zerowanie itd.
>
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.

do góry

T.M.F. wrote:

> W dniu 15.10.2009 20:11, MiSTER pisze:
>>> Cos sie zapetliles, to w koncu te pola bitowe sa rozmieszczane dowolnie
>>> czy nie?
>>> IMHO kompilator rozmieszcza je w kolejnosci w jakiej sa zdefiniowane - w
>>> koncu to struktura, a elementy struktury wystepuja w kolejnosci zgodnej
>>> z definicja.
>>
>> 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.
>>
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;
};

>
> Ale to jak sadze jest raczej kwestia big/little-endian.
Nie endian mowi o kolejnosi bajtow w slowie :
http://pl.wikipedia.org/wiki/Kolejność_bajtów

> 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.
Oczywiscie dopoki nie jest to unia i odwolujesz sie do niej zarowno przez
pola bitowe jak i slowa ;)

do góry

> 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.

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.

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

do góry

W dniu 16.10.2009 13:24, cepu69 pisze:
>> Ale to jak sadze jest raczej kwestia big/little-endian.
> Nie endian mowi o kolejnosi bajtow w slowie :
> http://pl.wikipedia.org/wiki/Kolejność_bajtów

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.

>> > 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.
> Oczywiscie dopoki nie jest to unia i odwolujesz sie do niej zarowno przez
> pola bitowe jak i slowa;)

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.



--
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:hb9lor$hs6$1@atlantis.news.neostrada.pl...
> 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.

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.

do góry

>> 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.
>
> 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ć ?

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.


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

do góry

> 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.

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

do góry