Advantages and Disadvantages of Using HJWasm

[habran]

I made this new topic because hutch-- got bored with the last one ;)
Anyway, when we are already on this topic:

DISADVANTAGES: NONE OUT OF 100%
ADVANTAGES      :THE REST

I fixed the bug with special registers which was hiding in parser.c line 2079

Try to find another one, that one was to easy

[jj2007]

DISADVANTAGES: NONE OUT OF 100%...
Try to find another one, that one was to easy

DISADVANTAGES: NOT COMPATIBLE WITH MASM

jj2007,

Code Select Expand

opax -DWORD PTR[rbx]; << << assembles fine with MASM
It shouldn't because it is wrong
JWasm  see that '-' as error because it does better job than MASM
If you were an assembler and come to such a statement wouldn't you complain ;)
I know for sure that you would screem

Code Select Expand

include \masm32\include\masm32rt.inc

opax macro arg
Local oa, tmp$
  oa = opattr arg
  tmp$ CATSTR <TheArg=>, <arg>, < with opattr=>, %oa
  % echo tmp$
; TheArg="a string" with opattr=36 ; HJWasm64
; TheArg="a string" with opattr=36 ; ML 10.0
ENDM

.code
start:
opax "a string" ; <<<<<<<<< 0 with ML, 36 with HJWasm
opax DWORD PTR [ebx]
opax -DWORD PTR [ebx]    ; <<<< assembles fine with MASM
print "ok"
  exit

end start
;)

[habran]

If this is all you have to throw on HJWasm I am glad that this part is not compatible 8)
Why would anybody write -DWORD PTR [ebx] unless under global influence of alcohol or some worse drug?
I can assure you that I would be able to make it work in HJWasm but I am not gonna do it
If you remember scene from "Groundhog Day" when Phil says to Ned: "I would love to have a coffee with you but I am not gonna do it"

[jj2007]

Why would anybody write -DWORD PTR [ebx]

Because you can do it with the Microsoft macro assembler (MASM) 8)

(and I do actually have a meaningful use for that one...)

I understand that you are tired, but have a look at the wrong opattr for "a string", though, which HJWasm flags as "immediate", while ML gives a zero, meaning "undefined". That might really break some non-JJ code 8)

[johnsa]

If this is all you have to throw on HJWasm I am glad that this part is not compatible 8)
Why would anybody write -DWORD PTR [ebx] unless under global influence of alcohol or some worse drug?
I can assure you that I would be able to make it work in HJWasm but I am not gonna do it
If you remember scene from "Groundhog Day" when Phil says to Ned: "I would love to have a coffee with you but I am not gonna do it"

What is the expected outcome of -dword ptr [ebx] ? (what do you use it for?) not being nosey.. just curious as i've never encountered it before :)

[dedndave]

Code Select Expand

mov dword ptr [ebx],0

this code is ambiguous - you don't know whether the operand is byte, word, or dword sized

Code Select Expand

mov [ebx],0

[johnsa]

Code Select Expand

mov dword ptr [ebx],0

this code is ambiguous - you don't know whether the operand is byte, word, or dword sized

Code Select Expand

mov [ebx],0

i know why you'd use a dword ptr with an immediate or type override obviously.
i mean, what is the purpose of the unary minus..

mov -dword ptr [ebx],0
mov eax,-dword ptr [ebx]

etc?

[hutch--]

 

> got bored with the last one

Nah, I was having trouble with the page depth.

[jj2007]

what is the purpose of the unary minus..

The concrete case here is a macro:
   GuiWarp ccurve, ul warpX:warpY, ur -warpX:warpY, ll -warpX:-warpY, lr warpX:-warpY

ccurve is a Gdi+ graphics object (a "closed curve" in this case), ul means upper left, ur upper right etc, and warpX and warpY are, well, parameters for the warp function.

You can see it in action with the attachment: use arrow left/right/up/down to see the fungus changing its shape (right-click to let it "float").

Here, warpX and warpY are variables defined via SetGlobals, i.e. [ebx+someoffset].

The one-liner above looks like this under the hood:

Code Select Expand

0108371D           ³.  8B43 99           mov eax, [ebx-67]
01083720           ³.  8B53 9D           mov edx, [ebx-63]
01083723           ³.  F7DA              neg edx
01083725           ³.  C1E2 10           shl edx, 10
01083728           ³.  66:0BD0           or dx, ax
0108372B           ³.  52                push edx                 ; Úarglr
0108372C           ³.  8B43 99           mov eax, [ebx-67]        ; ³
0108372F           ³.  F7D8              neg eax                  ; ³
01083731           ³.  8B53 9D           mov edx, [ebx-63]        ; ³
01083734           ³.  F7DA              neg edx                  ; ³
01083736           ³.  C1E2 10           shl edx, 10              ; ³
01083739           ³.  66:0BD0           or dx, ax                ; ³
0108373C           ³.  52                push edx                 ; ³argll
0108373D           ³.  8B43 99           mov eax, [ebx-67]        ; ³
01083740           ³.  F7D8              neg eax                  ; ³
01083742           ³.  8B53 9D           mov edx, [ebx-63]        ; ³
01083745           ³.  C1E2 10           shl edx, 10              ; ³
01083748           ³.  66:0BD0           or dx, ax                ; ³
0108374B           ³.  52                push edx                 ; ³argur
0108374C           ³.  8B43 99           mov eax, [ebx-67]        ; ³
0108374F           ³.  8B53 9D           mov edx, [ebx-63]        ; ³
01083752           ³.  C1E2 10           shl edx, 10              ; ³
01083755           ³.  66:0BD0           or dx, ax                ; ³
01083758           ³.  52                push edx                 ; ³argul
01083759           ³.  6A 0B             push 0B                  ; ³inx = 11.
0108375B           ³.  E8 C4090000       call MbWarp              ; ÀMbWarp

