Bit syntax frustrations, again (LONG)
Thu Oct 3 15:20:32 CEST 2002
mml> (* Bits-in-a-byte the wrong way around can happen, but
mml> surely not in a file format. When you transmit SS7 traffic
mml> over a E1/T1 PCM line, you send the LSB first. When you send
mml> voice over the same line, you send the MSB first. [...]
tony> This is a attempt to solve this question once and for all :-)
Except that your suggestion solves another problem, not the one I
The SS7 problem is this: if there's an octet 0x83 (1000 0011) on the
line, the receiving hardware will put it in RAM as 0xc1 (1100 0001).
This is a pain in the arse but, once you've figured out what's going
on and condemned the authors of Q.703 to hell yet again, it's dealt
with fairly easily by adding a bit-reflect mode in hardware.
The problem you're solving is one of dealing with file formats
designed for little endian machines:
tony> To solve this once and for all I wote for (re)introduction
tony> of bit groups!
tony> To given an example of how to specify the above bit pattern
tony> in a bit group:
tony> << <<A:3, B:2, C:1, D:4, E:6>>:2/little >>
tony> << <<A:3, B:2, C:1, D:4, E:6>>:2/big >> == <<A:3, B:2, C:1,
tony> D:4, E:6>>
Syntax-wise, this doesn't seem like such a huge win over
<< Temp:16/little >> = Bin,
<<<A:3, B:2, C:1, D:4, E:6>> == <<Temp:16>>.
though it may help the compiler generate good code.
In any case, I have a simpler solution: the authors of any little
endian protocols and file formats can go roast with the Shockwave and
More information about the erlang-questions