Problem with wmmx in smart device project with VS 2008

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

jtch - 03 Jun 2008 15:58 GMT

I have a smart device project using the Windows Mobile 5 SDK with VS2008.
There is a problem with the wmmx intrinsics in VS2008.
The high 32 bits of an __m64 variable are incorrect when executing a wmmx
instruction.

Below is a simple code that illustrates the problem.
I created a Win32 Smart Device console application for Windows Mobile 5.0
Pocket PC SDK.

#include "stdafx.h"
#include <mmintrin.h>

int _tmain(int argc, _TCHAR* argv[])
{
__m64 c;
BOOL res;
res = IsProcessorFeaturePresent(PF_ARM_INTEL_WMMX);
if (res)
{
c = _mm_set_pi16(4, 4, 4, 4);
}
return 0;
}

I have tried this code on a Dell Axim x51v PDA and on a Toshiba G900 phone.
The _mm_set_pi16() function only sets the first 32 bits of the __m64
variable c.
The same problem occurs with other wmmx intrinsics.
The same code works fine with VS2005.

Is this an issue with VS2008?
Has anyone else encountered this problem before?
Thanks.

Reply to this Message

Leonard Mosescu [MS] - 09 Jun 2008 16:35 GMT

Sorry for the late reply. What is the exact command line you use for the
code below?

The _mm_set_pi16() should expand to something like:

    tmcrr wr1, r0, r2
    tmcrr wr0, r1, r3
    wpackwss wr0, wr0, wr1

Is this what you see in your .cod file (/FAsc) ?

Signature

Thank you,
Leonard Mosescu, Microsoft Windows CE Compiler Team

This posting is provided "AS IS" with no warranties, and confers no rights.

> I have a smart device project using the Windows Mobile 5 SDK with VS2008.
> There is a problem with the wmmx intrinsics in VS2008.
[quoted text clipped - 30 lines]
> Has anyone else encountered this problem before?
> Thanks.

Reply to this Message

jtch - 09 Jun 2008 17:13 GMT

Thanks for your reply.

The command line options are:
/Od /D "_DEBUG" /D "_WIN32_WCE=0x501" /D "UNDER_CE" /D "WIN32_PLATFORM_PSPC"
/D "WINCE" /D "DEBUG" /D "_CONSOLE" /D "ARM" /D "_ARM_" /D "_UNICODE" /D
"UNICODE" /Gm /EHsc /MTd /fp:fast /GR- /Yu"stdafx.h" /Fp"Windows Mobile 5.0
Pocket PC SDK (ARMV4I)\Debug/wmmx_test.pch" /FAcs /Fa"Windows Mobile 5.0
Pocket PC SDK (ARMV4I)\Debug/" /Fo"Windows Mobile 5.0 Pocket PC SDK
(ARMV4I)\Debug/" /Fd"Windows Mobile 5.0 Pocket PC SDK
(ARMV4I)\Debug/vc80.pdb" /W3 /nologo /c /Zi /TP

The .cod file contains:

; 18 : c = _mm_set_pi16(4, 4, 4, 4);

