Let's say input==3
mov eax,input
mov eax,-4 ;eax==0xFFFFFFFF
Go_on: cmp eax,ebx
jae ;other procedure
inc bx
jmp Go_on
.....
.....
.....
Why does this FAIL ?
Does it take too much time-slice
from the cpu ?
mov eax,input
mov eax,-4 ;eax==0xFFFFFFFF
Go_on: cmp eax,ebx
jae ;other procedure
inc bx
jmp Go_on
.....
.....
.....
Why does this FAIL ?
Does it take too much time-slice
from the cpu ?
What's ebx?
You've got two "mov eax,(BLAH)" though...
Assuming that either of them are ebx, you will never succeed in the comparison though, because you only increment the bottom half of ebx.
e*x = 3
e#x = 0xFFFF FFFC
inc *x = 0xFFFF <- eventually
e*x = 0x0000FFFF so will fail the comparison
next itteration,
inc *x = 0x0000
e*x = 0x00000000
or:
inc #x = 0x0000
e#x = 0xFFFF 0000
so will fail the comparison
Solutions:
#1 Even the size of the operands
#2 Use movsx
Mirno
You've got two "mov eax,(BLAH)" though...
Assuming that either of them are ebx, you will never succeed in the comparison though, because you only increment the bottom half of ebx.
e*x = 3
e#x = 0xFFFF FFFC
inc *x = 0xFFFF <- eventually
e*x = 0x0000FFFF so will fail the comparison
next itteration,
inc *x = 0x0000
e*x = 0x00000000
or:
inc #x = 0x0000
e#x = 0xFFFF 0000
so will fail the comparison
Solutions:
#1 Even the size of the operands
#2 Use movsx
Mirno
Hi Mirno,
I typed wrong.... of cause it's EBX !
Let's say input==3
mov eax,input
mov eax,-4 ;eax==0xFFFFFFFF
Go_on: cmp eax,ebx
jae ;other procedure
inc ebx
jmp Go_on
.....
.....
.....
Why does this FAIL ?
Does it take too much time-slice
from the cpu ?
I can of cause make a check, so that
one can't type less than FOUR letters,
that will solve the problem, I just wonder
why it didn't work with THREE letters.
I typed wrong.... of cause it's EBX !
Let's say input==3
mov eax,input
mov eax,-4 ;eax==0xFFFFFFFF
Go_on: cmp eax,ebx
jae ;other procedure
inc ebx
jmp Go_on
.....
.....
.....
Why does this FAIL ?
Does it take too much time-slice
from the cpu ?
I can of cause make a check, so that
one can't type less than FOUR letters,
that will solve the problem, I just wonder
why it didn't work with THREE letters.
You don't assign ebx a value, what is that value? You assign eax twice though...
It should eventually always pass, it may just take quite some time...
JAE is taken if the carry flag = 0.
3 - (-4) = 7 but will set the carry flag...
4 - (-4) = 8 but will set the carry flag...
This will continue until ebx topples and becomes negative itself (-3 or below).
Mirno
It should eventually always pass, it may just take quite some time...
JAE is taken if the carry flag = 0.
3 - (-4) = 7 but will set the carry flag...
4 - (-4) = 8 but will set the carry flag...
This will continue until ebx topples and becomes negative itself (-3 or below).
Mirno
I'm obviously typing/thinking too quickly.....
EBX is just acting like a counter, and is just incremented from zero to ? (input length)
And I was typing "mov", when it should be "ADD", sorry for mixing it all....
So here is what it should have looked like:
Let's say input==3
I think that should be it....
Ps. I HAVE been typing it all very nicely placed, but when I post it
the spaces disappear, and it looks terrible.....hmmm
Now it works, added [ code ] tags :) - bazik
EBX is just acting like a counter, and is just incremented from zero to ? (input length)
And I was typing "mov", when it should be "ADD", sorry for mixing it all....
So here is what it should have looked like:
Let's say input==3
mov eax,input
add eax,-4 ;eax==0xFFFFFFFF
Go_on: cmp eax,ebx ;EBX==0, and is just incremented. (maybe should have used ECX)
jae Some Proc. ;other procedure
inc ebx
jmp Go_on
I think that should be it....
Ps. I HAVE been typing it all very nicely placed, but when I post it
the spaces disappear, and it looks terrible.....hmmm
Now it works, added [ code ] tags :) - bazik
Use the [ code ] (and it's end [ / code ]) tags, just cut of the spaces between the "[", "]" and "/"
1 space
2 spaces
L o t ' s o f s p a c e s . :)
Maybe your proc "Someproc" is useing ebx. So, try to push ebx before the call to "Someproc" and pop ebx after the call.
Let's say input==3
; make sure EBX has the correct value here
mov eax,input
add eax,-4 ;eax==0xFFFFFFFF
Go_on: cmp eax,ebx ;EBX==0, and is just incremented.
; (maybe should have used ECX)
jae Some Proc. ;other procedure
; if you have code here, make sure that EAX and EBX
; are not altered, or are being preserved
inc ebx
jmp Go_on
I see the problem now!
Input = 3
eax = input ; eax = 3
eax = eax - 4 ; eax = -1 = 0xFFFFFFFF
Comparison is a subtraction which sets the flags, but does not store the result.
JAE is jump if carry is set.
What can you subtract from 0xFFFFFFFF and set the carry flag?
Answer: NO 32 BIT VALUE CAN SET THE CARRY FLAG IN THIS CASE!
I think the Jxx instructions treat their values as unsigned, it works for signed in most cases, but this is a corner case where it does not.
Mirno
Input = 3
eax = input ; eax = 3
eax = eax - 4 ; eax = -1 = 0xFFFFFFFF
Comparison is a subtraction which sets the flags, but does not store the result.
JAE is jump if carry is set.
What can you subtract from 0xFFFFFFFF and set the carry flag?
Answer: NO 32 BIT VALUE CAN SET THE CARRY FLAG IN THIS CASE!
I think the Jxx instructions treat their values as unsigned, it works for signed in most cases, but this is a corner case where it does not.
Mirno
Try jge instead of jae.
By the way, I do not get the add eax,-4
Why don't you just use sub eax,4?
By the way, I do not get the add eax,-4
Why don't you just use sub eax,4?
JB = JC, (jump on carry set) at least according to DEBUG.
If EAX = 0xFFFF FFFF then
cmp EAX,EBX
jae JumpOut
will always jump out because JAE will interpret the condition code flags for unsigned comparison. 0xFFFF FFFF is Above or Equal to all other unsigned values.
If EAX = 0xFFFF FFFF then
cmp EAX,EBX
jae JumpOut
will always jump out because JAE will interpret the condition code flags for unsigned comparison. 0xFFFF FFFF is Above or Equal to all other unsigned values.
Thanks Mirno,
You're right, one can't make CF set, when the result is
already a SIGNED INTEGER !
Thanks scientica
I didn't knew that !
Hi roticv !
I could have done that as well !
Hi tenkey
If I understand you correct, then if we say:
eax==FFFFFFFF
ebx==00000001
then if: cmp eax,ebx
you mean to say that CF is set, because of the SIGNED value in eax ?
But when I test that in DEBUG, the CF isn't set. So......
:) :) :) :)
You're right, one can't make CF set, when the result is
already a SIGNED INTEGER !
Thanks scientica
I didn't knew that !
Hi roticv !
I could have done that as well !
Hi tenkey
If I understand you correct, then if we say:
eax==FFFFFFFF
ebx==00000001
then if: cmp eax,ebx
you mean to say that CF is set, because of the SIGNED value in eax ?
But when I test that in DEBUG, the CF isn't set. So......
:) :) :) :)
You're welcome. :)
Let me think, cmp it does this: and updates the flags (setting bits that should be set is set), but it doesn't save the result.
Let me think, cmp it does this: and updates the flags (setting bits that should be set is set), but it doesn't save the result.
There are two overflow flags, CF and OF, a sign flag, SF, and a zero flag, ZF.
FFFF FFFF - 0000 0001 = FFFF FFFE, no borrow (CF = 0), no overflow (OF = 0), sign is minus (SF = 1).
JAE (aka JNB or JNC) jumps if CF = 0.
JGE jumps if SF = OF.
CF can be set:
0000 0000 - 0000 0001 = FFFF FFFF, borrow (CF = 1), no overflow (OF = 0), sign is minus (SF = 1).
The CMP does not know if the compare is signed or unsigned. It simply sets the flags for both cases.
To illustrate borrow, we show 8-bit binary subtraction with extended unsigned precision:
FFFF FFFF - 0000 0001 = FFFF FFFE, no borrow (CF = 0), no overflow (OF = 0), sign is minus (SF = 1).
JAE (aka JNB or JNC) jumps if CF = 0.
JGE jumps if SF = OF.
CF can be set:
0000 0000 - 0000 0001 = FFFF FFFF, borrow (CF = 1), no overflow (OF = 0), sign is minus (SF = 1).
The CMP does not know if the compare is signed or unsigned. It simply sets the flags for both cases.
To illustrate borrow, we show 8-bit binary subtraction with extended unsigned precision:
0 1111 1111
- 0 0000 0001
-------------
0 1111 1110
0 0000 0000
- 0 0000 0001
-------------
1 1111 1111
The extra 1 bit is the unsigned overflow, or borrow.
1 1111 1111
- 0 0000 0001
-------------
1 1111 1110
1 1000 0000
- 0 0000 0001
-------------
1 0111 1111
In both cases, the result's true sign is minus. But if we truncate the second result to 8-bits,
the result will be erroneously recorded as positive - a signed overflow.
Al right tenkey, you know your stuff :alright:
It's a good thing, to straighten the math out like that :alright:
Thanks man :alright: :alright: :alright:
It's a good thing, to straighten the math out like that :alright:
Thanks man :alright: :alright: :alright: