This is more along the lines of where I want to go with this. The hard part is going to be doing this cleanly so that we don't have a special case hack in the parser for x86 and we don't make a big mess out of the x86 ISA description (it's already very, uncomfortably, complicated). This gets into what I was talking about before where the parser is smart enough (probably with guidance and bits of code from the ISA description) to deconstruct the way the flags are being used, to make the right flag fragments sources and destinations, to read/write the right pieces at the start and end of the instruction, and to assemble and disassemble a single value to play with while in the microop's code, all based off of construction time information, specifically which flags are requested to be set. All of this would be quite possible or even straightforward if doing this by hand, but then it would also be very tedious and repetitive. So we need to figure out a way to cleanly fit it into our code writing automation framework, aka the ISA parser, so it can do the grubby work for us, all without making a great big mess in the process. That's going to be a tricky bit of work, and it will have to be done well.
Gabe On 04/14/12 16:16, Nilay Vaish wrote: > The patch that was posted on the review board was along the lines of > the solution suggested in my previous mail. Note that only splitting > the ccFlags register is not the complete solution. We would still need > to check that whether or not all the flags in a particular register > are being completely written or not. Otherwise two 'add' instructions > would still not get done in parallel. > > But Gabe is not happy with the current state of the patch, so I dug in > to the isa_parser and here is another proposal. In operands.isa, let's > mark the ccFlagBits so that we can identify it in isa_parser. When > build the operand map, we can now figure out that we have an operand > that may be read conditionally (similar to how the PC is read and > updated). In functions makeRead(), makeConstructor functions, if we > encounter such an operand, we include a call to a check function which > decides whether or not this operand will be read. The check function > will need the ext (or the flag bits) to figure out if the operand > needs to be read. > > How does this sound? > > -- > Nilay > > > On Tue, 10 Apr 2012, Nilay Vaish wrote: > >> Gabe, Thanks for the explanation. >> >> I think I have a solution for the problem that will work when all the >> flag bits will be written. I am assumping that the condition code >> register is identified as a source because it appears on the right >> hand side of the following code in src/arch/x86/isa/microops/regop.isa >> >> class FlagRegOp(RegOp): >> abstract = True >> flag_code = \ >> "ccFlagBits = genFlags(ccFlagBits, ext, result, psrc1, op2);" >> >> Suppose we want to remove the RAW dependence in case of 'add' >> microop. We can create a new microop with a different mnemonic. This >> new microop will be used in places where currently 'add' is in use >> with all the flags. This microop will not inherit from FlagRegOp >> class as 'add' does. It will inherit from a class that assumes a >> default value for ccFlagBits. We will also need to add a default >> value of 0 for ccFlagBits in the prototype of function genFlags(). >> >> But this will only help in case of addition and subtraction, as those >> are the only ones that write all the six flag bits. As Gabe pointed >> out, for any good solution to work, we would need to break up the >> flag bits. >> >> -- >> Nilay >> > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
