The explanation to the problem you encounter is described in previous
messages...
I have came up in the past with this issue and solved it for pic16 port
by using
the PIC16_PACKED_BITFIELDS enviroment variable which aggressively
packs bitfields (which is what one expects, before reading specs!!:
On Friday 20 July 2007 10:11, Philipp Klaus Krause wrote:
> Hynek Sladky schrieb:
> > I think it is a bug because:
> >
> > struct {
> >unsigned short CCC:12;
> >unsigned short READ_BL_LEN:4;
> > } CSD;
> > > works as expected (2 bytes long)
> >
> > struct {
> >unsigned short READ_BL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hynek Sladky schrieb:
> I think it is a bug because:
>
> struct {
>unsigned short CCC:12;
>unsigned short READ_BL_LEN:4;
> } CSD;
> > works as expected (2 bytes long)
>
> struct {
>unsigned short READ_BL_LEN:4;
>unsigned short CCC
>From "C++: The Complete Reference", by Herbert Schildt, page 176:
You cannot know, from machine to machine, whether the fields
will run from right to left or from left to right; this implies
that any code using bit-fields may have some machine
dependencies. Other restrictions may be impo
The last note:
if bitfield in SDCC for the first time crosses byte boundary, it always
starts at bit zero. The strange thing is that second example produces 3
byte long structure (no 4 bytes long) so second byte-boundary crossing
seems working correctly.
// correct
struct {
unsigned int bit1
I think it is a bug because:
struct {
unsigned short CCC:12;
unsigned short READ_BL_LEN:4;
} CSD;
> works as expected (2 bytes long)
struct {
unsigned short READ_BL_LEN:4;
unsigned short CCC:12;
} CSD;
> works wrong (3 bytes long)
I think that this should work the same way sh
But it is sometimes used for such purposes (defining e.g. HW register
content - and I adopted it as well) so I don't understand why it is used
such way if it is not guaranted... Is there correct way for it?
BTW - my structure works in all other compilers I have used.
Thanks,
Hynek Sladky
Phil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hynek Sladky schrieb:
> It seems that second part of bitfield starts at next byte location from
> bit 0 :-(
Why not? AFAIK the C standard doesn't guarantee alignment in bitfields,
it doesn't even guarantee alignment in structures.
Philipp
-BEG
I am new SDCC user and I have problem :-)
struct {
unsigned int READ_BL_LEN:4;
unsigned int CCC:12;
} CSD;
Accessing READ_BL_LEN is OK.
Accessing CCC is wrong. Is there any problem with bitfields or is my
code wrong?
printf ("RDlen=%d\n", CSD.READ_BL_LEN);
>> ld hl,#_CSD
>> ...
