3 ms·

(a) has been copied in quite a few languages now. Here's my OCaml copy: https://bitstring.software/documentation/ https://bitstring.software/documentation/ (so

by rwmj 3y ago

(a) has been copied in quite a few languages now. Here's my OCaml copy: https://bitstring.software/documentation/ https://bitstring.software/documentation/ (sorry about the bad website cert, it's not under my control) https://github.com/xguerin/bitstring https://github.com/xguerin/bitstring We handle endianness very naturally. Performance of the OCaml version depends on whether everything is byte-aligned. It will compile-time optimize byte-aligned stuff to be fast, and do slow bit shifting for everything else. I believe this is an advantage over the Erlang original.

toast0 3y ago
This is pretty interesting. Thanks! I didn't have time to dig into it [1], but something that's a bit ugly is something like a PCI BAR, defined as Bits 31-4: 16-Byte Aligned Base Address Bit 3: Prefetchable (flag) Bits 2-1: Type Bit 0: Always zero In Erlang, this gets parsed with something like: <<BaseLS:4, Prefetch:1, Type:2, 0:1, BaseMS:24/little>> = BAR and then you have to put the Most Significant and Least Significant parts back together somehow, and there's the zero filling too, like maybe <<Base:32>> = <<BaseMS:24, BaseLS:4, 0:4>> If the structure were big endian, you'd probably have bits 0-28 be the address and bits 29-31 be the flags, and you could parse it as <<ShiftedBase:28, Prefetch:1, Type:2, 0:1>> = BAR, Base = ShiftedBase bsl 4 You could also just do <<BaseAndFlags:32/little>> = BAR and then mask out the flags and stuff, but then you lose the joy of pattern matching, or you defer the pattern matching which means you'd lose out on matching in function heads or have to have an intermediate parsing function that calls the real function with matching in its heads. [1] I looked a bit more and the example seems inline with Erlang syntax https://bitstring.software/documentation/#constructing-bitstrings https://bitstring.software/documentation/#constructing-bitst... shows something similar to what I would expect with Version = 1, Data = 10, <<Version:4, Data:12>>. You could say Data:12/little, and that does flip bits around, but a little endian C developer isn't going to be happy with what results. It's not natural for them to combine the lower bits of byte 0 with the bits of byte 1.

by rwmj 3y ago

toast0 3y ago

This is pretty interesting. Thanks! I didn't have time to dig into it [1], but something that's a bit ugly is something like a PCI BAR, defined as Bits 31-4: 16-Byte Aligned Base Address Bit 3: Prefetchable (flag) Bits 2-1: Type Bit 0: Always zero In Erlang, this gets parsed with something like: <<BaseLS:4, Prefetch:1, Type:2, 0:1, BaseMS:24/little>> = BAR and then you have to put the Most Significant and Least Significant parts back together somehow, and there's the zero filling too, like maybe <<Base:32>> = <<BaseMS:24, BaseLS:4, 0:4>> If the structure were big endian, you'd probably have bits 0-28 be the address and bits 29-31 be the flags, and you could parse it as <<ShiftedBase:28, Prefetch:1, Type:2, 0:1>> = BAR, Base = ShiftedBase bsl 4 You could also just do <<BaseAndFlags:32/little>> = BAR and then mask out the flags and stuff, but then you lose the joy of pattern matching, or you defer the pattern matching which means you'd lose out on matching in function heads or have to have an intermediate parsing function that calls the real function with matching in its heads. [1] I looked a bit more and the example seems inline with Erlang syntax https://bitstring.software/documentation/#constructing-bitstrings https://bitstring.software/documentation/#constructing-bitst... shows something similar to what I would expect with Version = 1, Data = 10, <<Version:4, Data:12>>. You could say Data:12/little, and that does flip bits around, but a little endian C developer isn't going to be happy with what results. It's not natural for them to combine the lower bits of byte 0 with the bits of byte 1.