The MASM Forum

General => The Laboratory => Topic started by: jj2007 on August 27, 2017, 02:57:20 PM

Title: SDWORD PTR in comparisons
Post by: jj2007 on August 27, 2017, 02:57:20 PM
Note the different encoding. There is apparently no reason to use the long encoding, but both ML and UAsm do it 8)

Code: [Select]
include \masm32\include\masm32rt.inc

.code
start:
  or ebx, -1
  .Repeat
print str$(ebx), " ebx", 13, 10
.if ebx<=sdword ptr 0 ; 81FB 00000000
print "le", 13, 10
.else
print "gt", 13, 10
.endif
.if sdword ptr ebx<=0 ; 83FB 00
print "le", 13, 10
.else
print "gt", 13, 10
.endif
inc  ebx
  .Until ebx>1
  inkey
  exit
end start
Title: Re: SDWORD PTR in comparisons
Post by: habran on August 28, 2017, 08:15:15 AM
Good spot JJ :t
Nobody noticed that because it is logical to do the second version, I myself would do this:

 .if (sdword ptr ebx <= 0)

I'll see if it can be done the same with otherway round
Title: Re: SDWORD PTR in comparisons
Post by: nidud on August 28, 2017, 08:39:06 AM
Good spot JJ :t
Nobody noticed that because it is logical to do the second version, I myself would do this:

 .if (sdword ptr ebx <= 0)

I'll see if it can be done the same with otherway round

The hll definition of if (…) is always signed, so the Asmc implementation is .ifs (…).

Code: [Select]
include stdio.inc

.code

main proc
    or ebx,-1
    .repeat
        printf("%d\n", ebx)
        .ifs ebx <= 0
            printf("le\n")
        .else
            printf("gt\n")
        .endif
        ;.ifs ebx <= 0
        ;    printf("le\n")
        ;.else
        ;    printf("gt\n")
        ;.endif
        inc ebx
    .until ebx > 1
    ret

main endp

    end

Code: [Select]
        cmp     ebx, 0  ; 0013 _ 83. FB, 00
        jg      ?_001   ; 0016 _ 7F, 0F
Title: Re: SDWORD PTR in comparisons
Post by: habran on August 28, 2017, 09:01:35 AM
Here are some variation what is happening:
Code: [Select]
   174: .if (ebx <= 0)
000000000103103d 83 FB 00                         cmp ebx, 0x0 
0000000001031040 77 01                            jnbe 0x1031043 
   175:   nop
0000000001031042 90                               nop 
   176: .endif
   177: .if ebx <= 0
0000000001031043 83 FB 00                         cmp ebx, 0x0 
0000000001031046 77 01                            jnbe 0x1031049 
   178:   nop
0000000001031048 90                               nop 
   179: .endif
   180: .if (sdword ptr ebx <= 0)
0000000001031049 83 FB 00                         cmp ebx, 0x0 
000000000103104c 7F 01                            jnle 0x103104f 
   181:   nop
000000000103104e 90                               nop 
   182: .endif
   183: .if ( ebx <= sdword ptr 0)
000000000103104f 81 FB 00 00 00 00                cmp ebx, 0x0 
0000000001031055 7F 01                            jnle 0x1031058 
   184:   nop
0000000001031057 90                               nop 
   185: .endif
   186:
   187: .if ebx <= sdword ptr 0
0000000001031058 81 FB 00 00 00 00                cmp ebx, 0x0 
000000000103105e 7F 01                            jnle 0x1031061 
   188:   nop
0000000001031060 90                               nop 
   189: .endif
Title: Re: SDWORD PTR in comparisons
Post by: jj2007 on August 28, 2017, 09:07:13 AM
The hll definition of if (…) is always signed

"always" is a big word - there are many hll out there...
Title: Re: SDWORD PTR in comparisons
Post by: habran on August 28, 2017, 09:12:15 AM
You are right JJ, you can see in above examples that it is not the case 8)
Title: Re: SDWORD PTR in comparisons
Post by: nidud on August 28, 2017, 09:57:37 AM
 :biggrin:

Programming is rule-based.

Comparison in HLL is based on the types used in the expression but the base integer types are by default signed so this will default to signed compare:
Code: [Select]
A(void) { return 0; }
B(void) { return 0; }

main(void)
{
if (A() > B())
return 1;
return 0;
}

You are right JJ, you can see in above examples that it is not the case 8)

Long debate:

