64-bit Assembly: Why I like working with ML64/UAsm/PoAsm/AsmC

[jj2007]

Hi everybody. This is the place to discuss how to advance towards a common approach to 64-bit coding. You may have come here from the survey. Feel free to defend your choices aggressively, not with insults, of course, but with arguments based on logic, observations, and personal experience.

As Zedd pointed out, in a post that I removed to keep this thread tidy, it's often a case of personal preferences - some of us have coded in 64-bit for ten years or so, and old habits don't change easily. However, I believe that we could offer an "entry package" for new members that is easy to use. 64-bit Assembly is more complicated than 32-bit coding, sure, but the main problem is right now that there are too many competing and confusing approaches - see the 5 points in The Survey.

Please, write about your personal experience, bring arguments for or against your favourite 64-bit package, and stay on topic.

[TimoVJL]

As Pelles C x64 needs also asm code, poasm should be covered somehow.

[jj2007]

As Pelles C x64 needs also asm code, poasm should be covered somehow.

Thanks, Timo - added to the survey

> Here, "arguments based on logic, observations, and personal experience" are wanted.

Timo, can you elaborate (in not too many words) what characterises PoAsm, and why you like it for 64-bit coding?

[Mikl__]

Hi Johen
I think anyone can install Visual Studio and get ml64.exe and link.exe from the Visual Studio that Microsoft updates every six months. Inc- and lib-files each user can make on their own, I have already showned how. In addition, Microsoft maintains a help system for WinAPI functions, which is very difficult for a small team to do on their own.

[TimoVJL]

As Pelles C x64 needs also asm code, poasm should be covered somehow.

Thanks, Timo - added to the survey

> Here, "arguments based on logic, observations, and personal experience" are wanted.

Timo, can you elaborate (in not too many words) what characterises PoAsm, and why you like it for 64-bit coding?

I am retired and i keep a break from programming.
I am just more useful local community than programming. Shovel is my tool now

[jj2007]

Hi Jochen
I think anyone can install Visual Studio and get ml64.exe and link.exe from the Visual Studio that Microsoft updates every six months.

Hi Mikl,

Did you try the Grab the 64-bit binaries tool? IMHO downloading Visual Studio and finding ml & link is ok for professional programmers, but it's an overkill for young new members who just started coding...

[Greenhorn]

Hi Jochen
I think anyone can install Visual Studio and get ml64.exe and link.exe from the Visual Studio that Microsoft updates every six months.

Hi Mikl,

Did you try the Grab the 64-bit binaries tool? IMHO downloading Visual Studio and finding ml & link is ok for professional programmers, but it's an overkill for young new members who just started coding...

It depends, I would say. Visual Studio comes along with the best debugger for x64, to be honest, the only useful easy to use debugger for x64, IMHO. In opposite to x64dbg it also supports source code debugging for assembly.
WinDbg is a slim alternative to VS debugger, though.

[Vortex]

Hello,

I would like to speak for Poasm. The high level constructs in 64-bit mode are not crippled like ml64, invoke and the other features are available while writing 64-bit assembly code.

While the macro engines of Poasm and Masm have some differences, this does not pose serious issues for me. Poasm creates MS COFF object modules like Masm.

WinInc , the include file set offered by Uasm's developers ( originally created by Japheth ) can be tweaked to maintain the compatibility with Poasm.

The author of Pelles C, Pelle Orinius is maintining the toolset and I am sending my test reports to Pelles forum. The bugs are fixed by Pelle.

The other main executables of Pelles C polink, polib and porc are very good tools accompanying Poasm.

[jj2007]

Thanks, Vortex, PoAsm is indeed a very good tool. If you have a link to the differences between PoAsm and Masm/AsmC/UAsm macros, I'd be very interested.

Thanks to everybody. I see a great variety of toolboxes - wow

