On Sat, 3 Aug 2013, Steve Reinhardt wrote:
I don't think your explanation is correct. To me it seems, it is only used when one wants to write bits <8,15> of a register. I think the only place where it is used is in microasm.isa. Here is the code:for reg in ('ah', 'bh', 'ch', 'dh'): assembler.symbols[reg] = \ regIdx("INTREG_FOLDED(INTREG_%**s, IntFoldBit)" % reg.upper()) Of the four registers specified, I think only 'ah' is in use ('ch' might also be in use, it is hard to read grep's output for ch). And the only places where 'ah' is used is in multiply and divide instructions and SAHF, LAHF instructions where we need to perform a merge, since we want to work with the AH register.I'm not sure how my explanation could be incorrect, when it was really a question and not an explanation ;-). You are right about the 'fold bit' being used to mark accesses to the upper byte of the 16-byte regs (AH, BH, CH, DH). However. although there are only a few instructions that use those registers implicitly, I believe they can be specified as explicit operands anywhere where an 8-bit register is needed (i.e., they can be used anywhere you can use AL, BL, CL, or DL). Anyway, I think I've figured it out. Basically we use FP_Base_DepTag and Ctrl_Base_DepTag as the offsets for unflattened registers, and NumIntRegs and NumIntRegs+NumFPRegs as the offsets for flattened registers. I don't think there's a good reason for this; my guess is that originally (pre-x86) we used them interchangeably and it didn't matter because they were the same. Then when x86 started using the IntFoldBit, which requires setting FP_Base_DepTag > NumIntRegs, things got inconsistent, and instead of consistently switching to FP_Base_DepTag everywhere, we ended up converging on two different schemes in two different places. It turns out that the flattened unified indices are really not used much anyway (only in a few places in inorder and o3), so we can probably get rid of the inconsistency just by changing how we handle architectural registers inside those two models.
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?
-- Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
