Re: [boost] Request for interest in new library : Bit Logic

From: Art Stamness (artstamness_at_[hidden])
Date: 2007-02-01 11:27:12

On Feb 1, 2007, at 7:03 AM, François Duranleau wrote:

> On Wed, 31 Jan 2007, Art Stamness wrote:
>
>>> On Jan 31, 2007, at 4:21 PM, me22 wrote:
>>>
>>>> On 1/31/07, Art Stamness <artstamness_at_[hidden]> wrote:
>>>
>>>> However, what's the main advantage of your code over
>>>> Boost.Dynamic_Bitset and std::bitset?  It seems (from a quick look)
>>>> that your bit_array is close to std::bitset and your bit_vector is
>>>> close to at least one of dynamic_bitset and vector<bool> (the  
>>>> latter
>>>> being specialised for packing).
>>>
>>> True, these types are similar to the std::bitset /
>>> boost::dynamic_bitset / std::vector<bool> in that they are used to
>>> represent bit data. However they have a very different operational
>>> semantic. These types are intended to model bit containers for
>>> arbitrary logic functions. Things that are commonly found when
>>> modeling hardware systems ( you can find why i do this under the
>>> "Motivation" section ).
>>>
>>> For instance, taking 4 bits from one type and 4 bits from another,
>>> doing a logical exclusive-or on those bits, and placing it in 4
>>> bits of a third type is a 1 line operation.
>>>
>>> c.select(15,12) = a.select(7,4) ^ b.select(3,0) ; // a,b,c can all
>>> be bit_array / bit_vector / bit_container ( adapted type )
>>>
>>> This very closely mimics what is found in hardware description
>>> languages ( which is my background ) .
>>>
>>> c[15:12] = a[7:4] ^ b[3:0] ; //  Same operation in Verilog
>>>
>>> This library is intended to provide fixed , and resizable types,
>>> that can be used to model n-bit long logical operations in a clear
>>> semantic description, while also providing some STL container like
>>> interface for use with STL algorithm.
>>>
>>> The above listed operations would be very difficult to do with any
>>> of the 3 listed types.
>
> How about writing bit container algorithms instead of new bit  
> containers? Taking the 'select' example, we could write:
>
> select(c,15,12) = select(a,7,4) ^ select(b,3.0)
>
> The 'select' algorithm would return a view for a range of bits.  
> Thus we would only need to write those algorithms plus some view  
> classes, and it could work with any already existing bit  
> containers. It could be possible to specialize the views for  
> certain types of containers if it could optimize some operations (I  
> don't know).

This was a consideration. The problem is that I cannot create a "3- 
bit type", in any of the existing bit storage types ( uint8_t for  
example )  and still check for errors if the 4th bit is used. I  
wanted a strongly typed container system.

The bit_container_adaptor class ( not documented, err well ) allows  
for taking any existing bit storage type, and providing the bit  
container functions. This will automatically size to the actual bit  
count of the container. so every data type would be a 2^n sized.

That is not to say that adding select_bits as a free function isn't a  
good idea. Let me add that now ( the base functionality is there, it  
just does not exist as a function today ) .

Thanks for the feedback.

-Art

p.s. Cromwell and Chris, I am working on providing responses to your  
earlier questions / comments.