On Sat, 7 Nov 2009, Gabe Black wrote: > If there's some static setting of the status word that makes life > easier, we could just install that at process start up for now. The ABI > seems to specify what a program can expect, but I don't think that > actually gets installed anywhere. If it's something that's expected to > change, I would strongly prefer implementing the status word correctly > instead of a hack that makes this case work but might trip somebody up > silently in the future. At minimum, we should throw in a "warn" microop > (specified in arch/x86/isa/microops/debug.isa) so that people know > something suspicious is happening.
we'll need to implement the status word correctly. Many instructions modify and read it. The sin/cos routine does when it detects an overflow. That means that the current sin/cos routines I posted are simplistic, in theory the floating point error codes need to be checked and the status word updated appropriately. > These look good. Do we want microops that do such complicated > operations? They're arguably not very important performance wise and > would be obnoxious to fully build out, but it seems really inaccurate > this way. I'm not apposed to either way, but we should come up with a > strategy that makes sense. Maybe we did already and I'm just behind the > times. I did some tests, and the fsincos instruction on actual hardware takes about an average of 60 uops on AMD Barcelona and around 150 uops on Pentium D. For m5, would we want to fully emulate this? It would involve some sort of polynomial-based method of calculating the values and I'm guessing it will be a pain to implement. At first I though I'd check how the other architectures implemented trig functions, momentarily forgetting that x86 is one of the few architectures crazy enough to do this in hardware. Vince _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
