I am struggling to understand the following code snippet in assembler:
if ( EAX >= 5 )
EBX = 1;
else
EBX = 2;"
In assembler this can be written as follows (according to my book), emulating the jge instruction you’d normally use in terms of "simpler" branches that only look at one flag at once:
1 cmp eax, 5 ;(assuming eax is signed)
2 js signon ;goto signon if SF = 1
3 jo elseblock ;goto elseblock if OF = 1 and SF = 0
4 jmp thenblock ;goto thenblock if SF = 0 and OF = 0
5 signon:
6 jo thenblock ;goto thenblock if SF = 1 and OF = 1
7 elseblock:
8 mov ebx, 2
9 jmp next
10 thenblock:
11 mov ebx, 1
12 next:
I can understand that the resulting flags can be: (if ( EAX >= 5 )):
SF = 0 & OF = 0
But I cannot understand how the flags can be:
SF = 1 & OF = 1? What computation gives this?
To clarify what I mean:
If eax is in the lower negative bound it would potentially overflow into the positive by subtracting 5. If it would be in the upper positive bound it could not overflow into the negative by subtracting 5?
Much easier to think of these in terms of 3 bit numbers, it all scales. Hmmm, if this is signed (you didnt specify/post in your high level code) then four bits is better because you used a 5. Walk through the numbers near 5 (this shows the output of the alu)
Now you have to understand how the hardware works. Some processor families when you do a subtract invert the carry flag coming out of the alu, others dont. either way you can definitely see a state change at the 5 – 5 point. And you dont need the carry flag here anyway, code doesnt use it.
In case you are doing signed math, then try some negative numbers as well.
And that sheds some light on the problem.
signed overflow is defined as the carry in being not equal to the carry out on the msbit of the adder. That can get messy so we just need to know where that boundary is.
and so on. Using this 4 bit model, in a signed interpretation we are limited to +7 (0b0111) down to -8 (0b1000). So the after -3 – 5 we will get into trouble:
The latter five are a signed overflow, the signed result cannot be represented in the number of bits available. (remember we are playing with a four bit system for now, that top bit is the carry bit, visually remove it when you look at the result).
The signed flag is simply the msbit of the result, which is also changing a the interesting boundaries. Cases where the signed flag, (msbit of result) is set is the positive (eax) values below 5 and the negative numbers that do not result in a signed overflow (+4 down to -3). All of which are in the <5 category so they want to have a result of 2. The first test looks for cases where sign is set, why it bothers to then test the signed overflow? That makes no sense, we already know all signed results are in the less than 5 category. the extra jump if signed overflow doesnt hurt.
so if you fall through js signon then the sign bit is off which is numbers greater than or equal to 5 (want a result of 1) or results negative enough to cause a signed overflow (want a result of 2). so jo elseblock sorts these two cases out by picking up the result of 2 cases (signed overflow, very negative). and jmp thenblock takes the positive numbers above 5.
It looks to me like you are doing signed math here (somewhat obvious from using the signed overflow flag). Since you are using a 5 to compare against and signed math, you need 4 or more bits in your system to implement this code, so 8, 32, 64, 123456 bits, it doesnt matter it all works the same as a 4 bit system (for this comparision). I find it easier to minimize the number of bits to do the analysis. Hardcoded comparisons like this make it that much easier, as above hand compute results just above, at, and below. then walk through the all zeros (zero) to all ones (minus one) for signed numbers, and very negative into the signed overflow range. for unsigned numbers it is a bit easier but the same process.