x86-64

I'm trying to understand the right way to use fences when measuring time with RDTSC/RDTSCP. Several questions on SO related to this have already been answered elaborately. I have gone through a few of them. I have also gone through this really helpful article on the same topic: http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/ia-32-ia-64-benchmark-code-execution-paper.pdf However, in another online blog, there's an example of using LFENCE instead of CPUID on x86. I was wondering how LFENCE prevents earlier stores from contaminating the RDTSC measurements. E.g. <Instr A>

While solving a bug I came across a difference between import jump tables of two Win64 DLLs. 64bit version of kernel32.dll uses plain FF25 jmp instruction in its import jump tables. On the other hand 64bit version of advapi32.dll uses 48FF25 which indicates REX.w=1 prefix before the jmp opcode. However, both seem to have 32bit operand specifying a RIP+offset address. Is there any meaning for REX.w prefix on this specific opcode? I'm not working with machine code often, so please excuse any factual mistakes. The REX.W prefix is ignored. In 64-bit mode the FF /4 opcode is always has a 64-bit

The GCC compiler $ gcc --version gcc (GCC) 4.8.2 ... doesn't generate an inc assembly instruction, where it could actually be useful, like in this C program: int main(int argc, char **argv) { int sum = 0; int i; for(i = 0; i < 1000000000L; i++) <---- that "i++" sum += i; return sum; } Instead, it generates an add instruction: 0000000000000000 <main>: 0: 31 d2 xor %edx,%edx 2: 31 c0 xor %eax,%eax 4: 0f 1f 40 00 nopl 0x0(%rax) 8: 01 d0 add %edx,%eax a: 83 c2 01 add $0x1,%edx <---- HERE d: 81 fa 00 ca 9a 3b cmp $0x3b9aca00,%edx 13: 75 f3 jne 8 <main+0x8> 15: f3 c3 repz retq Why does it do this?

I just want to build this on my development machine -- the binary install from Python.org is still 32 bits and installing extensions (MySQLdb, for example) is driving me nuts with trying to figure out the proper flags for each and every extension. Clarification: I did NOT replace the system Python, I just installed the Python.org binary into its normal place at /Library/..., not /System/Library/.... Everything else seems to build 64 bit by default, and the default Python 2.6.1 was 64 bit (before I replaced it with the Python.org build figuring it was a direct replacement)` I just want a 64 bit

Concerning the following small code, which was illustrated in another post about the size of structure and all the possibilities to align data correctly : struct { char Data1; short Data2; int Data3; char Data4; } x; unsigned fun ( void ) { x.Data1=1; x.Data2=2; x.Data3=3; x.Data4=4; return(sizeof(x)); } I get the corresponding disassembly (with 64 bits) 0000000000000000 <fun>: 0: 55 push %rbp 1: 48 89 e5 mov %rsp,%rbp 4: c6 05 00 00 00 00 01 movb $0x1,0x0(%rip) # b <fun+0xb> b: 66 c7 05 00 00 00 00 movw $0x2,0x0(%rip) # 14 <fun+0x14> 12: 02 00 14: c7 05 00 00 00 00 03 movl $0x3,0x0(%rip) # 1e