On Sun, 8 Nov 2009, Gabe Black wrote: > I can definitely see how this would be a pain to find, and I'm surprised > a benchmark was so sensitive.
Well, one of the symptoms is an off-by-one error, which doesn't sound like much, but after a subtraction this changed a multiplier from 1 to 2 which can cause a big difference. In addition to fixing lucas, the patch also fixes equake. > As long as float->double->uint32_t gets > the same answer as float->double->float->uint32_t (and I'm willing to > believe it does) then I don't think the srcSize==4 case will change, and > it should fix the srcSize==8 case. The problem (I think) is that the casting conversions do normal rounding, and the instruction that turned up this problem was doing truncation (rather than rounding). > Please give the attached program from > qemu a try on hardware and in M5 and make sure everything (except the > last 23 lines, fpuc... down) still matches. If everything there is fine > and the regressions pass, go ahead and commit it. Thanks! I ran the test and it showed the same results with and without the patch. So I'll commit the change once I run a few more tests. I compared the results of the qemu test to real hardware too, I notice that the m5 shldw instruction has some issues which I'll look at if I get the chance. Vince _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
