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. 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
