#241 insufficient type compare

[qWord]

Hello,

jWasm's type checking is not compatible with MASM:

;----- example ----
FOO1 typedef ptr DWORD
FOO2 typedef ptr SDWORD

IF (type FOO1) EQ (type FOO2)
echo FOO1 EQ FOO2
ELSE
echo FOO1 NE FOO2
ENDIF

FOO3 typedef ptr FOO1
FOO4 typedef ptr FOO2

IF (type FOO3) EQ (type FOO4)
echo FOO3 EQ FOO4
ELSE
echo FOO3 NE FOO4
ENDIF

echo

S1 struct
x DWORD ?
y DWORD ?
S1 ends

S2 struct
x SDWORD ?
y SDWORD ?
S2 ends

; same as S1
S3 struct
x DWORD ?
y DWORD ?
S3 ends

IF (type S1) EQ (type S2)
echo S1 EQ S2
ELSE
echo S1 NE S2
ENDIF

IF (type S1) EQ (type S3)
echo S1 EQ S3
ELSE
echo S1 NE S3
ENDIF

echo

PS1 typedef ptr S1
PS2 typedef ptr S2
PS3 typedef ptr S3

IF (type PS1) EQ (type PS2)
echo PS1 EQ PS2
ELSE
echo PS1 NE PS2
ENDIF

IF (type PS1) EQ (type PS3)
echo PS1 EQ PS3
ELSE
echo PS1 NE PS3
ENDIF
echo
;----- end example ----

The above code produce the following output with MASM (v6-11):

FOO1 NE FOO2
FOO3 NE FOO4

S1 NE S2
S1 NE S3

PS1 NE PS2
PS1 NE PS3

jWasm's (v2.10pre) result:
FOO1 EQ FOO2
FOO3 EQ FOO4

S1 EQ S2
S1 EQ S3

PS1 EQ PS2
PS1 EQ PS3

Seems like that MASM makes a deep analyses of the types, whereas jWasm is happy if the size match or we have pairs like ptr/ptr.

regards, qWord

[japheth]

Confirmed. Will be fixed in v2.10

( should be fixed in current pre v2.10 ).

[qWord]

Hello,
I've found further problems and made a test which marks the difference between jWasm (v2.10rc8, Mar 23 2013) and MASM.
One problem seems to be with local variables and pointer types (case 1, 12, 20, 28). Also there is a problems for dereferencing (case 6, 23, 25, 27, 31, 33, 35) and typecasting (case 5, 14, 22, 30, 36, 37).

;-------------- example begin ------------------
.686
.model flat, stdcall
option casemap :none

