uasm vs masm

[minor28]

I am using Visual Studio Community 2019 as ide to code ml64 projects. Current project is Stack problem posted here.

Now I will try to replace masm with uasm. I downloaded uasm249_x64.zip and installed it.
Building my project with masm, generates no errors and no warnings.

I changed the custom build to uasm and item type to uasm. I did not make any changes to the code.
Building with uasm generated "Error   MSB3721   The command "uasm.exe /c -win64 -Zp8 /nologo /Zi /Fo"x64\Debug\Source.obj" /W2 /coff   Source.asm" exited with code 1. uasm.targets line 49".

So I took an example from the uasm download

Code Select Expand


    option casemap:none

    includelib kernel32.lib
    includelib user32.lib

externdef MessageBoxA : near
externdef ExitProcess : near

    .data

text    db 'Hello world!', 0
caption db 'Hello x86-64', 0

    .code

OPTION PROC:NONE
main proc
    sub rsp, 28h        ; space for 4 arguments + 16byte aligned stack
    xor r9d, r9d        ; 4. argument: r9d = uType = 0
    lea r8, [caption]   ; 3. argument: r8  = caption
    lea rdx, [text]     ; 2. argument: edx = window text
    xor rcx, rcx        ; 1. argument: rcx = hWnd = NULL
    call MessageBoxA
    xor ecx, ecx        ; ecx = exit code
    call ExitProcess
main endp

    end

Building this code generates same error (MSB3721   The command "uasm.exe /c -win64 -Zp8 /nologo /Zi /Fo"x64\Debug\Project1.obj" /W2 /coff   Project1.asm" exited with code 1. uasm.targets line 49).

With masm, after commenting out line "OPTION PROC:NONE", build is successful and the program works. I can also comment out the two libs.

Does anyone have suggestions on what is missing?

[jj2007]

I get it running with a few changes and only one commandline option: -win64

Code Select Expand

    option casemap:none

    includelib \masm32\lib64\kernel32.lib
    includelib \masm32\lib64\user32.lib

externdef MessageBoxA : near
externdef ExitProcess : near

    .data

text    db 'Hello world!', 0
caption db 'Hello x86-64', 0

    .code

OPTION PROC:NONE
start proc
    sub rsp, 28h        ; space for 4 arguments + 16byte aligned stack
    xor r9d, r9d        ; 4. argument: r9d = uType = 0
    lea r8, [caption]   ; 3. argument: r8  = caption
    lea rdx, [text]     ; 2. argument: edx = window text
    xor rcx, rcx        ; 1. argument: rcx = hWnd = NULL
    call MessageBoxA
    xor ecx, ecx        ; ecx = exit code
    call ExitProcess
start endp

end

[hutch--]

MASM is simpler and more reliable.

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    include \masm32\include64\masm64rt.inc

    .code

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

entry_point proc

    rcall MessageBox,0,"MASM64 Pure and Simple"," UI Template",MB_OK
    rcall ExitProcess,0

entry_point endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    end

comment #

.text:0000000140001000 C8800000                   enter 0x80, 0x0
.text:0000000140001004 4883EC60                   sub rsp, 0x60
.text:0000000140001008 49C7C100000000             mov r9, 0x0
.text:000000014000100f 4C8B0557100000             mov r8, qword ptr [0x14000206d]
.text:0000000140001016 488B157A100000             mov rdx, qword ptr [0x140002097]
.text:000000014000101d 4833C9                     xor rcx, rcx
.text:0000000140001020 FF15E6100000               call qword ptr [MessageBoxA]
.text:0000000140001026 4833C9                     xor rcx, rcx
.text:0000000140001029 FF15CD100000               call qword ptr [ExitProcess]

       #

[minor28]

Thank you,

OK, I stick to masm.

[Mikl__]

Hi, minor28

Code Select Expand

; GUI #
include d:\masm64\include\win64a.inc 
.data               
MsgCaption      db "Uncle Remus tales#2: MessageBox",0
MsgBoxText      db "Win64 Assembly is Great!",0
.code               
WinMain proc
push rsp
      invoke MessageBox, NULL, &MsgBoxText, &MsgCaption, MB_OK
      invoke RtlExitUserProcess,NULL
WinMain endp
end

Code Select Expand

.text:00000000'00400200: 54              push rsp
.text:00000000'00400201: 33C9            xor ecx,ecx
.text:00000000'00400203: 488D1546000000  lea rdx,[000400250]
.text:00000000'0040020A: 4C8D051F000000  lea r8,[000400230]
.text:00000000'00400211: 4533C9          xor r9d,r9d 
.text:00000000'00400214: FF154E000000    call MessageBoxA
.text:00000000'0040021A: 33C9            xor ecx,ecx
.text:00000000'0040021C: FF154E000000    call RtlExitUserProcess

