Hi folks. This is mostly addressed to people up on fancy new language
features. Back when I implemented the BitUnion stuff, I discovered that
there was an annoying and serious bug which resulted from a limitation of
C++. At the time, I think I saw that the missing feature would become
available in the future.

The quick version of how BitUnions work is that they are a class holding an
anonymous union of bitfield classes. The only data inside the bitfield
class is an instance of the underlying type of the bitunion. When accessing
the bitfield, operator overloading makes it extract or set the particular
field in question. The way the underlying data is set or extracted is
arbitrary and, unlike C bitfields, can be independent of endianness.

So for instance, if you have a BitUnion64, it might expand to something
like this (pseudo-code-ey)

class BitUnion64
{
  union {
    uint64_t data;
    class Bitfield<3, 1> a
    {
      uint64_t data;
    }
    class Bitfield<5, 4> b
    {
      uint64_t data;
    }
};

That works just fine, even if it is a little bit dodgy in the way it
assumes the Bitfield classes are laid out. The problem is if you have two
bitfields of the same type (signed vs. unsigned, bit positions) and you
assign one to the other. What you expect to happen is that the value will
be extracted from one Bitfield, and then that value will be used to fill in
the other. If the types aren't perfect matches for each other, that's what
happens. If they *are* perfect matches for each other though, they'll be
assigned directly from one to the other. Since each actually contains a
complete copy of the underlying data (shared with the other bitfields and
the parent class) the entire value will be overwritten with the entire
other value, not just the bitfields.

The thing you might use to solve this problem is to define a copy
constructor/assignment operator for a Bitfield type that would force it to
extract the bitfield from one and then insert it in the other like you'd
expect. The problem here is that you're not allowed to have non-default
constructors or something like that on types that go into unions (maybe
just anonymous unions?). I forget exactly what you were going to be allowed
to do that would let you fix this (constructor on an anonymous union?), but
it sounded like it was coming down the pipe.

Any idea what that feature was and if it's available now? I'd really like
to get this fixed. It's bugged me for years that it's been broken like that.

Gabe
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to