This would be an overlay instead of indirection. I'd have a uint64_t that overlapped with several smaller fields. Fewer comparison/xors would need to be done if you used the uint64_t, and you'd get roughly equivalent results.
The way bitunions work is that they're a union of classes which all contain a single data element of whatever the underlying type is supposed to be. Because they're all unioned on top of each other, they all effectively share and have access to the same underlying variable. Then there are a bunch of operator overloads and whatnot that let each of those classes munge the underlying variable appropriately to get out or in whatever data you wanted. Nate may correct me here, but since all classes share the same storage, a single variable, they shouldn't need any more memory than their underlying type, a uint64_t for instance. This was a major motiviation of the design. I'm going to reference my ExtMachInst structure from arch/x86/types.hh. I'd copy it here, but I'd need to copy basically the whole file which is too much for email. The first two fields are 8 bit vectors of various prefixes, one for legacy prefixes and one for the 64 bit REX prefixes. Next is a structure that holds the opcode information, a count, a "prefix" byte (aka a byte that says there are more bytes and how to interpret them), a second "prefix" byte, and the opcode itself. Then there are two more bytes from the instruction that describe memory addressing. The operand size, address size, stack size, and displacement size are next in 8 bit variables. These could be combined into bit fields of fewer variables because they're practically bounded to, say, a max of 8 currently. Finally there's a mode bit field which is 8 bits long but which uses 3 bits. All together, that's 2 + 4 + 2 + 8 + 8 + 4 + 1 = 29 bytes. The sizes and the mode could be combined into one 16 bit field, so it could be 26 bytes. In either cases, assuming the alignment works out, that could be overlayed with uint64_t[4]. The comparision operator in that same file could be redone to compare those 4 variables directly. The hashing function in utility.hh would also be considerably simpler. Gabe Quoting Ali Saidi <[email protected]>: > We don't keep around the instruction cache in a checkpoint. However, > the more indirection and larger the machine instructions are the less > effecient the caching will be. Does your bitunion use any space? > > Ali > > On Aug 3, 2009, at 2:04 AM, Gabe Black wrote: > >> I'm thinking about overlaying my ExtMachInst type in a union with >> an >> array of (or just a few scalar) large ints that would make comparing >> and >> hashing them a little more efficient. One potential problem that would >> create is that the bit position of the elements relative to the >> integers >> would change depending on the endianess of the system. If an >> instruction >> was hashed, the simulation checkpointed, and then restarted on a >> different machine with different endianess, would it be a problem that >> the hashes may no longer or may incorrectly match? Do we keep things >> around at that level of detail when we checkpoint? >> >> Gabe >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
