0

I think I'm not quite understanding what the PF is in the eflags register. Here are two comparisons I have done to see how it works:

 # a > b -- 0b01
 mov $4, %rax
 mov $3, %rbx
 cmp %rax, %rbx  # [ CF PF AF SF IF ] *PF* included

 # a > b -- 0b10
 mov $5, %rax
 mov $3, %rbx
 cmp %rax, %rbx  # [ CF AF SF IF ]

 # a = b -- 0b00
 mov $5, %rax
 mov $5, %rbx
 cmp %rax, %rbx  # [ PF ZF IF ] *PF* included

In the first operation, the comparison would produce 1 or 0x01 and in the second it would produce 2 or 0x10. Why then is the parity flag set in the first one but not the second one, since both of them have one bit set to 1.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
David542
  • 104,438
  • 178
  • 489
  • 842
  • 1
    `3-4 = 0xffffffffffffffff`. An even number of bits set in the low byte. Don't forget, this is AT&T syntax – Peter Cordes Aug 28 '20 at 04:12
  • @PeterCordes I see. But why does it do the operation as `4-3` instead of `3-4` for the comparison? – David542 Aug 28 '20 at 04:14
  • 2
    It doesn't do `4-3`. It does `3-4`. AT&T syntax is always destination-last, operand list reversed vs. Intel syntax. So `cmp %rax, %rbx` is like `sub %rax, %rbx` but without modifying the destination (RBX). It would be even more weird if instructions like `cmp` didn't have their operand-lists reversed. – Peter Cordes Aug 28 '20 at 04:16
  • @PeterCordes got it -- that's a bit tricky actually, thanks for clarifying how the `cmp` works in doing the flags. – David542 Aug 28 '20 at 04:19

0 Answers0