MMX registers ?

[rrr314159]

I am still astounded at the level of ignorance here,

True I am somewhat ignorant about the issue, that's why I kept saying "AFAIK". Here's what I've been assuming,

1) FPU and MMX share same storage so can't be used at the same time.
2) You can't assume MS won't use FPU during some API calls (in both older and new Windows).
3) You should clear the FPU stack when making (most) API calls, if only just to be on the safe side.
4) You can't count on MMX registers preserved across API calls.

Since I don't use MMX, and finish FPU calcs and leave all registers free before returning from the procedure anyway, I've never bothered to find out for sure if these assumptions are correct. So, are they?

[raymond]

1) FPU and MMX share same storage so can't be used at the same time.
Although I'm not familiar with the MMX instructions, I think you can specify which registers are to be used. It could thus be possible to use both the FPU and MMX at the same time. However, since the MMX is used primarily for MultiMedia programming and ALL registers would normally be used, there may not be any usefulness for sharing with the FPU.

2) You can't assume MS won't use FPU during some API calls (in both older and new Windows).
I'm not so sure that MS programmers know how to use FPU instructions. However, they seem to be using the MMX instructions (which use the same hardware as the FPU instructions) for all their computations, specially those required for window sizing.

3) You should clear the FPU stack when making (most) API calls, if only just to be on the safe side.
In my opinion, there is NO need for such precaution. As many have already noticed, MMX instructions don't seem to require free registers (as do the FPU instructions). If float computations should be required by the OS, their compiler must certainly free whatever register(s) may be needed in order to avoid "invalid operation exceptions".

4) You can't count on MMX registers preserved across API calls.
TRUE. However, my interpretation of the intent of this thread is that the use of MMX registers is NOT for long term storage of data but simply as very temporary storage for transmitting some extra data to your own  procedures which would be written specifically to accept such transmission.

[rrr314159]

Thanks raymond,

I assume you're kidding about MS programmers not knowing how to use FPU. I always leave FPU cleared out of habit, regardless of API calls, seems safest and cleanest that way; but agree it shouldn't cause the OS trouble if I don't. I thought we were talking about (possibly) using MMX registers for storage across API calls. Apart from those points we're on the same page.

[Gunther]

4) You can't count on MMX registers preserved across API calls.
TRUE. However, my interpretation of the intent of this thread is that the use of MMX registers is NOT for long term storage of data but simply as very temporary storage for transmitting some extra data to your own  procedures which would be written specifically to accept such transmission.

Are you sure? The FXSAVE and XSAVE area contains room for FPU/MMX registers. That's necessary for task switches. Why not for API calls?

Gunther

[rrr314159]

Personally I'm not sure MMX is not preserved by ABI. But MS doesn't say you can count on that anywhere. FPU stack is preserved, BTW, by printf family. But AFAIK even if you test all your API calls you can't be sure they won't break later. Anyway FXSAVE and XSAVE don't guarantee anything. A task switch preserves rax and rcx (etc) also, but they can still be trashed by API calls.

[Gunther]

But MS doesn't say you can count on that anywhere. FPU stack is preserved, BTW, by printf family.

That's the tricky point. You're right. It would be an enormously amount of work to test all the API calls.

Gunther

[hutch--]

I wonder at the logic here, if the 64 bit ABI says the MM registers are not specified, then you treat them as unspecified registers in much the same way as the volatile registers in either win32 or 64. Leaving data in an unspecified register when there is the potential for them to be used in intervening code is just bad programming practice. I used to see these donkeys testing code under win32 and if they could get away with avoiding the specs of the ABI OR lack of them on one Windows version, they thought they could do it on all versions. There were many confused programmers when their code went BANG on another OS version.

The simple rule is ANY volatile register is unsafe when it can be used by other code.


; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    include \masm64\include\masm64rt.inc

    .code

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

entry_point proc

    .stack

    LOCAL.mm0   :QWORD
    LOCAL.mm1   :QWORD
    LOCAL.mm2   :QWORD
    LOCAL.mm3   :QWORD
    LOCAL.mm4   :QWORD
    LOCAL.mm5   :QWORD
    LOCAL.mm6   :QWORD
    LOCAL.mm7   :QWORD

    movq .mm0, mm0
    movq .mm1, mm1
    movq .mm2, mm2
    movq .mm3, mm3
    movq .mm4, mm4
    movq .mm5, mm5
    movq .mm6, mm6
    movq .mm7, mm7

  ; -------------------------------------
  ; use and abuse your MMX registers here
  ; -------------------------------------

    movq mm0, .mm0
    movq mm1, .mm1
    movq mm2, .mm2
    movq mm3, .mm3
    movq mm4, .mm4
    movq mm5, .mm5
    movq mm6, .mm6
    movq mm7, .mm7

    void(ExitProcess,0)

    ret

entry_point endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    end