bitfield v avr-gcc

[Jan Waclawek]

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

Nerozumiem: ved pointer/offset/nazvimetoakochceme mi predsa vypocita sam prekladac, nemusim sa o to starat. 

Predstav si funkciu T_bitfieldAddress GetBitfieldAddress(T_bitfield), potom funkciu T_bitfield GetBitfieldValue(T_bitfieldAddress) a k nej "inverznu" funkciu void SetBitfieldValue(T_bitfieldAddress, T_bitfield). To prve je ekvivalent operatora &, to druhe je x=*p, a to tretie je *p=x. Teraz mozem zapisat prenasanu polozku bitfieldu ako struct{T_bitfieldAddress a; T_bitfield b}; mozem si z takychto poloziek spravit pokojne pole, naplnit ho runtime pomocou tych prvych dvoch funkcii, preniest ho, a pomocou tej tretej ulozit; to vsetko bez toho, aby som sa ja ako programator zapodieval tym, kde v certoch je vobec ten bitfield alokovany.


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

Mozne to je ale nie je to tak univerzalne riesenie ake by poskytli pointre.
Ako som uz napisal, viem to obist a nerobi mi zasadnejsi problem pouzivat konstanty a makra a masky apod. Islo mi o princip.


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

No a?
V skutocnosti aj existujuce pointre na rozne typy su rozdielne a nemali by ist priradit jeden do druheho bez nasledkov (u C je to vdaka makroasemblerovosti obvykle len warning, ak si ho nepotlacis). Vzajomna kompatibilita pointrov nie je nevyhnutna.


>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

Ja viem....

wek


PS. Este by bola moznost presvedcit sucasnych chlebodarcov aby presli na jediny spravny jednocip, t.j. '51; a do SDCC by som si to trufal dopisat... ;-)