00040    e3a02004    mov r2, #4
00044    e3a03004    mov r3, #4
00048    ec432001    tmcrr wr1, r2, r3
0004c    e3a02004    mov r2, #4
00050    e3a03004    mov r3, #4
00054    ec432000    tmcrr wr0, r2, r3
00058    eeb00081    wpackwss wr0, wr0, wr1
0005c    ed8d0102    wstrw wr0, [sp, #8]
00060    ed9d0102    wldrw wr0, [sp, #8]
00064    ed8d0104    wstrw wr0, [sp, #0x10]
00068    ed9d0104    wldrw wr0, [sp, #0x10]
0006c    ed8d0106    wstrw wr0, [sp, #0x18]
00070        |$LN1@wmain|

> Sorry for the late reply. What is the exact command line you use for the
> code below?
[quoted text clipped - 41 lines]
> > Has anyone else encountered this problem before?
> > Thanks.

Reply to this Message

Leonard Mosescu [MS] - 09 Jun 2008 23:44 GMT

That looks fine, what makes you believe that only the first (low?) 32 bits
of "c" are set? Are you reading the values back in your code or are you
inspecting the variable with the debugger? I'm trying to rule out a debugger
issue here.

Signature

Thank you,
Leonard Mosescu, Microsoft Windows CE Compiler Team

This posting is provided "AS IS" with no warranties, and confers no rights.

> Thanks for your reply.
>
[quoted text clipped - 75 lines]
>> > Has anyone else encountered this problem before?
>> > Thanks.

Reply to this Message

jtch - 10 Jun 2008 10:43 GMT

The debugger shows that only the low 32 bits are set and that the high 32
bits are unchanged.
If I try to use the return value in my code, the results are wrong too.
The same code gives the correct results when compiled with VS2005.

.

> That looks fine, what makes you believe that only the first (low?) 32 bits
> of "c" are set? Are you reading the values back in your code or are you
[quoted text clipped - 80 lines]
> >> > Has anyone else encountered this problem before?
> >> > Thanks.

Reply to this Message

Leonard Mosescu [MS] - 10 Jun 2008 16:42 GMT

Can you please send me a self contained repro that demonstrates the issue
without using the debugger?

Signature

Thank you,
Leonard Mosescu, Microsoft Windows CE Compiler Team

This posting is provided "AS IS" with no warranties, and confers no rights.

> The debugger shows that only the low 32 bits are set and that the high 32
> bits are unchanged.
[quoted text clipped - 93 lines]
>> >> > Has anyone else encountered this problem before?
>> >> > Thanks.

Reply to this Message

jtch - 11 Jun 2008 17:30 GMT

The following code writes the values to a text file.

Since reporting the problem, I have found that with this particular example,
the problem only happens when optimisation is disabled (/0d).
However, with a more complex calculation, the use of the wmmx intrinsics
still give incorrect results even when optimisation is on.
It is probably because in this simple case, the wmmx intrinsics get
optimised out by the compiler.

#include "stdafx.h"
#include <mmintrin.h>
#include <stdio.h>
int _tmain(int argc, _TCHAR* argv[])
{
__m64 c;
int c1, c2;
BOOL res;
FILE * fid;

c1 = c2 = 9;
res = IsProcessorFeaturePresent(PF_ARM_INTEL_WMMX);

if (res)
{
c = _mm_set_pi32(2, 1);
c1 = _mm_cvtsi64_si32(c);
c2 = _mm_cvtsi64_si32(_mm_srli_si64(c, 32));
fid = fopen("output.txt", "w");
fprintf(fid, "c1 = %d, c2 = %d", c1, c2);
fclose(fid);
}
return 0;
}

> Can you please send me a self contained repro that demonstrates the issue
> without using the debugger?

Reply to this Message

Leonard Mosescu [MS] - 12 Jun 2008 18:11 GMT

Thanks for the repro. Can you share the actual output values as well the
value you expect from this code?

Please note that the code below is different from your original report, can
you create a repro demonstrating the issue with _mm_set_pi16() as well?

Signature

Thank you,
Leonard Mosescu, Microsoft Windows CE Compiler Team

This posting is provided "AS IS" with no warranties, and confers no rights.

> The following code writes the values to a text file.
>
[quoted text clipped - 33 lines]
>> Can you please send me a self contained repro that demonstrates the issue
>> without using the debugger?

Reply to this Message

jtch - 13 Jun 2008 10:07 GMT

> Thanks for the repro. Can you share the actual output values as well the
> value you expect from this code?
[quoted text clipped - 39 lines]
> >> Can you please send me a self contained repro that demonstrates the issue
> >> without using the debugger?

Reply to this Message

jtch - 13 Jun 2008 10:31 GMT

Encountered a problem when posting the reply.
Here it is again.

The values in the text file when in debug mode are:
c1 = 1, c2 = 0

The correct values should be:
c1 = 1, c2 = 2
And are obtained when optimisation is turned on.

To reproduce the problem with _mm_set_pi16()
please replace _mm_set_pi32(2,1);
with _mm_set_pi16(4,4,4,4);

The values in the text file when in debug mode are:
c1 = 262148, c2 = 0

The correct values should be:
c1 = 262148, c2 = 262148
And are obtained when optimisation is turned on.

Reply to this Message

Leonard Mosescu [MS] - 18 Jun 2008 01:16 GMT

Thank you again, I'll investigate the issue.

Signature

Thank you,
Leonard Mosescu, Microsoft Windows CE Compiler Team

This posting is provided "AS IS" with no warranties, and confers no rights.

> Encountered a problem when posting the reply.
> Here it is again.
[quoted text clipped - 63 lines]
>> >> issue
>> >> without using the debugger?

Reply to this Message

Leonard Mosescu [MS] - 24 Jun 2008 18:15 GMT

I can confirm that the issue you're seeing here is a compiler bug, thanks
for reporting it.

The issue is related to loading/storing WMMX values (only 32bits are
loaded/stored in cases like this). Compiling with optimizations enabled may
result in the correct code in some cases but unfortunately it's not a
reliable workaround.

Signature

Thank you,
Leonard Mosescu, Microsoft Windows CE Compiler Team

This posting is provided "AS IS" with no warranties, and confers no rights.

> Encountered a problem when posting the reply.
> Here it is again.
[quoted text clipped - 63 lines]
>> >> issue
>> >> without using the debugger?

Reply to this Message

jtch - 01 Jul 2008 10:11 GMT

Are you able to give any estimate of when this bug is likely to be fixed?
Thanks.

> I can confirm that the issue you're seeing here is a compiler bug, thanks
> for reporting it.
[quoted text clipped - 71 lines]
> >> >> issue
> >> >> without using the debugger?

Reply to this Message

Leonard Mosescu [MS] - 03 Jul 2008 17:42 GMT

The fix will be included in the next release of the compiler (in PB or VS),
but I'm afraid I don’t have the details on when is going to happen.

Signature

Thank you,
Leonard Mosescu, Microsoft Windows CE Compiler Team

This posting is provided "AS IS" with no warranties, and confers no rights.

> Are you able to give any estimate of when this bug is likely to be fixed?
> Thanks.
[quoted text clipped - 78 lines]
>> >> >> issue
>> >> >> without using the debugger?

Reply to this Message