Author Topic: SDWORD PTR in comparisons  (Read 610 times)

jj2007

  • Member
  • *****
  • Posts: 7558
  • Assembler is fun ;-)
    • MasmBasic
SDWORD PTR in comparisons
« 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

habran

  • Member
  • *****
  • Posts: 1107
    • uasm
Re: SDWORD PTR in comparisons
« Reply #1 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
Cod-Father

nidud

  • Member
  • *****
  • Posts: 1371
    • https://github.com/nidud/asmc
Re: SDWORD PTR in comparisons
« Reply #2 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

habran

  • Member
  • *****
  • Posts: 1107
    • uasm
Re: SDWORD PTR in comparisons
« Reply #3 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
Cod-Father

jj2007

  • Member
  • *****
  • Posts: 7558
  • Assembler is fun ;-)
    • MasmBasic
Re: SDWORD PTR in comparisons
« Reply #4 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...

habran

  • Member
  • *****
  • Posts: 1107
    • uasm
Re: SDWORD PTR in comparisons
« Reply #5 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)
Cod-Father

nidud

  • Member
  • *****
  • Posts: 1371
    • https://github.com/nidud/asmc
Re: SDWORD PTR in comparisons
« Reply #6 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

jj2007

  • Member
  • *****
  • Posts: 7558
  • Assembler is fun ;-)
    • MasmBasic
Re: SDWORD PTR in comparisons
« Reply #7 on: August 28, 2017, 05:22:43 PM »
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)


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:"

nidud

  • Member
  • *****
  • Posts: 1371
    • https://github.com/nidud/asmc
Re: SDWORD PTR in comparisons
« Reply #8 on: August 28, 2017, 10:41:55 PM »
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)

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

jj2007

  • Member
  • *****
  • Posts: 7558
  • Assembler is fun ;-)
    • MasmBasic
Re: SDWORD PTR in comparisons
« Reply #9 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 ;)

nidud

  • Member
  • *****
  • Posts: 1371
    • https://github.com/nidud/asmc
Re: SDWORD PTR in comparisons
« Reply #10 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.

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 4813
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: SDWORD PTR in comparisons
« Reply #11 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.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin:

aw27

  • Member
  • ****
  • Posts: 709
Re: SDWORD PTR in comparisons
« Reply #12 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).

« Last Edit: August 29, 2017, 04:31:12 PM by aw27 »

jj2007

  • Member
  • *****
  • Posts: 7558
  • Assembler is fun ;-)
    • MasmBasic
Re: SDWORD PTR in comparisons
« Reply #13 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.

aw27

  • Member
  • ****
  • Posts: 709
Re: SDWORD PTR in comparisons
« Reply #14 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.