On Mon, Mar 4, 2013 at 1:13 AM, Maciej Fijalkowski wrote: >print sys.maxint >>>> print hex(sys.maxint) 0x7fffffffffffffff
That works. Not so obvious though. On Monday, March 4, 2013 1:20 AM, Antonio Cuni wrote: >just a wild guess: is it possible that you generated pyc files with a 32bit >version of pypy and then imported it on a 64bit one? Ding! That's exactly what was afflicting me. I had no idea the pyc files would not get refreshed on the platform change. After 'rm *pyc' I now see substantially better code! Importantly, the arithmetic function calls are reduced to the single x86 instructions that Carl Friedrich saw. For the record, this is what I now see: BINARY_XOR i39 = ((pypy.objspace.std.intobject.W_IntObject)p35).inst_intval [pure] mov r8,QWORD PTR [r10+0x8] i40 = ((pypy.objspace.std.intobject.W_IntObject)p37).inst_intval [pure] mov rdi,QWORD PTR [r13+0x8] i41 = int_xor(i39, i40) mov rcx,r8 xor r8,rdiLOAD_CONST 2147483648 BINARY_AND i43 = i41 & 2147483648 mov r11d,0x80000000 and r8,r11LOAD_CONST 0 COMPARE_OP == i45 = i43 == 0 cmp r8,0x0 jne 0x9468582b It's strange the AND doesn't use the imm32 form like the COMPARE does. It's unfortunate the COMPARE doesn't suppress the cmp and reuse the zero flag from the prior instruction. Looking at the self.low and self.high references prior to the XOR, I'm assuming the null guard is because their types are a PyInt_Type which can always have a None (Python semantics). But I don't understand why the work isn't moved out of the loop (or maybe it is and I just can't tell). Thanks everyone, -Roger _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
