Comparing 128-bit numbers aka OWORDs

[Antariy]

Jochen, can you make an example of a number which fails with it?

[jj2007]

Hi Alex,
Search cmp128.asc for if Alex to see the source of this output (N means negative OWORD):

---------- ALEX ----------
positive (lesser, greater)
oSmall  smaller oBig
oBig    bigger  oSmall

negative (lesser, greater)
oSmallN smaller oBigN
oBigN   bigger  oSmallN

pos, neg (greater, greater)
oSmall  smaller oBigN
oBig    smaller oSmallN

neg, pos (lesser, lesser)
oSmallN bigger  oBig
oBigN   bigger  oSmall

pos, neg (equal, equal)
oMedium EQUALS  oMedium
oSmallN EQUALS  oSmallN

Or did you do unsigned comparisons??

P.S.: Ocmp works currently only for JWasm and recent ML.exe, not for ML 6.15 :(

[Antariy]

Jochen, I'm sure it is correct. Maybe the problems is in that you're using BSF to find non-matching element, but you should use BSR - because you want to find the highest order non-matching element. So, if you're comparing results of my code and your code, and decide results of your code as right, then this maybe a reason for not correctness of my macro.

Try your macro with this numbers, for an instance: 80000000800000000000000000000100 and 80000000000000000000000000000300.

[Antariy]

Or did you do unsigned comparisons??

No, I just made the usual CMP "emulator" for 128 bits It behaves just the same as CMP does - i.e. it works for signed and unsigned numbers, with no different, the "signed-ness" of the number controls via usual Jcc instuctions (JG/JA/JL/JB).

[jj2007]

Alex, thanks, will check tomorrow (too tired now, it's 1:30 AM).

But oSmallN bigger oBig looks wrong for signed comparisons - a negative number is always lower than a positive one, right?

[Antariy]

P.S.: Ocmp works currently only for JWasm and recent ML.exe, not for ML 6.15 :(

Yes, I used ML10 to build, but previous, smaller testbed was buildable with ML10 only, too - strange, ML6.15 gives internal assembler error.

[Antariy]

Alex, thanks, will check tomorrow (too tired now, it's 1:30 AM).

But oSmallN bigger oBig looks wrong for signed comparisons - a negative number is always lower than a positive one, right?

oSmallN? I see oSmallF in the source only? Can you drop the numbers?

[Antariy]

Alex, thanks, will check tomorrow (too tired now, it's 1:30 AM).

But oSmallN bigger oBig looks wrong for signed comparisons - a negative number is always lower than a positive one, right?

Jochen, check the number oBig definition for non-ML6.15, you've defined it as a negative (too much zeroes, probably) :t

Again, I checked the code very carefully, it shoud not be wrong.

[jj2007]

oSmallN? I see oSmallF in the source only? Can you drop the numbers?

They are in the testbed, cmp128.asc (not the *timings.asm).

oSmallN   OWORD 88000000000000000000000000000001h
oBigN   OWORD 88000000000000000000000000000003h

And you were absolutely right about bsr instead of bsf :t

> check the number oBig definition
Will do so, thanxalot, Alex :icon14:
New version of the testbed attached. There is still the problem with your negative numbers.

[Antariy]

Also make sure how do you check results, my code does it just like CMP:

CMP First128BitNumber,Second128BitNumber
JZ -> if first equal to second
JA/JG -> unsigned/signed jump if first is above/greater than second
JB/JL -> -/- - - - - below/less - -

[jj2007]

See if showresults - for technical reasons (cmc), I use Carry? and Zero?, should be sufficient for signed comparisons.

[Antariy]

oSmallN? I see oSmallF in the source only? Can you drop the numbers?

They are in the testbed, cmp128.asc (not the *timings.asm).

Thanks, found it after some time :redface:

> check the number oBig definition
Will do so, thanxalot, Alex :icon14:

I've completely entangled in the source already

oSmallN   OWORD 88000000000000000000000000000001h
oMedN   OWORD 88000000000000000000000000000002h
oBigN   OWORD 88000000000000000000000000000003h

"Big negative number" - what did you mean? "Big" - how? This definition oBigN is greater than oSmallN, like -1 greater than -2.

[Antariy]

See if showresults - for technical reasons (cmc), I use Carry? and Zero?, should be sufficient for signed comparisons.

But my code sets all flags just like CMP does, so, to check its correctness you should use a standard technique with JA/JB for unsigned numbers, and JG/JL for signed.

[jj2007]

"Big negative number" - what did you mean? "Big" - how? This definition oBigN is greater than oSmallN, like -1 greater than -2.

Here are the corresponding qwords, which Str$() can handle:

qSmallPos=      8574853690513424385
qBigPos=        8574853690513424387

positive (lesser, greater)
qSmall lesser qBig
qBig greater qSmall


qSmallNeg=     -8646911284551352319
qBigNeg=       -8646911284551352317

negative (lesser, greater)
qSmallN lesser qBigN
qBigN greater qSmallN

OWORDs should behave identically. As you may have seen already, I use MbcmpO to decide which size to handle.

[Antariy]

Yes, I meant this - oBigN is greater ("bigger" ) than oSmallN.

But, still, to check my code you need to use appropriate Jcc instructions, because it follows the standard CPU manner in flags setting. I checked it before posting with different kinds of numbers - it works.