SDWORD PTR in comparisons

[jj2007]

Note the different encoding. There is apparently no reason to use the long encoding, but both ML and UAsm do it 8)

Code Select Expand

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

[habran]

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

[nidud]

deleted

[habran]

Here are some variation what is happening:

Code Select Expand


   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


[jj2007]

The hll definition of if (...) is always signed

"always" is a big word - there are many hll out there...

[habran]

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

[nidud]

deleted

[jj2007]

Programming is rule-based

Absolutely :t But the C/C++ fraction rules only 12% 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)

Long debate:

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 "

[nidud]

deleted

[jj2007]

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 ;)

[nidud]

deleted

[hutch--]

 

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.

[aw27]

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).

[jj2007]

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.

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 Expand

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

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.

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.

[aw27]

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 Expand


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


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.