Additionally, regarding Statement 1, bitOrder does have an affect on *individual* elements that have with number of bits a multiple of 8 if the parse starts on a non-byte boundary. Note that this requires a previous element to have a non-byte length. Just want to make it clear that you can't just look at the length of an element to know if bitOrder applies. You also need to look at previous elements as well.
A more accurate statement 1 might be: dfdl:bitOrder only affects parsing data when the data element does not start or end on a byte boundary. On 2/18/19 5:59 PM, Beckerle, Mike wrote: > Statement 2 is not correct. > > > byte order matters if the number of bits is greater than 8. > > > To push the point, imagine a 9-bit wide field. > > > If byteOrder is bigEndian and bitOrder is mostSignificantBitFirst, then > imagine > these two bytes: > > > hex 00 80 > > > So the value of the first 9 bits here, is 1, because the most significant bit > of > the 2nd byte will be the least significant bit of the 9 bit-wide element. > > > Here's where it gets tricky: if byteOrder is littleEndian, and bitOrder is > still > mostSignificantBitFirst then the two bytes mean something different. > > > The first byte of data is the least-significant byte. The second "byte" of > data, > which contains only a single bit, becomes the most significant byte, but > that > 1-bit that was 80, becomes 01 because that byte has only 1 bit contributing > to > it. We shift it over as it is the only bit in the 2nd byte of the number. The > value is hex 0100 which is 256 decimal as an unsignedInt. Strange but true. > > > A good way to understand this is to consider two *whole* bytes being used to > represent the value 256. In little endian, this would be bytes 00 01. Now, > suppose I say, I only need 15 bits. Well in bitOrder mostSignificantBitFirst, > which bit is the "last" bit? It's the least significant bit of the 2nd byte. > So > we have to shift the 2nd byte 1 bit to the left, resulting in 00 02. The > value > of that 15 bit field is also 256. If we narrow it to 14 bits then the least > significant 2 bits of the 2nd byte are unused. So the bytes are then 00 40 to > represent 256. And so on until we've left 7 bits off, the bytes are 00 80 > using > 9 bits to represent the value 256. > > > If byteOrder is littleEndian and bitOrder is leastSignificantBitFirst, then > the > value is 0, because the single bit that is a 1 in the 2nd byte, won't be part > of > the 9-bits of our data. All the other bits are zero, so the value is zero. > > > I find byteOrder bigEndian and bitOrder mostSignificantBitFirst fairly > intuitive, and byteOrder littleEndian with bitOrder leastSignificantBitFirst > similarly pretty easy to understand. > > > It's the funny mixed mode: byteOrder littleEndian with bitOrder > mostSignificantBitFirst.... this one is super confusing to me. It is; > however, > probably the most common due to the ubiquitous PC and Intel CPUs. > > -------------------------------------------------------------------------------- > *From:* Costello, Roger L. <[email protected]> > *Sent:* Monday, February 18, 2019 4:59:32 PM > *To:* [email protected] > *Subject:* bitOrder versus byteOrder > > Hello DFDL community, > > Are these two statements true: > > 1. *dfdl:bitOrder only affects parsing data with number of bits not a > multiple > of 8.* > > 2. *dfdl:byteOrder only affects parsing data with number of bits i * 8, where > i > >= 2 and i is an integer.* > > /Roger >
