On Wed, Aug 7, 2013 at 3:20 PM, Nilay Vaish <[email protected]> wrote:
> > I think the fold bit can moved beyond the most significant bit in the > register index (when all types of registers are taken together). But it > seems that this still would not solve the problem since we play with the > register indexing in arm and sparc architectures. Have you thought about > indexing in those two architectures? Can you elucidate why they will work > correctly? > The difference with SPARC and ARM is that although we do munge the register indices, we do this because there are a large number of actual registers (more than the ISA lets you access directly). So it still works to have NumIntRegs == FP_Base_DepTag, it's just that NumIntRegs is bigger than you would think because there are a lot of extra registers in there (to support register windows on SPARC, or the mode-specific registers in ARM). In contrast, the IntFoldBit increases the number of valid integer register index values without increasing the number of actual integer registers. Because FP_Base_DepTag needs to be larger than any valid integer register index, you end up with the unique situation where FP_Base_DepTag is necessarily larger than NumIntRegs. All this is confusing because there's no good documentation on when you want to use NumIntRegs as an offset for FP register indices, and when you want to use FP_Base_DepTag. In the end I figured it out: NumIntRegs gets used when accessing unified structures where you are actually allocating storage (like the physical register file and scoreboard), but FP_Base_DepTag is used most other places. Rather than continuing with this confusing distinction, though, I restructured a bunch of the internal classes (scoreboard, free list, reg file, etc.) so that in general you don't need to know or care what offset to use, and when you do need to know, you basically always use FP_Base_DepTag, because the few classes that use NumIntRegs instead have that fact securely hidden inside their implementation, invisible to anyone who uses them. Patches forthcoming after a round of internal review... Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
