428,838 Members | 2,222 Online
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,838 IT Pros & Developers. It's quick & easy.

# question about .. my 'unpacker'.

 P: n/a I'm trying to unpack a 32 bit word into 3-10 bits samples. So now: Sample0 corresponds to bits 0-9 Sample1 corresponds to bits 10-19 Sample2 corresponds to bits 20-29 Bits 30 and 31 are don't cares So my unpacker looks like: void unpack( unsigned int *beg, unsigned int *end, float* dest) { const unsigned int mask=(1<<20)-1; while (beg!=end) { *dest++ = *beg & mask; *dest++ = *beg >> 20 & ((1<<10)-1); ++beg; } } Usage: unsigned int val(0xA5A5A5); float dest[3]; unpack (&val, &val+1, dest); I'd like a - sort of - generic approach that'll acount for floats and doubles. I suspect I should also use a vector, nonetheless critiques and/or a more refined implementation welcome. Sep 11 '05 #1
10 Replies

 P: n/a ma******@pegasus.cc.ucf.edu wrote: .... I'd like a - sort of - generic approach that'll acount for floats and doubles. Somthing like this ? template < typename InT, typename OutT, unsigned N > void unpack( InT beg, InT end, OutT ( & dest )[ N ] ) { const unsigned int mask=(1<<20)-1; unsigned i = 0; while (beg!=end) { dest[ i++ ] = *beg & mask; if ( i >= N ) throw Overflow; dest[ i++ ] = *beg >> 20 & ~mask; if ( i >= N ) throw Overflow; ++beg; } } I suspect I should also use a vector, nonetheless critiques and/or a more refined implementation welcome. Sep 12 '05 #2

 P: n/a * ma******@pegasus.cc.ucf.edu: I'm trying to unpack a 32 bit word into 3-10 bits samples. So now: Sample0 corresponds to bits 0-9 Sample1 corresponds to bits 10-19 Sample2 corresponds to bits 20-29 Bits 30 and 31 are don't cares So my unpacker looks like: void unpack( unsigned int *beg, unsigned int *end, 'const' for both those arguments. float* dest) mysterious choice of result type. { const unsigned int mask=(1<<20)-1; while (beg!=end) { *dest++ = *beg & mask; Here you're copying the lower 20 bits. *dest++ = *beg >> 20 & ((1<<10)-1); ++beg; } } -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? Sep 12 '05 #3

 P: n/a ma******@pegasus.cc.ucf.edu wrote: I'm trying to unpack a 32 bit word into 3-10 bits samples. So now: Sample0 corresponds to bits 0-9 Sample1 corresponds to bits 10-19 Sample2 corresponds to bits 20-29 Bits 30 and 31 are don't cares So my unpacker looks like: void unpack( unsigned int *beg, unsigned int *end, float* dest) { const unsigned int mask=(1<<20)-1; while (beg!=end) { *dest++ = *beg & mask; *dest++ = *beg >> 20 & ((1<<10)-1); ++beg; This certainly won't work. For one, it only gives you two values, not three. } } Usage: unsigned int val(0xA5A5A5); float dest[3]; unpack (&val, &val+1, dest); I'd like a - sort of - generic approach that'll acount for floats and doubles. I suspect I should also use a vector, nonetheless critiques and/or a more refined implementation welcome. #include using namespace std; typedef unsigned int uint; template void unpack( vector::const_iterator srcBegin, vector::const_iterator const srcEnd, vector::iterator dest ) { static const uint mask = (1<<10)-1; while( srcBegin++ != srcEnd ) { *dest++ = DestType( (*srcBegin ) & mask ); *dest++ = DestType( (*srcBegin >> 10) & mask ); *dest++ = DestType( (*srcBegin >> 20) & mask ); } } Cheers! --M Sep 12 '05 #4

 P: n/a mlimber wrote: ....I'd like a - sort of - generic approach that'll acount for floats anddoubles. I suspect I should also use a vector, nonetheless critiquesand/or a more refined implementation welcome. #include using namespace std; typedef unsigned int uint; template void unpack( vector::const_iterator srcBegin, vector::const_iterator const srcEnd, vector::iterator dest ) { static const uint mask = (1<<10)-1; while( srcBegin++ != srcEnd ) { *dest++ = DestType( (*srcBegin ) & mask ); *dest++ = DestType( (*srcBegin >> 10) & mask ); *dest++ = DestType( (*srcBegin >> 20) & mask ); } } Good catch on the algorithm issues. On the templateization however, unless you really want to hold down the parameters to be vector iterators, you can simply let the compiler figure out the template argument. If you do this carefully enough, your template code will be more generic, for example, the code below works for both vectors or plain arrays (or any combination of them). Hence, the same unpack() code can be used generically in legacy code as well as new code that uses vector. template void unpack_helper( SrcType srcBegin, SrcType srcEnd, DestType dest, const DestValueType & /*dest_value unused*/ ) { static const unsigned mask = (1<<10)-1; unsigned int i = 0; while( srcBegin++ != srcEnd ) { dest[ i ++ ] = DestValueType( (*srcBegin ) & mask ); dest[ i ++ ] = DestValueType( (*srcBegin >> 10) & mask ); dest[ i ++ ] = DestValueType( (*srcBegin >> 20) & mask ); } } template void unpack( SrcType1 srcBegin, SrcType2 srcEnd, DestType dest ) { unpack_helper< SrcType2, DestType >( srcBegin, srcEnd, dest, dest[ 0 ] ); } void fp() { int x[1] = {0xaaaaaa}; float v[3]; unpack( x, x+1, v ); } #include void fv() { std::vector x(1); x[1] = 0xaaaaaa; std::vector v(3); unpack( x.begin(), x.end(), v ); } int main() { fp(); fv(); } Cheers! --M Sep 12 '05 #5

 P: n/a Gotta love comp.lang.c++. You guys are good. Thanks all. Nothing like seeing the implementations, more specifically the different implementation approaches. A humbling experience since it highlights how far I have to go. Makes me think I should have been a comp sci major as opposed to EE-DSP. :) Sep 12 '05 #6

 P: n/a Gianni Mariani wrote: Good catch on the algorithm issues. On the templateization however, unless you really want to hold down the parameters to be vector iterators, you can simply let the compiler figure out the template argument. If you do this carefully enough, your template code will be more generic, for example, the code below works for both vectors or plain arrays (or any combination of them). Hence, the same unpack() code can be used generically in legacy code as well as new code that uses vector. [snip] Good points. I was assuming that the OP wants to restrict the incoming data to unsigned int because of the specified hardware packing scheme. Your scheme does make it more general but also allows the user to introduce potentially dangerous code. Perhaps a via media can be found with dumb pointers (allowing more abuse but also providing greater flexibility than my previous post and allowing less abuse but also providing less flexibility than your post): template void Unpack( uint const* const begin, uint const* const end, DestType * const dest ) { // Same as above } void Foo() { const uint n = 0xC0FFEE; vector dest( 3 ); Unpack( &n, &n+1, &dest[0] ); // ... } void Bar() { const vector n; n.push_back( 0xC0FFEE ); float dest[ 3 ]; Unpack( &n[ 0 ], &n[ n.size() ], dest ); // ... } Presumably the OP's actual circumstances will determine what approach is best. Cheers! --M Sep 12 '05 #7

 P: n/a ma******@pegasus.cc.ucf.edu wrote: Gotta love comp.lang.c++. You guys are good. Thanks all. Nothing like seeing the implementations, more specifically the different implementation approaches. A humbling experience since it highlights how far I have to go. Makes me think I should have been a comp sci major as opposed to EE-DSP. :) I'm an EE. Sep 12 '05 #8

 P: n/a Gianni Mariani wrote: .... #include void fv() { std::vector x(1); x[1] = 0xaaaaaa; should be : x[0] = 0xaaaaaa; std::vector v(3); unpack( x.begin(), x.end(), v ); } :-( Sep 12 '05 #9

 P: n/a mlimber wrote: .... Good points. I was assuming that the OP wants to restrict the incoming data to unsigned int because of the specified hardware packing scheme. Your scheme does make it more general but also allows the user to introduce potentially dangerous code. Perhaps a via media can be found with dumb pointers (allowing more abuse but also providing greater flexibility than my previous post and allowing less abuse but also providing less flexibility than your post): Yep, good points also. Presumably the OP's actual circumstances will determine what approach is best. As always. G Sep 12 '05 #10

 P: n/a Gianni Mariani wrote: ma******@pegasus.cc.ucf.edu wrote: Makes me think I should have been a comp sci major as opposed to EE-DSP. :) I'm an EE. Me too, also with a specialization in DSP. I'm currently writing code for dual TI DSPs in an embedded system (TI has a very conformant compiler, possibly the EDG front end, but no STL; I have my required parts of STLport working, though). Reading some good books on C++ and practice can really bridge the gap, ma740988. Don't give up, and don't change majors! Cheers! --M Sep 12 '05 #11

### This discussion thread is closed

Replies have been disabled for this discussion.