On Tue, Sep 06, 2011 at 05:19:23PM -0400, Ron Wilson wrote: > On Tue, Sep 6, 2011 at 4:21 PM, Martin S. Weber <[email protected]> wrote: > > (and many, many, many, many more lines like that). This seems to be because > > of the calls to asm() ... I don't know how to fix that. FYI, after > > preprocessing, the first instruction of line 104 looks like: > > > > qq[4]+=((qq[1]&(qq[2]^qq[3]))^qq[3])+(block[0] = (({ unsigned > > int y; asm("rorl" " %1,%0" : "=r" (y) : "I" (8), "0" (block[0])); > > y; })&0xFF00FF00) |(({ unsigned int y; asm("roll" " %1,%0" : > > "=r" (y) : "I" (8), "0" (block[0])); y; })&0x00FF00FF))+0x5A827999+({ > > unsigned int y; asm("roll" " %1,%0" : "=r" (y) : "I" (5), "0" > > (qq[0])); y; }); > > The asm() calls are being used to invoke the rotate instructions. C > does not have operators for peforming bitwise rotation of an operand > and emulating a rotate using shifts is messy and very ineficient: > > unsigned int rotateLeft(unsigned int x, unsigned int n) > { > unsigned int t; > > t = x >> (SIZEOFINT - n); > return ((x << n) | t); > }
Well, the comment in the function is definitely wrong. So far it looks like GCC doesn't want to use left rotates other than by 1 (which has a smaller encoding, so could be the peep hole optimizer). It does seem to encode some of them as ror with large constant, which is fine. The diff is large enough that ATM I have no f**king clue what it is doing though. Joerg _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
