bitfield v avr-gcc

[Jan Waclawek]

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


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

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

wek