discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] guidance on datatypes, especially bit-oriented


From: Robert Brewer
Subject: [Discuss-gnuradio] guidance on datatypes, especially bit-oriented
Date: Thu, 19 May 2005 10:06:26 -0400

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]