bitfield v avr-gcc

Miroslav Sinko sinkomiro@rocketmail.com
Pondělí Červen 16 18:40:48 CEST 2008


--- On Mon, 6/16/08, Jan Waclawek <konfera@efton.sk> wrote:

> From: Jan Waclawek <konfera@efton.sk>
> > Mozes mu poslat bitove pole 2x (pomocou pointera na
> cele pole a sizeofu to vies). V prvom poli bude maska,
> ktore flagy sa maju prevziat a v druhom budu mat tie flagy
> hodnotu, ktoru pozadujes.
> 
> Super, takze miesto 1-2  byte offsetu budem posielat
> vsetkych 144 bitov, a to este dvakrat...
> Nie je to neprekonatelny problem si to dat na fixny ofset,
> takze riesenie existuje, som sa len spytal, ci uz na to
> niekto nemyslel a nevymyslel hack.

No ale to si sam protirecis. Predtym si napisal toto:

> Pointa tych bitovych poli by mala byt presne v tom istom
> ako je vobec pointa pouzivat miesto asembleru makroasembler
> zvany C; t.j. aby nieco co moze urobit stroj aj ten stroj
> urobil. Ak si mam sam definovat kde co je a v akom poradi,
> tak to mozem robit priamo v asembleri.

Takze ak sa nechces starat o to, kde je co v bitovom poli, sam vylucujes "pointer", offset a pod. Moznost ako sa o to nestarat, som napisal. Jednoducho na cielovej strane vezmes masku a platne bity - v cielovej strukture podla nich nastavis tie spravne flagy na spravne hodnoty bez znalosti offsetov, jednoduchymi maskovaniami celych bytov bez znalosti ktory flag je kde. Jednoduche. O 144 bitoch pises az teraz. K efektivite prenosu 2x 18 bytov sa nemam ako vyjadrit, nepoznam Tvoj system. 

> > Podla mojho nazoru nepojde ani toto, lebo bitove pole
> z principu nemusi obsahovat len 1-bitove flagy, ale aj
> viacbitove polozky, ktore sa mozu prelievat z bytu do bytu.
> 
> Presne ako pointer na akykolvek viacbytovy typ, ktory sa
> tiez moze (a nemusi, kedze toto je presne ako bitfieldy
> implementacne zavisle) prelievat cez hranice zarovnanych
> oblasti u 16/32/64 bitovych procesorov. Toto vsetko moze
> riesit stroj (prekladac) bez toho aby sa tym musel clovek
> zapodievat.

Iste, C nema problem ziskat pointer na lubovolnu premennu v "nebitovej" strukture, hoci su cleny struktury zarovnane. Pointer ale ukazuje na cely byte a z principu kazdy clen zacina na celom byte. V bitovej strukture to tak ale nie je... Potreboval by si uplne iny typ poinetra, nejaky 2 zlozkovy.
 
> > Akoze ukazat povedzme na zaciatocny bit takej polozky
> (byte a bit) by mozno nejako uzitocne mohlo byt, ale ono sa
> bitfield pouziva iba tak, ze si jednoducho priradis hodnotu
> danej polozky z pola do premennej a s tou dalej pracujes,
> podobne v cykloch, podmienkach, predavani do funkcie...
> 
> Ale ale, cele C je predsa o porusovani principov
> programovania vo vyssich jazykoch, obvykle v mene vyssieho
> principu zvanom efektivita. 50% pouzitia pointrov v C je
> presne o tomto. Samotna existencia sizeof je o tomto istom
> - vo vyssom jazyku Ta nema co zaujimat velkost cohokolvek.
> Nehovoriac o memcpy a spol.  Tie pointre ci co do
> bitfieldov sa predsa daju implementovat rovnako - ako
> nestandardne kniznicne (zabudovane) funkcie. Neverim, ze
> som jediny koho to za tie roky napadlo, len pripustam, ze
> nikomu sa zatial nechcelo v tom gcc len kvoli tomu rypat...

No mas par moznosti:
- zmieris sa s tym, ze pointer v C je tak nedokonaly, ze vie ukazat len na cely byte
- prejdes k vyssiemu jazyku, ktory principy neporusuje
- upravis si GCC k obrazu svojmu
 
:-)
 
miro

> wek



      



Další informace o konferenci Hw-list