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!!:-) )
This workaround currently only works for pic16 port and after having set the
enviroment variable PIC16_PACKED_BITFIELDS, like this (on linux):
PIC16_PACKED_BITFIELDS=1 sdcc -mpic16 .....
one could easily adopt this behavior to other ports. What remains to be
tested
is the behavior of the bit reading/writing functions in the code
generator (gen.c)
of the respective port, so that it reads/writes bitfields in the correct
offset of the
array bytes' .
regards,
Vangelis Rokas
[EMAIL PROTECTED] wrote:
> 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 shouldn't it?
> Unfortunately I need the second version... :-(
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
