Re: [Discuss-gnuradio] 4-to-32 bit symbol mapper block

[Marcus Müller]

Hi Christopher,

On 01/03/2015 09:56 PM, Christopher Friedt wrote:
> On Sat, Jan 3, 2015 at 1:38 PM, Marcus Müller <address@hidden> wrote:
>> Then: If I understand you correctly, what you have is an input stream of
>> unsigned (32 bit)ints, each int containing exactly one bit of information:
>> 0x00000000, 0x00000001, 0x00000001, 0x00000000, and so forth.
>> This format is especially wasteful on memory, and wherever GNU Radio
>> uses unpacked bits, they are usually transported as unsigned char items
>> (giving you a memory overhead of only 8x instead of 32x), so there's
>> blocks for that particular job (packed_to_unpacked and the reverse).
> For sure it's wasteful on memory. I usually just try getting something
> working before optimizing it. Unit tests pass now, thankfully :-)
Good approach; I often do premature optimization and end up with nothing...
> So, assuming that I may do this basing my class on the
> sync_interpolator class, I'd like to pack my input and output -
> ideally as 32 or 64-bit ints (whatever the wordsize is - 64 bits in my
> case). 
As you mentioned in IRC, your symbols/chips might contain a maximum of
32 bit, which would make uint32_t sufficient. x86_64 CPUs still deal
with 32 bit ints as efficiently as it does in 32 bit mode, so use
whatever makes sense for your application (or use 64 bit if you might
want to expand).
> From what I've read, I can only expect to pack up to 32-bits
> into each integer-type output item [1], and therefore will
> unfortunately only be able to pack up to 4-bits into each integer-type
> input. Is that correct, or is there also a 64-bit output type?
Well, the FAQ entry is half-true, only. Basically, GNU Radio knows
nothing of types. We don't have a convention on how to suffix blocks
that take 64 bit integers, and I guess GRC doesn't have a color for
them, but other than that, there's nothing stopping you from using items
of an arbitrary length of bytes (there's memory reservation issues if
you use things that are hard to page-align, but unless you use items of
say 1023 byte length, this shouldn't be a problem). This has some
dangerous effects: for example, you can connect a block that produces
float items to a block that consumes 32 bit integers -- because these
items have the same size, GNU Radio won't notice the mixup. Therefore,
the suffix convention explained in that FAQ entry was born.

There's a lot of blocks that really don't care about what's inside an
item -- file_sink for example just takes the items as memory, and puts
them into a file. You just have to tell it "hey, expect items of length
N bytes"; the same goes for many network sinks etc.

On the other hand, you might want to use existing arithmetic blocks on
these items -- in that case, you might be better off using a type that
they actually know.

>
> I guess if I'm packing 4 bits into one byte on the output and 32-bits
> into an int on the output, I would probably just use a sync block with
> a ratio of 1-1, and e.g. add an example to remind the user to use the
> Pack 4 Bits block on the input.
Well, I agree that memory is most probably not the problem  -- so it
might be easiest to modify your block to take completely unpacked bits
in bytes, and using
a) a matching output multiple or
b) vectors of 4.
By the way, b) would be a 4 byte input signature, exactly like you have
with your int block, but with different packing scheme (eg. 0x01010101
instead of 0x0000000F for the 1111-symbol)
>
> It was an interesting exercise to learn a bit about some of gr's
> various blocks :-)
:-) !
>
>> Since I really *want* to understand what is happening here, I'll go
> I wrote most of my code snippet when I was 1/2 asleep at 2 am last
> night! Sorry for subjecting you to it!
Oh no problem at all, keep it coming! So nice to read something like
that; I've written code that used a bit more variables than it needed to
a hundred times, and the fact that I put my own rewrite in the mail was
that I had it at hand, anyway (it's how I often try to understand
someone else's code, by slightly rewriting it), it just had to be
formatted a bit nicer. In fact, I think it's commonly agreed that
although GR has gotten some nice features for digital data (as in hard
symbols) processing over the last two years (PDUs, tagged stream blocks,
the whole messaging/PMT thing), there's still a lot of room and need for
best practices when it comes to processing bitstreams -- so your program
excerpt is, as I assume, useful for the community and development process.

Greetings,
Marcus
>
> [1] 
> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-are-items-in-a-flowgraph