Of course, it is a matter of taste if you prefer "pure" assembler or a macro. But IMH experience design and development of such applications proceeds faster with macros, and the code is more readable to those who are willing to read the macro's manual entry.

Btw the macro works with ML and HJWasm, but the workaround for making it compatible was non-trivial.

[johnsa]

Hi,

I started looking into the opattr issue today and I don't believe it would be right for us to change this.. From what I can see , 36 is the correct value and 0 is wrong.
From the masm reference for OPATTR (bit definitions):

Code Select Expand


OPATTR/.TYPE Return Value
Bit(s) Meaning
0 References a label in the code segment if set.
1 References a memory variable or relocatable data object if set.
2 Is an immediate (absolute/constant) value if set.
3 Uses direct memory addressing if set.
4 Is a register name, if set.
5 References no undefined symbols and there is no error, if set.
6 Is an SS: relative reference, if set.
7 References an external name.

8-10
000 - no language type
001 - C/C++ language type
010 - SYSCALL language type
011 - STDCALL language type
100 - Pascal language type
101 - FORTRAN language type
110 - BASIC language type


So based on this, for a literal string value passed in as a macro argument:
2   Is an immediate (absolute/constant) value if set.
5   References no undefined symbols and there is no error, if set.

Bit's 2 and 5 should be set. 5 at the very least if you debate the immediate/constant'ness of the literal string.. neither being 0. Bits 2+5 = 36.

[GoneFishing]

That's true
... but HJWasm has -Zg switch :

-Zg                  Generated code is to exactly match Masm's one

From JWASM's manual:

Option -Zg: Masm-compatible Code Generation
Option -Zg makes JWasm try an exact copy of Masm's code generation, which results in the following changes:

    the default prologue for procedures will use
      add [e]sp, - localsize
    instead of
      sub [e]sp, localsize.
    the default epilogue for procedures will almost always prefer to generate opcode LEAVE if possible.
    expressions
      <reg> == 0 and <reg> != 0
    will generate code
      or <reg>,<reg>
    instead of
      cmp <reg>,0.
    if invoke must extend an argument's size from word to dword, register eax remains unchanged.
    the segment value of FAR externals will always be assumed unknown, no matter whether the external is defined inside or outside of a segment block. Thus those labels are excluded from "far call optimization".

I think it would not be that hard to preserve  MASM compatibility , at least through the special command line switch

[johnsa]

That's true
... but HJWasm has -Zg switch :

-Zg                  Generated code is to exactly match Masm's one

From JWASM's manual:

Option -Zg: Masm-compatible Code Generation
Option -Zg makes JWasm try an exact copy of Masm's code generation, which results in the following changes:

    the default prologue for procedures will use
      add [e]sp, - localsize
    instead of
      sub [e]sp, localsize.
    the default epilogue for procedures will almost always prefer to generate opcode LEAVE if possible.
    expressions
      <reg> == 0 and <reg> != 0
    will generate code
      or <reg>,<reg>
    instead of
      cmp <reg>,0.
    if invoke must extend an argument's size from word to dword, register eax remains unchanged.
    the segment value of FAR externals will always be assumed unknown, no matter whether the external is defined inside or outside of a segment block. Thus those labels are excluded from "far call optimization".

I think it would not be that hard to preserve  MASM compatibility , at least through the special command line switch

Ok.. your wish is our command :)

-Zg will now force opattr=0 for literal string and 36 otherwise.
Please test and let me know, source committed to github.

[GoneFishing]

GCC DEBUG=1:

Code Select Expand


gcc -c -IH -D__UNIX__ -DDEBUG_OUT -g -o GccUnixD/symbols.o symbols.c
symbols.c: In function 'DumpSymbol':
symbols.c:807:5: warning: format '%p' expects argument of type 'void *', but argument 5 has type 'union <anonymous>' [-Wformat=]
     printf( "%-12s  %16" I64_SPEC "X %02X %8p %c %8p %s\n", type, value, sym->mem_type, dir->e, sym->ispublic ? 'X' : ' ', (void*)sym->name, (void*)sym->name );
     ^
symbols.c:807:5: warning: format '%s' expects argument of type 'char *', but argument 8 has type 'void *' [-Wformat=]


...
Ok.. your wish is our command :)
...

Sounds great! Still it's not my wish and not a wish at all ... It's an idea
Not sure if I can generate my own ideas  I only translate already existing ideas to you  ;)

[johnsa]

Ok, that last one in symbols.c should be fixed now.

[GoneFishing]

GCC DEBUG=1: no warnings  :t