News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Comparing 128-bit numbers aka OWORDs

Started by jj2007, August 12, 2013, 08:25:24 PM

Previous topic - Next topic

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

Quote from: jj2007 on August 14, 2013, 09:20:21 AM
Or did you do unsigned comparisons??

No, I just made the usual CMP "emulator" for 128 bits :biggrin: 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

Quote from: jj2007 on August 14, 2013, 09:20:21 AM
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

Quote from: jj2007 on August 14, 2013, 09:27:56 AM
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

Quote from: jj2007 on August 14, 2013, 09:27:56 AM
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

Quote from: Antariy on August 14, 2013, 09:32:10 AM
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

Quote from: jj2007 on August 14, 2013, 09:52:32 AM
Quote from: Antariy on August 14, 2013, 09:32:10 AM
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:

Quote from: jj2007 on August 14, 2013, 09:52:32 AM
> check the number oBig definition
Will do so, thanxalot, Alex :icon14:

I've completely entangled in the source already :greensml:

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

Quote from: jj2007 on August 14, 2013, 10:03:02 AM
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

Quote from: Antariy on August 14, 2013, 10:13:29 AM"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" :biggrin:) 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.