Thanks Steve. As it turns out, I am working with the Link-16 data format. You are saying that the stream of received bits – 0 then 1 then 1 then 1 then 0 then 0 then 1 then 0 then … - are viewed in this fashion:
High memory address Low memory address 0010 0001 ................................................ 0100 1110 Hex: 21 ……………………………………. 4E That is consistent with the Link-16 specification. Here’s where I get confused. Suppose I store those bits into a file. Then I open the file in a hex editor. How will the hex editor display the data? Will the hex editor display the four bits at the lowest memory address (1110) in hex digit form (E), followed by the four bits at the next-to-lowest memory address (0100) in hex digit form (4): E4 ……………………………… 12 Or will the hex editor see the bits in reverse order: Low memory address High memory address 0111 0010 ………………………………………… 1000 0100 Hex: 72 ………………………………………………. 84 And display this: 72 ………………………………………….. 84 That is wildly different! Eek! I am so confused! Help! From: Steve Lawrence <slawre...@apache.org> Sent: Thursday, December 7, 2023 1:16 PM To: users@daffodil.apache.org Subject: [EXT] Re: Bits are streamed into an application ... the bits are put in memory ... is the first bit received at the lowest memory address? The most likely interpretation is that the 2-bit field will have a value of "01", with a decimal value of 1. This is what DFDL calls dfdl: bitOrder="mostSignificantBitFirst" and is what most data formats use. DFDL also has dfdl: bitOrder="leastSignificantBitFirst", The most likely interpretation is that the 2-bit field will have a value of "01", with a decimal value of 1. This is what DFDL calls dfdl:bitOrder="mostSignificantBitFirst" and is what most data formats use. DFDL also has dfdl:bitOrder="leastSignificantBitFirst", which is common in some old military formats like VMF and Link16. One way to imagine this is as if the memory addresses and bits were ordered and read right-to-left. So, your example would look like this: High memory address Low memory address 0 0 ................................................ 1 1 0 So we have the same data, and you still read the low memory address bits first, it's just all backwards. Because we read right-to-left, the first two bits are now "10". Note that interpreting the value of the bits is the same as normal, so "10" evaluates to 2--all that changes is the order in which we read bits. I haven't seen any formats where the high memory address bits would be read first and would lead to the 2-bit field being "00". DFDL doesn't have a way to model this. On 2023-12-07 12:28 PM, Roger L Costello wrote: > Hi Folks, > > A basic question about bits. > > Scenario: an application is receiving a message. The message arrives as a > stream of bits. The first bit received is 0. The second bit received is 1. > The third bit received is another 1. ... The second-to-last bit received is > 0. The last bit received is 0. > > The application stores the message in memory. > > Will the first bit received be in the lowest memory address and the last bit > received in the highest memory address? I.e., > > Low memory address High memory address > 0 1 1 ............................................................. 0 0 > > The message contains a series of bit fields. The specification for the > message says the first field is two bits. > > Is the first field the bits 0 1 or the bits 00? > > /Roger
