0

Check this code out

include 'win32ax.inc'

;.data


.code

start:

mov al,00000001b

add al,00000001b   ;even  =2     pf = 0
add al,00000001b   ;odd   =3     pf = 1
add al,00000001b   ;even  =4     pf = 0
sub al,00000001b   ;odd   =3     pf = 1
sub al,00000001b   ;even  =2     pf = 0
sub al,00000001b   ;odd   =1     pf = 0
sub al,00000001b   ;even  =0     pf = 1

.end start

The last two subtraction instructions should of set PF=1, then PF=0, so why doesn't it?

Also i'm using FASM, i'm debugging with ollydbg debugger.

old_timer
  • 69,149
  • 8
  • 89
  • 168
noob
  • 51
  • 6

1 Answers1

2

from wikipedia:

In x86 processors, the parity flag reflects the parity only of the least significant byte of the result, and is set if the number of set bits of ones is even.

so

result = 0  an even number of ones are set so pf = 1 is the right answer
result = 1 an odd number of ones are set so pf = 0 is the right answer
result = 2 an odd number of ones are set so pf = 0 is the right answer
result = 3 an even number of ones are set so pf = 1 is the right answer

1 = 0b00000001  one bit is set an odd number of bits set pf = 0
3 = 0b00000011 two bits are set pf = 1
7 = 0b00000111 three bits are set pf = 0
12 = 0b00001100 two bits are set pf = 1
old_timer
  • 69,149
  • 8
  • 89
  • 168
  • well heres my confusion – noob Feb 10 '15 at 22:01
  • sub al,00000001b ;odd =3 pf = 1 sub al,00000001b ;odd =1 pf = 0 – noob Feb 10 '15 at 22:01
  • they are both odd but have different results, if it's 3 then PF=1, if it's 1 PF=0 – noob Feb 10 '15 at 22:04
  • actually im still confused – noob Feb 10 '15 at 22:26
  • PF is set, when the number of 1s is even or zero. 0: 0000 PF=1 // 1: 0001 PF=0 // 2: 0010 PF=0 // 3: 0011 PF=1 // 4: 0100 PF=0. Thus it is only set if the result is 0 and 3 in your example. – Welcor Feb 10 '15 at 22:29
  • when my eax register says 7742D303 PF = 1, when my eax register says 7742D301 PF = 0? I haven't read your comment yet blechdose you posted before me – noob Feb 10 '15 at 22:30
  • yeah, should be. In your case, your mistake is to look at the decimal number odd/eveness, instead of looking at the dualcode itself. Be carefull, that is different from the Paritybits used in ASCII and so on. – Welcor Feb 10 '15 at 22:31
  • I'm going to go back and mess around with my code for a bit so this can sink in better – noob Feb 10 '15 at 22:34
  • yeah, the problem is, that debugger show hexnumbers, that can be quite confusing, when you think about stuff like parity bit, signumflag and stuff like that. I had moments like that, too, until i finally checked out the dualcode of the result – Welcor Feb 10 '15 at 22:36
  • Yeah that is exactly what i was doing, i was looking at what number the bits represented instead of counting how many bits were turned on. No wonder i was confused. Thanks everyone for the help i can't thank you enough. – noob Feb 10 '15 at 23:17