On Sun, May 29, 2011 at 10:06 PM, Ali Saidi <sa...@umich.edu> wrote: > That would do it. Misc register in the o3 are always available to be read. > There is no dependency tracking with misc registers in the o3, so I don't > think it should matter. >
If you don't mind my asking, how is this made safe? Is it some form of speculation? > However, it would be good to fix the cases where FpscrExc and FpscrQc are > read unnecessarily. If you've got some time to do it that would be > appreciated. > > Thanks, > Ali > > > > > On May 29, 2011, at 8:55 PM, Marc de Kruijf wrote: > > > > On Sun, May 29, 2011 at 7:59 PM, Ali Saidi <sa...@umich.edu> wrote: > >> >> On May 29, 2011, at 3:03 PM, Marc de Kruijf wrote: >> >> > I'm seeing all (or almost all) ARM floating point operations serializing >> on the MISCREG_FPSCR_EXC register. >> >> I don't believe this is the case, and looking at the code seems to confirm >> that. Since it's a miscellaneous register, MISCREG_FPSCR_EXC isn't renamed, >> and is thus always available at issue. Writes to it are committed in-order >> at commit. >> > > I should have clarified and said it was serializing my CPU model, not O3 > :). However, I thought O3 would be serialized too because of the > read-modify-write by every FP instruction. Miscellaneous registers are > treated differently in O3? I don't quite understand how an older > instruction can issue before a younger instruction in this situation... I > guess I will have to look at the O3 code. > > > >> >> > Are FP operations truly serialized even for real ARM OoO processors >> (i.e. A9/A15)? I don't quite understand it because aren't FP exceptions >> reported imprecisely for ARM? >> > >> > If I look at the .isa files it seems to be because the FP operations are >> reading the floating point "mode" information from the exception register, >> and then -- presumably, it is not clear -- updating the exception >> information. This makes sense, but wouldn't a simpler and faster solution >> be to simply serialize on FP mode updates? I'm assuming updates to the >> exception information are information-preserving and hence WAW violations >> are not an issue. >> >> It seems like the FpscrExc and FpscrQc operands are unnecessarily read in >> many cases, however, as I mentioned above that shouldn't cause any stalling. >> >> Ali >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@m5sim.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > _______________________________________________ > gem5-users mailing list > gem5-users@m5sim.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > _______________________________________________ > gem5-users mailing list > gem5-users@m5sim.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list gem5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
