FPU and MMX

[Merrick]

OK. I'm sorry if this is one of those RTFM questions, but I'm a little confused about some CPU behavior I'm seeing. I've written an FFT routine as a DLL and while developing it I *really* could have used a good debugger. but I finished it and it works fine. So I decided I wanted to solve the debugger issue now before I needed it again. I finally got WinDBG up and running, which is a joy, because I can load my VS front end code is as well as my MASM code and step through all of it. Make's life much easier. So for giggles I loaded up my VB front end and started stepping through the FFT routine. And while watching the CPU registers I noted something that I think is really strange - and which I don't at all understand.

At command like: fldpi results in 3.14159265358979 in st[0], just like you'd expect - but it also caused the mm7 register to change to c90f:daa2:2168:c235. In fact, many FPU commands cause changes not only to the FPU stack but mmx registers. Here is a short list:

   fsin     mm6 = c8bd:35e1:4da1:5f0f   (depends on value in st[0])
   fld1    mm7 = 8000:0000:0000:0000
   fldz     mm7 = 0000:0000:0000:0000

I haven only observed mm5-mm7 being modified by calls to the FPU so far.

The only thing I can think of is that somehow WinDBG is using the mmx registers. But that doesn't seem right, becuase how would I debug mmx code that way?

Very odd. Any ideas?

[dsouza123]

The same registers are used for both FPU and MMX,
the MMX are mapped to the FPU registers, they use the lower 64 bits of the 80 bit FPU registers.
SSE-SSE4 use a separate set of 128 bit registers.

[Merrick]

OK. Now the fldz and fld1 resutls make sense.
It seems, though, that st[0] is mapped to mm7 rather than mm0. Interesting.

Thanks!

[stanhebben]

It seems, though, that st[0] is mapped to mm7 rather than mm0. Interesting.

Note that the FPU is a stack - based system, while the MMX is register-based. So next time st[0] will be mm0. (or mm6)