Quote
There is an attempt to include HLL in MASM, but it is currently not fully implemented. The first problem with the current implementation is that it doesn’t work, and the second problem is that it's not High Level Language.

http://masm32.com/board/index.php?topic=902.0
Title: Re: SDWORD PTR in comparisons
Post by: jj2007 on August 28, 2017, 05:22:43 PM
Programming is rule-based

Absolutely :t But the C/C++ fraction rules only 12% (https://www.tiobe.com/tiobe-index/) of the world of programming. The other 88% are free to define their own rules. They are not even obliged to call their numbers "type" or their procedures "class" 8)


Quote
Long debate:

Quote
There is an attempt to include HLL in MASM, but it is currently not fully implemented. The first problem with the current implementation is that it doesn’t work, and the second problem is that it's not High Level Language.

http://masm32.com/board/index.php?topic=902.0

Very long debate! When I reached the end of that page, I thought "oh no, only page 1 of 17 :dazzled:"
Title: Re: SDWORD PTR in comparisons
Post by: nidud on August 28, 2017, 10:41:55 PM
Programming is rule-based

Absolutely :t But the C/C++ fraction rules only 12% (https://www.tiobe.com/tiobe-index/) of the world of programming. The other 88% are free to define their own rules. They are not even obliged to call their numbers "type" or their procedures "class" 8)

Another integrated part of programming is logic so they are indeed obligated to define the types used in order to compare them correctly.
Code: [Select]
DECLARE FUNCTION foo (A AS INTEGER, B AS INTEGER)

The default type of a number will for this reason be signed.
Code: [Select]
var1    equ 1
var2    equ -1

IF (var1 GT var2)
    ECHO Signed compare
ELSE
    ECHO Unsigned compare
ENDIF
Title: Re: SDWORD PTR in comparisons
Post by: jj2007 on August 29, 2017, 12:09:59 AM
Another integrated part of programming is logic
...
The default type of a number will for this reason be signed

In C/C++ logic, yes. The other 88% of the programming world are absolutely free to define their own logic ;)
Title: Re: SDWORD PTR in comparisons
Post by: nidud on August 29, 2017, 12:22:39 AM
In C/C++ logic, yes. The other 88% of the programming world are absolutely free to define their own logic ;)

 :biggrin:

Logic is the science of reasoning so you need the ability to reason correctly to define it.
Title: Re: SDWORD PTR in comparisons
Post by: hutch-- on August 29, 2017, 01:58:49 AM
 :biggrin:

Therez rools and there's rules but some languages let you make more of your own than someone else's rewelz. By going under conventional high level languages you have more room to make your own rules as you are not restricted by someone else's rules but you must also be able to make it work and be convenient enough to use on a regular basis.

The two ends address different problems, with a high level language that does not have a rule that lets you do what you require, the burden is getting around those rules whereas at a lower level you can make your own rules but have to deal with the complexity of consistency and functionality. Both approaches have their respective virtues and vices.
Title: Re: SDWORD PTR in comparisons
Post by: aw27 on August 29, 2017, 12:25:58 PM
Note the different encoding. There is apparently no reason to use the long encoding, but both ML and UAsm do it

The expressions are not equivalent most of the time. ".if sdword ptr ebx<=0" is translated here to CMP r/m32,imm8 (Compare imm8 with r/m32) the other is translated to CMP r/m32,imm32 (Compare imm32 with r/m32).

Replace "or ebx, -1" (why or here?) with "mov ebx, -2147483647" and you will see they are not.

On the other hand, if you compare with larger values (not byte sized) they will be encoded the same way. For example,
".if sdword ptr ebx<=257" is encoded like "ebx<=sdword ptr 257"

Another point is that the program crashes when assembled with MASM, (I mean MASM from the last 20 years or so, not some museum MASM).

Title: Re: SDWORD PTR in comparisons
Post by: jj2007 on August 29, 2017, 05:44:36 PM
The expressions are not equivalent most of the time. ".if sdword ptr ebx<=0" is translated here to CMP r/m32,imm8 (Compare imm8 with r/m32) the other is translated to CMP r/m32,imm32 (Compare imm32 with r/m32).

Thank you for confirming that different encodings are being used. The number "0" is obviously an imm8, so a clever assembler can choose the shorter imm8 encoding, since the "0" is known at assembly time. This is why I started the thread.

Quote
Replace "or ebx, -1" (why or here?) with "mov ebx, -2147483647" and you will see they are not.

