Proposal: leverage BitVector in `Clash.Annotations.BitRepresentation`

[martijnbastiaan]

A ConstrRepr uses two fields to encode a mask and a value to encode constructor bits. For example:

ConstrRepr 'A 0b110011 0b1010 []

which would mean: take the four bits indicated by the first binary value. If the value corresponds to 1010 it's constructor A. This is confusing in multiple ways:

• It's possible to mix up the positions of the fields, as there's no real indication of which is which without looking at ConstrRepr's documentation. (This could be fixed by making ConstRepr a record, though.)
• It's not clear whether the value is compared against the four bits extracted by the mask field (this is what Clash is doing), or whether you're supposed to give an equally sized field in the second field
• It's not easy to see which bits in the value field correspond to what bits in the overall data type.

Perhaps we could fix this by leveraging the ability to set undefined bits on BitVector. For example:

ConstrRepr 'A (bLit "10..10") []

The Python programmer in me says we could even use OverloadedStrings and do:

ConstrRepr 'A "0b10..10" []

but that's a topic for another day..

---

Relevant documentation: http://hackage.haskell.org/package/clash-prelude-1.4.0/docs/Clash-Annotations-BitRepresentation.html#g:1

[JvWesterveld]

+1! Perhaps to serve your point: I believe your description of how this currently works is wrong. Bitpacking A would rather result in 0b00..10. The mask and value are matched bit by bit, and the bits of the value for which the corresponding mask bits are zero are ignored.

[martijnbastiaan]

Thanks @JvWesterveld. And yeah, I think that definitely proves my point then :-)