On Thu, 16 Mar 2006 02:05:22 -0000, "Andy Little" <andy@servocomm.freeserve.co.uk> 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@mailcan.com