On 7/26/2014 9:29 AM, JonY wrote:
> On 7/26/2014 22:39, Ozkan Sezer wrote:
>> On 7/26/14, dw <limegreenso...@yahoo.com> wrote:
>>> Well, since no one else has responded, what would you say to this
>>> (attached)?
>>>
>>> If you like, I can write up a detailed description about why I believe
>>> this is the way to go, but hopefully the comments and code speak for
>>> themselves.  This should give the correct definitions for 32bit, LP64
>>> and LLP64.
>>>
>>> If this is approved, someone else will have to commit it.  git is not my
>>> thing.
>> Kai and/or Jon should be approving or rejecting this.
>>
> I'm not familiar enough with these calls to comment on them, but if
> Cygwin uses it, keep in mind that Cygwin is LP64, not LLP64 like Windows is.

That's the crazy thing about all this: It truly isn't that complicated 
to understand.  Here is the actual code needed for _lrotl:

unsigned long _lrotl(unsigned long __X, int __C)
{
   return (__X << __C) | (__X >> ((sizeof(long) * 8) - __C));
}

And you know what you have to change to get this to support 32bit? Or 
LP64?  Or LLP64?  NOTHING!  That's the whole dang thing there in 1 line 
of code.

But instead of using this simple, easy to understand, platform neutral 
and readily inlined code, we've got macros, #undefs, weird pragmas, 
#ifs, imports, etc.  The only part of this that's hard to understand is 
why everyone has made this so freaking complicated.

<deep breath>

Ok then, the challenge here is take what we've got and try to make the 
best of things. So this is what my patch does:

1) If x86intrin.h has been included, it's got a nice inline version of 
this function.  Now that the gcc team has fixed it, this is the best choice.
2) If we are dealing with 32bit longs (either x86 or LLP64), just add 
the prototype and let things get resolved from msvcrt.dll.  Not as nice 
as x86intrin's inline, but it works (and is what the existing code does).
3) If we are dealing with 64bit longs (ie 64bit cygwin), we macro _lrotl 
to _lrotl64, which will get resolved from msvcrt.dll.  Again, not 
ideal.  But unlike the existing definition in stdlib.h (which always 
maps to msvcrt.dll's 32bit _lrotl), it gives the right answer.

And while I think it would be a good idea to add this function to 
intrin-impl.h so that this "intrinsic" function would be, well, 
intrinsic (instead of imported), that seems like a discussion for 
another day.

dw

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to