That's what we already have and isn't sufficient. Having every bit broken out isn't what processors do, but they do break it down into a group of condition cdes and then a few individuals.
Gabe On 04/05/12 21:48, Nilay Vaish wrote: > I would be surprised if a processor actually carries out bit-level > dependency checks, it seems expensive to me. I would rather have two > separate registers, > > * one that contains the status flags (OF, SF, ZF, AF, PF, CF) which I > think depend only on the current instruction under execution. > > * the other one would contain the system flags which will be modified > by only very few instructions, even if most instructions read it. > > -- > Nilay > > On Fri, 6 Apr 2012, Watanabe, Yasuko wrote: > >> Hi Gabe, >> >> Do you already have an idea of how to fix this? If so, can you give >> me some pointers? >> >> Yasuko >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Gabe Black >> Sent: Thursday, April 05, 2012 6:12 PM >> To: [email protected] >> Subject: Re: [gem5-dev] Data dependency caused by flags >> >> Yes, you guys are right. This is a recognized problem, and I've made >> some changes over time which should make it easier to do this like a >> real x86 CPU would. I haven't yet, but it's on the horizon. I tend to >> be very busy, although circumstances may mean I have a little more or >> less time than normal for a little while so I don't know for sure >> when I'll get it fixed. If you have an idea of how to get it to do >> what you want locally, feel free. That will get you going, and when I >> get it fixed for real then you can start using that. >> >> Gabe >> >> On 04/05/12 17:18, Watanabe, Yasuko wrote: >>> Nilay, >>> >>> I agree with you. I think the dependencies of those flag bits should >>> be evaluated at bit level. >>> >>> Gabe and others, >>> >>> This change seems invasive. Do you know the best way to handle this? >>> >>> Yasuko >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On >>> Behalf Of Nilay Vaish >>> Sent: Thursday, April 05, 2012 3:35 AM >>> To: gem5 Developer List >>> Subject: Re: [gem5-dev] Data dependency caused by flags >>> >>> The code for the function genFlags() in >>> src/arch/x86/insts/microregop.cc suggests that the values of flag >>> bits not updated by the ADD instruction need to be retained. This >>> means that the previous values need to be read and written again, >>> which means the second ADD can be dependent on a value written by >>> the first ADD. If the dependencies were evaulated at bit level, then >>> these instructions would not be dependent. >>> >>> -- >>> Nilay >>> >>> On Thu, 5 Apr 2012, Watanabe, Yasuko wrote: >>> >>>> I ran O3 CPU in FS mode in x86 with a simple microbenchmark and got a >>>> much lower IPC than the theoretical IPC. The issue seems to be data >>>> dependencies caused by (control) flags, not registers, and I am >>>> wondering if anyone has come across the same issue. >>>> >>>> The microbenchmark has many data independent ADD instructions >>>> (http://repo.gem5.org/gem5/file/570b44fe6e04/src/arch/x86/isa/insts/g >>>> e >>>> neral_purpose/arithmetic/add_and_subtract.py#l41) >>>> in a loop. On a 2-wide out-of-order machine with enough resources, >>>> the IPC should be two at a steady stated. However, the IPC only goes >>>> up to one. What is happening is that even though the ADDs have two >>>> source and one destination registers and a flag to set in x86, gem5 >>>> adds one extra flag source register to the ADDs. As a result, each >>>> ADD becomes dependent on the earlier ADD's destination flag, >>>> constraining the achievable IPC to one. >>>> >>>> Here is an example sequence with physical register mappings: >>>> ADD: S1=98, S2=9, S3=2, D1=82, D2=105 (flag) >>>> ADD: S1=92, S2=9, S3=105 (flag), D1=79, D2=90 ... >>>> >>>> Physical registers 98, 9, and 92 are ready when those two ADDs are >>>> renamed; however, as you can see, the second ADD has to wait for the >>>> first ADD because of the extra flag source register S3. When I >>>> removed those flags in the macroop definition, the IPC jumped up >>>> from 1 to 1.7. >>>> >>>> Does anyone know why the ADD has to read the flags, even though the >>>> x86 manual does not say that? Those flags should just cause >>>> write-after-write dependency, not read-after-write. >>>> >>>> Yasuko >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
