2013/3/29 dw <[email protected]>
> While I haven't heard back from you about my response re volatile, I'm
> going to go ahead and write my post about why I think my understanding
> of the memory clobber is correct. Should give you plenty to think about
> over the weekend.
>
Please take the hostility down a notch. I don't see why it's necessary.
>
> In my original post, I said that I wanted to add the memory clobber to
> the __sto* routines. Your response was "Please don't do that."
>
> Now, if my understanding of how the memory clobber works is correct,
> this provides an excellent opportunity to prove it. Consider this code
> (__stosb copied from existing winnt.h):
>
> #include <stdio.h>
> #include <assert.h>
>
> typedef unsigned char BYTE;
> typedef unsigned char *PBYTE;
> typedef unsigned long long SIZE_T;
> typedef void VOID;
>
> __CRT_INLINE VOID __stosb(PBYTE Dest,BYTE Data,SIZE_T Count)
> {
> __asm__ __volatile__
> (
> "rep; stosb" :
> [Dest] "=D" (Dest), [Count] "=c" (Count) :
> "[Dest]" (Dest), "a" (Data), "[Count]" (Count)
> );
> }
>
> int main(int argc, char* argv[])
> {
> struct
> {
> int a;
> int b;
> } c;
>
> c.a = atoi(argv[1]);
> c.b = atoi(argv[2]);
>
> __stosb((PBYTE)&c, 0, sizeof(c));
>
> printf("%u %u\n", c.a, c.b);
> }
>
> If I compile this with:
>
> c++.exe -o %1.exe -march=native -mwin32 -Os -m64 %1.cpp
>
> and execute it with the line:
>
> n 1 2
>
> What result would you expect to get printed?
>
> a) 0, 0
> b) 0, 2
> c) 1, 2
>
> Without the memory clobber (your solution), you get (b). With the
> memory clobber (my solution), you get (a). I believe (a) is correct.
>
This is not the behavior I see. If I fix your buggy code to read
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <intrin.h>
int main(int argc, char* argv[])
{
struct
{
int a;
int b;
} c;
c.a = atoi(argv[1]);
c.b = atoi(argv[2]);
__stosb((unsigned char*)&c, 0, sizeof(c));
printf("%u %u\n", c.a, c.b);
}
so that it actually compiles, I get
g++ main.cpp -o test && test 1 2
0 0
And more importantly
cl main.cpp /link /out:test.exe && test 1 2
0 0
I tested this with pretty much any build I have (which includes
MinGW-w64 trunk and v2.0.7 headers/libs), including clang 3.2. All 64
and 32-bit (including MSVC 2012). Optimization options changed
nothing.
> This demonstrates the errors you get if you omit the "memory" clobber
> when it is required. If I get a chance, I'll create a second sample
> that shows the performance penalty you pay for using it when it isn't
> necessary.
>
Sorry, I don't see any unexpected behavior here (solely by comparing to
MSVC output). So either I'm misunderstanding you, or what is currently in
MinGW-w64 is correct.
Ruben
> dw
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel(R) Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest. Compete
> for recognition, cash, and the chance to get your game on Steam.
> $5K grand prize plus 10 genre and skill prizes. Submit your demo
> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
> _______________________________________________
> Mingw-w64-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