[minor28]

I appreciate your answers and I have no doubt that the uasm example is written correctly. What I wondered was why VS  not can build uasm but masm. I guess it's because VS is MS and masm is MS. VS as an ide for masm64 works just fine. I have written some extensions to better fit to assembly.

Previously, when I coded in masm32, I basically only used the built-in macros invoke, .if, .while etc and some custom macros of  my own. Now Invoke works well but .if which is important for readability I think does not work so well in VS. Therefore, I thought I would try uasm.

Greetings
minor28

[Vortex]

Hi minor28,

The .IF macro is defined in the macros64.inc file which is an important component of the Masm64 package. To get the latest release :

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

[DebugBSD]

The problem with masm64 against uasm64 is the lack of support to macros such as .IF/.ENDIF, and more things such as stack management which is done automatically. Things that UASM adds and that makes more friendly to develop huge projects. If you're a top assembly programmer, you wont have problems with masm64, but anyway, UASM64 is a great tool to start with assembly language programming. I have a lot of projects written in assembly language (MASM32) and thanks to UASM64, most of them are ported without any problem. That's why I think it's a great tool with great possibilities. Althought, some times it's quite time consuming to debug software because the lack of support to some features in the debugging format.

Nice day!
Guille

[stevenxie]

in the masm64. invoke macro,. if macro,. while macro,. repeat macro is as good as the pseudo command in the masm32. I applied them without any problems.

[DebugBSD]

in the masm64. invoke macro,. if macro,. while macro,. repeat macro is as good as the pseudo command in the masm32. I applied them without any problems.

Yes, but, because you're using the MASM64 SDK instead of the MASM64 which comes with Visual Studio. :)

MASM64 doesn't support that "pseudo commands" by default.

[stevenxie]

in the masm64. invoke macro,. if macro,. while macro,. repeat macro is as good as the pseudo command in the masm32. I applied them without any problems.

Yes, but, because you're using the MASM64 SDK instead of the MASM64 which comes with Visual Studio. :)

MASM64 doesn't support that "pseudo commands" by default.

Ml64.exe is the macro assembler, its ancient preprocessor, can weave extremely colorful functional code. The masters, such as Mr. steve hutchesson and Mr. vassily, are also skilled in this, and in the masm64sdk for us to achieve the same advanced grammatical functions as ml.exe. For nothing else, just because masm is Microsoft's macro assembly processor. Macro!!

[Vortex]

Hi DebugBSD,

The Masm64 SDK provides powerful macros, so the high-level constructs should not be a problem. It's the same with Fasm, the HLL elements are defined in include files :

Code Select Expand

macro stdcall proc,[arg] ; directly call STDCALL procedure
{ common
    if ~ arg eq
   reverse
    pushd arg
   common
    end if
    call proc }

macro invoke proc,[arg] ; indirectly call STDCALL procedure
{ common
    if ~ arg eq
   reverse
     pushd arg
   common
    end if
    call [proc] }

[DebugBSD]

Hi DebugBSD,

The Masm64 SDK provides powerful macros, so the high-level constructs should not be a problem. It's the same with Fasm, the HLL elements are defined in include files :

Code Select Expand

macro stdcall proc,[arg] ; directly call STDCALL procedure
{ common
    if ~ arg eq
   reverse
    pushd arg
   common
    end if
    call proc }

macro invoke proc,[arg] ; indirectly call STDCALL procedure
{ common
    if ~ arg eq
   reverse
     pushd arg
   common
    end if
    call [proc] }

Yes, I knew that.

When I said that MASM64 had a lack of support to such macros, I was talking about the problem that minor28 had building his program into Visual Studio.  That's why UASM64 is a great tool. Because, the tool adds such things automatically instead of delegating that to the MASM SDK. It's obvoius that if you want more features, you have two main options: 1) Use the SDK; 2) Create such features yourself.

[hutch--]

MASM has long had the option of writing its own macros, the 1990 version had them and the notation has remained much the same for 30 years. They are no joy to write, the pre-processor is buggy but with enough patience you can do a vast number of things with them. The so called MASM compatible Watcom derivatives have tried to emulate the MASM pre-processor with varying degrees of success.

The win with a terse pig like 64 bit MASM is that you are not at the mercy of a compiler/assembler author and have considerable freedom with procedure design, stackframe layouts and not having to try and twiddle the stack for procedure entry and exit. It takes work but you get considerable freedom without the hassle.