Hi Christopher, On 01/03/2015 09:56 PM, Christopher Friedt wrote: > On Sat, Jan 3, 2015 at 1:38 PM, Marcus Müller <[email protected]> > 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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
