2013/8/3 dw <limegreenso...@yahoo.com>:
> I have some (non-asm) questions about _lrotr (long rotate right).
>
> Looking at intrin.h, it uses a #ifdef __x86_64__ to change the parameters
> between LONG32 and LONG64. But that doesn't seem right. Shouldn't it be
> looking at __LP64__? Since this is mapped to msvcr*.dll in the .def files,
> will this even work correctly?
Well, those prototype hacks are done in intrin.h and in stdlib.h for
rotate-left/right 32-bit/64-bit. The reason for these hacks can be
found in gcc's ia32intrin.h header, where these functions are
implemented. Eg the 64-bit variant via define to _rotq functions. As
for LLP64 long isn't 64-bit wide, we need to override it. For LP64
(cygwin-mode) indeed we might not need to do those redefines.
> If we play this game with the #ifdef, that leaves no methods for 32 bit
> rotations under LP64. There will be 8, 16, and 2 different functions for
> 64bit (_lrotr and _rotr64). Are we sure that's what we want?
What? 32-bit version is of course present and called _rotr and _rotl
(rotate left/rotate right). The 64-bit functions are _rolq and _rorq.
MS world introduced additional here _rotl64 and _rotr64, which need
to be mapped to _rolq and _rorq.
> Also in intrin.h, it uses #pragma push_macro ("_lrotr") and #undef _lrotr.
> As I understand it, these both only apply to macros, and _lrotr is not a
> macro. I think this should be deleted.
We want to make sure that those functions aren't overriden by any
macros ... see here again gcc's intrin-headers for details.
>
> I realize that the "l" in _lrotr is supposed to stand for long. However, I
> believe it should still perform a 32bit rotation, even under LP64. That
> would give us:
Hmm, please tell how to resolve difference between gcc's and MS
intrinsic-defintion. And please note that changing of these headers
in gcc was already tried by me in the past and was rejected. So we
need to work-a-round that.
These work-a-rounds btw are exaclty the reason why we strictly
recomment that users are including intrin.h header instead of
including directly gcc's headers. See also _mm_malloc & co ...
> unsigned char _rotr8 (unsigned char _val, int _Shift);
> unsigned short _rotr16(unsigned short _val, int _Shift);
> unsigned __LONG32 _lrotr (unsigned __LONG32 _val, int _Shift);
> unsigned __int64 _rotr64(unsigned __int64 _val, int _Shift);
you miss _rotr/_rotl ...
>
> Note that mingw-w64-headers\crt\stdlib.h and
> mingw-w64-headers\include\winnt.h do the same thing.
Right we need to map things without including intrin.h header ...
intrin.h does too much, we (or user) might not want in all cases.
> dw
So I have strong doubts about the intend of your patch.
Kai
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