My own baby is JBasic alias dual 64-/32-bit assembly. It works with Masm/AsmC/UAsm, maybe even with PoAsm (I'll have to check).

Conceptually, it is very different from the rest, as it uses (almost) no static libraries. As mentioned elsewhere, "import libraries" don't work if the corresponding DLLs are not present. So JBasic goes directly to the DLL, via macros that check which DLLs and API calls are needed, and loads them via LoadLibrary+GetProcAddress. Speed- and size-wise, it's identical to "import libraries".

JBasic builds on the Masm32 SDK. It uses Windows.inc to create \Masm32\MasmBasic\Res\DualWin.inc, containing all the equates and structures needed, with one major modification: handles and addresses are not DWORD or QWORD but SIZE_P (there are 1438 of them). The advantage is that with a simple switch you can decide whether to assemble as 64-bit (SIZE_P equ QWORD) or 32-bit (SIZE_P equ DWORD) code. Sources assembly flawlessly in both modes, except if you use registers that don't exist in 32-bit mode, of course.

Given that compatibility with ML64.exe was one objective, an invoke macro was needed. It is called jinvoke, and in contrast to the Masm64 SDK invoke, jinvoke counts parameters, checks their type and throws errors if something is wrong.

So much for the pros. The big con: I'm not a fan of 64-bit coding, and struggle to find time for my baby, therefore JBasic is for the time being only a half-complete proof of concept

Selected available macros (there are about 100 of them):

Code Select Expand

jinvoke apiarg, args:VARARG
rv FuncName:REQ,args:VARARG
repargA rarg
Open "I", #1, "MyFile.txt"
Chr$ any_text:VARARG
Hex$ arg
Str$ sform$, sNum0:VARARG
Input$
Val arg$
Print args
PrintLine args
MsgBox 0, "Text", "Title" [, MB_OK]
@AsmUsed$()
Err$()
RgbCol(red, green, blue)

[zedd151]

For Masm64 when I do occasionally use it, I use ml64, and link of the same version. Reason being is that hutch put in a lot of work, for trying to make using the 64 bit SDK as easy as using the 32 bit SDK.
There are major differences of course, but converting many source codes from 32-->64 is rather trivial in many instances; some examples from the 32 bit SDK that I have converted, for instance; they're here, I'll fetch the link to it later.

Later:
https://masm32.com/board/index.php?topic=7450.msg81456#msg81456


.

[Vortex]

Hi Jochen,

If you have a link to the differences between PoAsm and Masm/AsmC/UAsm macros, I'd be very interested.

Good question, I dont't have a link but I will try to create a thread explaining the differences.

[jj2007]

Thanks, Erol.

Nasm+Fasm, if I remember well, do not even have the EXITM <eax> thing, so print str$(myvar) is not possible with them.

The Masm family is powerful in this respect. I wonder whether PoAsm allows to create macros by macros, as used in Dim some$().

Another MASM feature that I frequently use is the creation of variables using e.g.

Code Select Expand

include \masm32\include\masm32rt.inc

.code
start:
ct=0
  REPEAT 5
ct=ct+1
tmp$ CATSTR <Count>, %ct
.DATA?
tmp$ dd ?
.CODE
mov tmp$, ct*1000
  ENDM
  print str$(Count1), "=count1", 13, 10
  print str$(Count5), "=count5", 13, 10
  exit

end start

[Vortex]

Hi Jochen,

Fasm does not provide yet a macro like EXITM :

https://board.flatassembler.net/topic.php?t=22715

About Poasm handling macros creating macros, I think that should be possible.

[jj2007]

Thanks, Erol.

Fasm does not provide yet a macro like EXITM :

https://board.flatassembler.net/topic.php?t=22715

Roman, 02 May 2023: But we could writing exitm to preprocessor_directives
exitm
https://www.asmcommunity.net/forums/topic/12375/

Screenshot from the asmcommunity link, over twenty years ago. The "Why" tells us a lot about the FASM mindset

[Vortex]

Hi Jochen,

In 2023, the macro EXITM should be a standart statement in the vocabulary of assemblers. While the Fasm coomunity have very talented members, it's difficult to understand why they didn't incorporate EXITM to their assembler.