I'm writing some simple bit-oriented blocks, the first is a block interleaver. It would be nice if I could write a fairly generic block interleaver, and the user would specify the number of rows and columns of bits when it is instantiated. But I'm having these issues:
1. For such a conceptually simple operation, the code is still messy due to all the masking and shifting required to unpack an individual bit from the input buffer and pack it back into the output buffer. 2. What if the interleaver's size is not a multiple of 8, or the block feeding into my interleaver outputs data in multiple chunks of bits whose size are not a multiple of 8? For the GSM block interleaver I'm interested in, this is not an issue. Should I just require everything to start and end on byte boundaries and move on? I'm wondering if instead of fully packed arrays, I should instead represent the bits as 1 bit in each byte in the input and output buffers. Then I would use array indexing to grab each bit, which would solve issue 1, and issue 2 would go away. The expense would be some buffer memory. I don't know which direction CPU usage would go. I can imagine that when using soft-decision decoding, someone may even want to deinterleave a soft-decision bit instead of a hard-decision bit, which may push toward a more templatized interleaver. Are there guidelines about this in the GNU radio codebase, such as "we prefer our bits fully packed" or "for these kinds of operations, we prefer 1 bit per byte" or even "we have a special abstract data type for dealing with this problem"? Thanks, Rob -- Robert W. Brewer _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