It is highly unlikely that the assembler would change encoding when changing the entry value of ebx, but here is code to test. With all my assemblers, encodings and results are identical. Btw, "or ebx, -1" is the short version of "mov ebx, 0FFFFFFFFh". 
Code: [Select]
include \masm32\include\masm32rt.inc

.code
start:
  or ebx, -1 ; my suggestion
  mov ebx, -2147483647         ; José's suggestion
  push 2 ; 3 iterations
  .Repeat
print str$(ebx), " ebx", 13, 10
; int 3
.if ebx<=sdword ptr 0 ; 81FB 00000000
print "le", 13, 10
.else
print "gt", 13, 10
.endif
; int 3
.if sdword ptr ebx<=0 ; 83FB 00
print "le", 13, 10
.else
print "gt", 13, 10
.endif
inc  ebx
dec dword ptr [esp]
  .Until Sign?
  pop eax
  inkey
  exit
end start

Quote
On the other hand, if you compare with larger values (not byte sized) they will be encoded the same way. For example,
".if sdword ptr ebx<=257" is encoded like "ebx<=sdword ptr 257"

Correct. This is what the thread is all about.

Quote
Another point is that the program crashes when assembled with MASM, (I mean MASM from the last 20 years or so, not some museum MASM).

Not on my assemblers (ML 6.14, 6.15, 8.0, 9.0, 10.0, UAsm & friends). Please post the executable that crashes, and indicate which assembler and OS you were using.
Title: Re: SDWORD PTR in comparisons
Post by: aw27 on August 29, 2017, 06:09:04 PM
It is highly unlikely that the assembler would change encoding when changing the entry value of ebx
It is true, I just thought it would be enough for you to take conclusions.
Look at this case then:

Code: [Select]
include \masm32\include\masm32rt.inc

.code
start:
 
  mov ebx, -2147483647
  .Repeat
print str$(ebx), " ebx", 13, 10
.if ebx<=sdword ptr -1
print "le", 13, 10
.else
print "gt", 13, 10
.endif
.if sdword ptr ebx<=-1
print "le", 13, 10
.else
print "gt", 13, 10
.endif
inc  ebx
  .Until ebx>1
  inkey
  exit
end start

Quote
Not on my assemblers (ML 6.14, 6.15, 8.0, 9.0, 10.0, UAsm & friends). Please post the executable that crashes, and indicate which assembler and OS you were using.
Good rules dictate that developers must always use the latest versions of their tools. That's what I do.
Check with release 14 of MASM then.
Title: Re: SDWORD PTR in comparisons
Post by: jj2007 on August 29, 2017, 06:30:26 PM
Look at this case then:

I looked, and excuse my ignorance: where is the problem?
Code: [Select]
-2147483647 ebx
le
le
-2147483648 ebx
le
le
2147483647 ebx
gt
gt

Quote
Good rules dictate that developers must always use the latest versions of their tools. That's what I do.
Check with release 14 of MASM then.

Whether your rules are good or not, I don't care - they are not my rules (recent versions of MASM are very buggy, but that is no secret, right?).

I asked you to post the exe, and you didn't do that, for good reasons, I suppose 8)
Title: Re: SDWORD PTR in comparisons
Post by: aw27 on August 29, 2017, 06:53:56 PM
I looked, and excuse my ignorance: where is the problem?
You are correct. No problem.  :t

Quote
recent versions of MASM are very buggy, but that is no secret, right?
I am not sure they are more buggy. They simply tightened their tolerance for bad practices.  :lol:

Quote
I asked you to post the exe, and you didn't do that, for good reasons, I suppose 8)
You can assemble with MASM from your Visual Studio Community 2017 or 2015 editions and see for yourself.

Title: Re: SDWORD PTR in comparisons
Post by: jj2007 on August 29, 2017, 07:25:34 PM
You can assemble with MASM from your Visual Studio Community 2017 or 2015 editions and see for yourself.

