Re: [boost] [bitfield] Draft 3 available

From: Emile Cormier (emilecormier_at_[hidden])
Date: 2006-03-15 23:44:36

On Thu, 16 Mar 2006 02:05:22 -0000, "Andy Little"
<andy_at_[hidden]> said:
> "Emile Cormier" wrote:
> 
> [...]
> 
> > - Turned my previous "Port" example into an actual working mechanism to
> > access memory-mapped I/O ports. I don't intend to include Port in any
> > formal Boost proposals. I just want a concrete working example that
> > demonstates how Bitfield could make use of the proposed <iohw.h> port
> > types in the "Technical Report on C++ Performance".
> 
> I havent heard much more about <iohw.h> for a while. It might be worth
> trying to
> find out what happened about it. It seems to have died

They have released the final draft of TR 18015 on Feb 14, 2006.
Downloadable here:

http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf

> > I haven't yet had the chance to analyze the performance of my code
> > compared to hand-written bit manipulations. That will be my next focus.
> >
> > So far, I haven't received any feedback on my bitfield proposal.
> 
> Not quite true as there has been some feedback in the form of downloads
> from the
> vault, which can help to guage interest in the field.
> (Note I havent looked at latest version.)

The number of downloads does seem encouraging. I myself am guilty of not
providing feedback on the open-source software I use/peruse, so I guess
I shouldn't complain. :-)

> My response after downloading Bitfield2.zip was to be disappointed that
> there
> was no documentation provided. A html page of rationale for what you are
> trying
> to achieve would give those wanting to provide feedback somewhere to
> start.

Good point about the lack of a rationale document. I'll get started on
that soon.

> My own view on Bitfield2 version is that the following syntax is not very
> appealing (from Test.cpp)
> 
>  (high(r)) = 0x12;
> 
> I had a quick look and came up with a couple of alternatives.
> 
> 1)    set_field<high>()(r,0x12);
> 2)    set_field<high>(r,0x12);
>  3)    *high(r) =12;
> 
> (I think personally 2 is best as its just a function and does the job
> without
> trying to be too clever).

If you check out draft version 3, you'll see that I've added static
get/write methods that look similar to your #2 alternative. Here is how
some alternatives stack up:

r = (r & 0x00ff) | ((val & 0xff) << 8); // By hand, where r is just an
integer type.
r.high = val; // Draft #1, using non-portable packed unions
(high(r)) = val; // Draft #2
high::set(r, val); // Draft #3
set_field<high>(r, val); // Andy #2

The way you propose definately has advantages in terms of readability.
Just think of the cryptic names hardware vendors give to their registers
and bitfields:

// Hardware register and bitfield definitions
typedef Port<uint32_t, 0x12345678> LCDCR;
typedef Bitfield<6, 14, uint32_t, LCDCR> LCDXMAX;

// Bitfield usage in some driver code
set_field<LCDXMAX>(0x12); // Ok, LCDXMAX is a bitfield.
LCDXMAX::set(0x12); // Very compact. But what the hack is an LCDXMAX?

I might not get rid of value semantics for a Bitfield. Here's an ugly
contrived example of how value semantics can be convenient:

// BitBangOut and BitBangIn are Bitfields tied to some I/O port.
BitBangOut o;
BitBangIn i;
o = 1;
o = 1;
o = 0;
o = 1;
uint8_t response = i << 3;
response |= i << 2;
response |= i << 1;
response |= i;

I'll try to think of more elegant, yet realistic examples in the
rationale document.

> 
> Please
> > let me know if I'm on the right path, if there's a better way of doing
> > this, or if this is a hopeless cause. :) If it's the latter, I can
> > always post this stuff on The Code Project for those who may want to use
> > it or come up with a better solution. In the end, what I want is a
> > standard(-ish) way of implementing portable bitfields in C++.
> >
> > The lack of interest may be due to what I think is a relatively low
> > number of programmers who deal in "bit twiddling" and, at the same time,
> > make use of Boost. I assume that most bit twiddling for hardware I/O is
> > still done in C.
> 
> I would guess from the number of downloads and the lack of further
> feedback that
> there is interest in the idea, but that your implementation has failed to
> spark
> interest (That is of course just 1 persons unscientific opinion) I would
> guess
> that documentation would help, but also finding the right interface which
> (witthout looking at the latest version) I dont think you have found yet.
> 
> As with all these things its partly about whether you are prepared to
> push it 
> too ;-)
> 
> 
> regards
> Andy Little
> 
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost

Thanks for the feedback. :-)
-- 
  Emile Cormier
  emilecormier_at_[hidden]