typeCmp macro num:req,expr:req,_type:req
IF (type (&expr)) EQ (type (&_type))
echo [#&num]: TRUE ;typeof (&expr) is &_type
ELSE
echo [#&num]: FALSE ;typeof (&expr) is not &_type
ENDIF
endm

S1 struct
x DWORD ?
S1 ends
PS1 typedef ptr S1
PPS1 typedef ptr PS1

FOO typedef DWORD
PFOO typedef ptr FOO
PPFOO typedef ptr PFOO

.data?
g_pS1 PS1 ?
g_ppS1 PPS1 ?
g_s1 S1 <>

g_pfoo PFOO ?
g_ppfoo PPFOO ?
.code
main proc
LOCAL l_pS1:PS1
LOCAL l_ppS1:PPS1
LOCAL l_s1:S1
LOCAL l_pfoo:PFOO
LOCAL l_ppfoo:PPFOO

typeCmp 01, l_pS1,PS1 ; <-- wrong for jWasm
typeCmp 02, l_s1,S1

typeCmp 03, g_pS1,PS1
typeCmp 04, g_s1,S1

typeCmp 05, PS1 ptr esi,PS1 ; <-- wrong for jWasm
typeCmp 06, [PS1 ptr esi],S1 ; <-- wrong for jWasm
typeCmp 07, S1 ptr [esi],S1

assume esi: ptr S1
typeCmp 08, esi,PS1
typeCmp 09, [esi],S1

assume esi: PS1
typeCmp 10, esi,PS1
typeCmp 11, [esi],S1

assume esi: nothing
typeCmp 12, l_pfoo,PFOO ; <-- wrong for jWasm
typeCmp 13, g_pfoo,PFOO

typeCmp 14, PFOO ptr esi,PFOO ; <-- wrong for jWasm
typeCmp 15, [PFOO ptr esi],FOO

assume esi: ptr FOO
typeCmp 16, esi,PFOO
typeCmp 17, [esi],FOO

assume esi: PFOO
typeCmp 18, esi,PFOO
typeCmp 19, [esi],FOO

assume esi: nothing
;/* ptr ptr types */
typeCmp 20,l_ppS1,PPS1 ; <-- wrong for jWasm
typeCmp 21,g_ppS1,PPS1

typeCmp 22,PPS1 ptr esi,PPS1 ; <-- wrong for jWasm
typeCmp 23,[PPS1 ptr esi],PS1 ; <-- wrong for jWasm

assume esi: ptr PS1
typeCmp 24,esi,PPS1
typeCmp 25,[esi],PS1 ; <-- wrong for jWasm

assume esi: PPS1
typeCmp 26,esi,PPS1
typeCmp 27,[esi],PS1 ; <-- wrong for jWasm

assume esi: nothing
typeCmp 28,l_ppfoo,PPFOO ; <-- wrong for jWasm
typeCmp 29,g_ppfoo,PPFOO

typeCmp 30,PPFOO ptr esi,PPFOO ; <-- wrong for jWasm
typeCmp 31,[PPFOO ptr esi],PFOO ; <-- wrong for jWasm

assume esi: ptr PFOO
typeCmp 32,esi,PPFOO
typeCmp 33,[esi],PFOO ; <-- wrong for jWasm

assume esi: PPFOO
typeCmp 34,esi,PPFOO
typeCmp 35,[esi],PFOO ; <-- wrong for jWasm

typeCmp 36,PFOO ptr g_pS1,PFOO ; <-- wrong for jWasm
typeCmp 37,PFOO ptr l_pS1,PFOO ; <-- wrong for jWasm

ret
main endp
end main
;-------------- example end ------------------
(MASM returns TRUE for all cases)

I hope I'm not too annoying with that stuff ;-D

regards, qWord

[japheth]

> I hope I'm not too annoying with that stuff ;-D

No - you're reports are always welcome, of course. :)

However, this addition is a bit "unfortunate" because:

1. the bug report has been attached to a group already ( that means: it's marked as "fixed" )

2. the cases in the report happily mix "normal" type issues and "dereference" type issues. This is a small problem because I somehow tend to delay the fix of the latter ones ( after all, no one except you knows that this feature exists at all ).

[jj2007]

Another example for the type comparison problem. Assembles correctly with various ML versions.

include \masm32\include\masm32rt.inc

MyStruct STRUCT
  msBytes   db 100, 200
MyStruct   ENDS

.code
ms MyStruct <>
start:
   mov ecx, 1
   movzx eax, ms.msBytes[ecx]
   print str$(eax), 9

   if (type ms.msBytes[ecx]) eq BYTE
      inkey "a byte", 13, 10
   else
      inkey "NOT a byte", 13, 10
   endif
   exit
end start

[japheth]

Assembles correctly with various ML versions.

I'm getting assembly errors with both masm and jwasm - there's a <> missing after "ms MyStruct".

After adding the <>, both assemblers will accept the source without error.

I guess what you wanted to say is that the final binary will display "a byte" if it was assembled with Masm and "NOT a byte" if assembled with JWasm?

[jj2007]

there's a <> missing after "ms MyStruct".

Sorry, I pasted the brackets but apparently SF doesn't like them inside pre tags.