Thank you so much for your valuable contributions to this thread, José. Unfortunately, right now I am busy with important things, so I won't have time to investigate the secrets of the slowest software I've ever seen. Btw did you ever fix the little bug in your almost correct (http://masm32.com/board/index.php?topic=6417.msg68774#msg68774) conversion routine ("diff" is the difference between the Real4 and the converted Real8, and it should be zero, of course)?
Title: Re: SDWORD PTR in comparisons
Post by: aw27 on August 29, 2017, 07:39:39 PM
Unfortunately, right now I am busy with important things, so I won't have time to investigate the secrets of the slowest software I've ever seen.

Something is wrong with your hardware :badgrin:
It loads in less than 2 seconds in my i5 notebook:
(http://www.atelierweb.com\a\vs2017GIF.gif)

Quote
Btw did you ever fix the little bug
What I remember from that thread is that I fixed your bug and you rushed to make something a little different in order to not recognize that. JJ is JJ  :lol:
Title: Re: SDWORD PTR in comparisons
Post by: jj2007 on August 29, 2017, 07:58:20 PM
Quote
Btw did you ever fix the little bug
What I remember from that thread is that I fixed your bug and you rushed to make something a little different in order to not recognize that. JJ is JJ  :lol:

Your irrelevant remarks ("This looks wrong") and your (still) buggy code could not help me to identify the bug that I fixed minutes later. Anyway, that thread is public, so everybody can see the "conversation" (http://masm32.com/board/index.php?topic=6417.0) :P
Title: Re: SDWORD PTR in comparisons
Post by: aw27 on August 29, 2017, 08:05:03 PM
@JJ
So, you said "Thank you, José - you are right, the mov eax, ecx was redundant. Here is the final version:" and 1 month later it is not anymore? You are one of a kind.  :greenclp:
Title: Re: SDWORD PTR in comparisons
Post by: hutch-- on August 29, 2017, 08:31:41 PM
Jose,

Make me wiser, what does my download page have to do with starting VS ?
Title: Re: SDWORD PTR in comparisons
Post by: aw27 on August 29, 2017, 08:45:49 PM
Jose,

Make me wiser, what does my download page have to do with starting VS ?
Hutch,
We hear JJ complain all the time that VS tools are slow to load. They are indeed very fast. The slowest one I know is VS2015 which will take a few more seconds. Probably, JJ should consider it is time to get a new computer.  ;)
Title: Re: SDWORD PTR in comparisons
Post by: jj2007 on August 29, 2017, 08:55:21 PM
@JJ
So, you said "Thank you, José - you are right, the mov eax, ecx was redundant. Here is the final version:" and 1 month later it is not anymore? You are one of a kind.  :greenclp:

Even one month later, your remark about the mov eax, ecx is still valid, and I thanked you for spotting that. It was indeed redundant, so I removed it - 2 bytes less, thank you so much again. But it had nothing to do with the problem, and it won't change the fact that your buggy code is still waiting to be fixed while my version is working perfectly. Maybe you should consider using less buggy tools (http://masm32.com/board/index.php?topic=6508.0)?

Re slow computers: My Core i5 is faster than the average computer, and definitely fast enough when using my own software. There is a reason why I am hanging around here, in an assembler forum: I like fast software. Not bloated tools like VS Community; a Google search for visual studio community slow yields "About 9,330,000 results" :bgrin:

I will admit, though, that my VS Community would load in "less than 2 seconds" if I used it so often that the whole crap was already in the cache. But I am not a masochist :P
Title: Re: SDWORD PTR in comparisons
Post by: aw27 on August 29, 2017, 09:34:03 PM
But it had nothing to do with the problem, and it won't change the fact that your buggy code is still waiting to be fixed while my version is working perfectly.[/url]?
I don't think it is buggy. I remember there was indeed a bug the first time I posted but I fixed it sometime later. I am too lazy to go again through waters passed under the bridge.

Quote
Re slow computers: My Core i5 is faster than the average computer,
:badgrin:

Quote
a Google search for visual studio community slow yields "About 9,330,000 results" :bgrin:
I tried "who is JJ" in Google and got 26 400 000 results.  :badgrin:

Quote
I will admit, though, that my VS Community would load in "less than 2 seconds" if I used it so often that the whole crap was already in the cache. But I am not a masochist :P
Actually not, I only use the notebook when go out for the weekend and have probably loaded VS2017 3 or 4 times.
Title: Re: SDWORD PTR in comparisons
Post by: jj2007 on August 29, 2017, 10:16:16 PM
I don't think it is buggy. I remember there was indeed a bug the first time I posted but I fixed it sometime later.

The code you posted here (http://masm32.com/board/index.php?topic=6417.msg68773#msg68773) has indeed a fat bug, and you never fixed it. Your original code is contained in the archive attached to Reply #5*)  and produces wrong results:
Code: [Select]
-- R4ToR8 jj --
R4: -123456.789      R8: -123456.789       diff: 0.0   ; zero is correct
R4: -111111.789      R8: -111111.789       diff: 0.0
...
R4: 37028.2109       R8: 37028.2109        diff: 0.0
R4: 49373.2109       R8: 49373.2109        diff: 0.0
-- R4ToR8 aw27 --
R4: -123456.789      R8: -123456.781       diff: 0.0078   ; non-zero is WRONG
R4: -111111.789      R8: -111111.781       diff: 0.0078
R4: -98766.7891      R8: -98766.7812       diff: 0.0078
R4: -86421.7891      R8: -86421.7812       diff: 0.0078
R4: -74076.7891      R8: -74076.7812       diff: 0.0078
R4: -61731.7891      R8: -61731.7812       diff: 0.0078
R4: -49386.7891      R8: -49386.7812       diff: 0.0078
R4: -37041.7891      R8: -37041.7812       diff: 0.0078
R4: -24696.7891      R8: -24696.7812       diff: 0.0078
R4: -12351.7891      R8: -12351.7891       diff: 0.0
R4: -6.78906250      R8: -6.78906250       diff: 0.0
R4: 12338.2109       R8: 12338.2109        diff: 0.0
R4: 24683.2109       R8: 24683.2031        diff: -0.0078
R4: 37028.2109       R8: 37028.1875        diff: -0.023
R4: 49373.2109       R8: 49373.1875        diff: -0.023

*) Since you will surely complain that ConvertFloats.asc "does not open": Use Wordpad to see the content.
Title: Re: SDWORD PTR in comparisons
Post by: aw27 on August 29, 2017, 11:10:20 PM
@JJ
You are using a case I barely remember, and that did not even came on the way in this thread, to compensate for dozens of situations I made you swallow your anger.
Pure revenge  :badgrin: .
Looking forward for more rabbits to come out of your hat.
Title: Re: SDWORD PTR in comparisons
Post by: hutch-- on August 29, 2017, 11:23:28 PM
Every time I have ever installed VS over the last few years, loading the IDE is a genuine pain and the Haswell I am using is no slouch. The last i7 was a reasonably fast machine and it was slow on it as well. After I install VS, I grab all of the files I want then delete it so it does not try and hog file extensions.
Title: Re: SDWORD PTR in comparisons
Post by: aw27 on August 29, 2017, 11:44:24 PM
Every time I have ever installed VS over the last few years, loading the IDE is a genuine pain and the Haswell I am using is no slouch. The last i7 was a reasonably fast machine and it was slow on it as well. After I install VS, I grab all of the files I want then delete it so it does not try and hog file extensions.
I have a 500 GB SSD which serves as drive C, where is installed VS. This explains most of the speed.
Title: Re: SDWORD PTR in comparisons
Post by: jj2007 on August 29, 2017, 11:53:35 PM
dozens of situations I made you swallow your anger.

My dear friend, why should I be angry about you? It's fun to argue with you :badgrin:
Title: Re: SDWORD PTR in comparisons
Post by: aw27 on August 30, 2017, 12:09:25 AM
It's fun to argue with you :badgrin:
I think the same, it is fun to argue with you!  :lol:
Title: Re: SDWORD PTR in comparisons
Post by: hutch-- on August 30, 2017, 12:46:58 AM
 :biggrin:

Just remember that if you scratch each other's eyes out you code quality will drop dramatically.  :P
Title: Re: SDWORD PTR in comparisons
Post by: aw27 on August 30, 2017, 02:02:21 AM
:biggrin:
Just remember that if you scratch each other's eyes out you code quality will drop dramatically.  :P

In the end JJ gave me the opportunity to fix the small typo (he calls it a fat bug) in the code I produced one month ago to fix the fat bugs in his own code.  :lol:
Title: Re: SDWORD PTR in comparisons
Post by: hutch-- on August 30, 2017, 02:31:02 AM
 :biggrin:

Well, you could get yourself a braille keyboard.  :P
Title: Re: SDWORD PTR in comparisons
Post by: jj2007 on August 30, 2017, 03:34:37 AM
In the end JJ gave me the opportunity to fix the small typo

Thread is already updated. Your code is even a tick faster now, and one byte shorter than mine :t
Title: Re: SDWORD PTR in comparisons
Post by: aw27 on August 30, 2017, 04:26:31 AM
In the end JJ gave me the opportunity to fix the small typo

Thread is already updated. Your code is even a tick faster now, and one byte shorter than mine :t
:t
Title: Re: SDWORD PTR in comparisons
Post by: felipe on August 30, 2017, 11:14:09 AM
Phuk! you really inspire me guys.  :biggrin:

Another thumb up for this great forum  :icon14:

 :greenclp:

 :lol: