Re: [Mingw-w64-public] Errors in winnt.h - memory clobber

2013-03-29 Thread dw
> Please take the hostility down a notch. I don't see why it's necessary. I apologize (to both you and Kai) if that's how this came across. That was not my intent. I routinely use weekends to work on new puzzles. The reason I suggested it would give him plenty to think about over the weekend

Re: [Mingw-w64-public] Errors in winnt.h - memory clobber

2013-03-29 Thread Ruben Van Boxem
2013/3/29 dw > 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.

Re: [Mingw-w64-public] Errors in winnt.h

2013-03-29 Thread dw
> I agree that where the code would really be suboptimal, the intrinsics > should be implemented using more efficient means. However, I doubt > that, e.g., _InterlockedAdd() has the same problem. Each intrinsic > should be evaluated separately. Fair enough. When the first couple of intrinsics

Re: [Mingw-w64-public] Errors in winnt.h - memory clobber

2013-03-29 Thread dw
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. In my original post, I said that I wanted to add the memory cl

Re: [Mingw-w64-public] Errors in winnt.h

2013-03-29 Thread Václav Zeman
On 28 March 2013 22:32, dw wrote: > On 3/28/2013 3:52 AM, Václav Zeman wrote: >> Why are those intrinsics even implemented using inline assembler >> instead of GCC's own built-in functions like __builtin_ffs() for >> _BitScanForward(), __sync_add_and_fetch() for _InterlockedAdd(), etc.? > Actually,

Re: [Mingw-w64-public] Errors in winnt.h

2013-03-28 Thread dw
Actually, I looked at doing just that. And while this is possible, my experience suggest that gcc's built-ins don't do *quite* the same thing. For example, __builtin_ffs() returns 0 if no bits are set, or the 1-based bit position if a bit is set. BitScanForward return a BOOL to indicate no b

Re: [Mingw-w64-public] Errors in winnt.h - volatile

2013-03-28 Thread dw
Hello Kai. Thank you for the detailed response. It takes someone brave to wade into a post that long. To respond to your points: > I disagree here. > The cite from http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html Well, it's good to know that we are (literally) on the same page about where t

Re: [Mingw-w64-public] Errors in winnt.h

2013-03-28 Thread Václav Zeman
Why are those intrinsics even implemented using inline assembler instead of GCC's own built-in functions like __builtin_ffs() for _BitScanForward(), __sync_add_and_fetch() for _InterlockedAdd(), etc.? -- VZ -- Own the Fu

Re: [Mingw-w64-public] Errors in winnt.h

2013-03-28 Thread Kai Tietz
Hello dw, I try my best to read through your long e-mail ... (I want to get the kudos ;) ). And thank you for reviewing this inline-assembler. This is much appreachiated. Most of this stuff is implemented in a way "it works for me", but code didn't had a general review. At the beginning I want