Bit Order in `<bitfield>` and `<set>` about commsdsl HOT 4 CLOSED

Hi @bearbattle,
I think your mental model of the bitfields as well as endian setting is incorrect.

When you specify members of the <bitfield> the order of the members is starting with the LSB first, so when you think of your AnnFlags as a 16 bit number representation it is encoded as:

MSB -> [PXNum (4 bits) | UnitNum (4 bits) | Flags (8 bits)] <- LSB

The bit ordering of the <set> is also always starting from LSB, i.e bit 0 has mask 0x1 (1 << 0), bit 1 has mask 0x2 (1 << 1), bit 2 has mask 0x4 (1 << 2), etc...

In other words, if your Flags.F is set to 1, UnitNum is set to 2, and PXNum is set to 3, then the 16 bit of the AnnField is going to be 0x3201.

The endian specifies the order of written bytes, not bits, i.e the two bytes above can be written in only 2 ways:

• 0x32 0x01 - for big endian
• 0x01 0x32 - for little endian

That's all. If you need to serialize it in different way, then you need to re-order your <bitfield> and/or use different idx property value for your bits. For example if you need your bit F to come first (be MSB), then it needs to have idx="7".

Hope it helps.
Regards,
Alex

from commsdsl.

Thank you. Will the library provide any methods to alter the bit order (i.e. from MSB to LSB)?

from commsdsl.

Hi @bearbattle,
Counting (indexing) bits from MSB is NOT a common practice in software engineering. I do not intend to do it. It will introduce too much complexity with too little benefit. Re-ordering of the bits is completely within your control when defining the protocol schema, just assign appropriate idx value, such as

<set name="Flags" ...>
    <bit name="F" idx="7" />
    <bit name="K" idx="6" />
    <bit name="P" idx="5" />
    <bit name="C" idx="4" />
</set>

Note that the order of the <bit>-s definition doesn't have to be from lowest idx to the highest. It can be arbitrary, what important is setting the right idx value.

from commsdsl.

Thanks for your reply! I'm closing the issue.

from commsdsl.