How can I use @ProcName ?

[jj2007]

find some other assembler

Good luck finding a better one. Most of the other assemblers can't even return something from a macro, as in

Code Select Expand

.if len(esi)>20
   MsgBox 0, str$(eax), "The length of esi:", MB_OK
.endif

[NoCforMe]

Any reason you can't use good old MASM?

[jj2007]

Any reason you can't use good old MASM?

Serious bugs, for example?

Besides, 64-bit MASM is severely crippled, and all MASM versions are a factor 4-5 slower than UAsm.

[NoCforMe]

But but ... they didn't say anything about 64-bit.

Slower? So who give a shit about that? Really? Are you that impatient?

[jj2007]

Slower? So who give a shit about that?

You are right, for hello world proggies MASM is fast enough. But for assembling RichMasm I would have to stare 12 seconds at a blank output window until the first error messages start to crawl in. Unacceptable

[NoCforMe]

Omigod, you have my sincerest sympathy. I mean, how can you stand the inconvenience?

[jj2007]

how can you stand the inconvenience?

I don't - I use UAsm, like everybody who works on serious assembly projects ;-)

[NoCforMe]

So what's your ranking of all the *asms available out there? (Asking out of ignorance, as MASM is all I've ever used.)

[jj2007]

David,

In practice, I use UAsm64. From time to time I check if my bigger sources still assemble with MASM (6.15 is the minimum, 14.x and higher are often buggy). Most of the time it works, but the RichMasm source, for example, can't cope any more with the limitations of MASM. And really: MASM is very, very slow.

Then there is AsmC: about 25-30% faster than UAsm, so roughly a factor 7-8 faster than MASM. Nice, but Nidud has added so much eerie C stuff to his assembler that I don't trust it.

UAsm is fast, less buggy than MASM, and some people do maintain it. Even if nobody worked on it any more, it's so good that it will be sufficient for all assembly coding in my lifetime.

Re FASM, TASM, NASM: the non-MASM assemblers may be even a tick faster than UAsm, but their macro engines are very poor. No chance to do a print str$(ecx) because there they don't implement EXITM <eax>.

I have never tried PoAsm, and I doubt MasmBasic would be possible with it, but it might be an alternative for some people.

[HSE]

JWasm also is working. It is currently been updated by Japheth now.

[jj2007]

JWasm also is working

Right. There is a Wikipedia page on various versions, such as HASM and HJWASM.

[Vortex]

Tasm ( Turbo Assembler ) is offered by Embarcadero as a component of RAD Studio :

https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Turbo_Assembler_Options

Lazy Assembler (LZASM) by Stepan Polovnikov :

Free TASM clone with support for new CPU instructions

http://www.phatcode.net/downloads.php?sub=compilers

[jj2007]

Re FASM, TASM, NASM: the non-MASM assemblers may be even a tick faster than UAsm, but their macro engines are very poor. No chance to do a print str$(ecx) because there they don't implement EXITM <eax>.

Searching "fasm" "macro" "exitm" I found this 2005 post by Tomasz Grysztar, the creator of FASM:

No, inlining the macros is something against the fasm's concept. The macro in fasm is just a special kind of "mnemonic", which gets converted into chain of other lines by preprocessor.

So, in FASM print str$(eax) (invented by Hutch 20 years ago) is impossible by design.

Same for TASM.

P.S.: More recently, in May 2023, Roman posted this:

But we could writing exitm to preprocessor_directives Smile
Time to upgrade preprocessor_directives !
Comrades.

exitm
https://www.asmcommunity.net/forums/topic/12375/

I think FASM would be the perfect solution for our bare metal fans and macro haters

[Vortex]

Hi Jochen,

I don't understand why the author of Fasm is against inline macros. In my opinion, inline macros are great tools supported by Masm and compatible assemblers. Asking ChatGPT :

Why inline macros are not recommended?

The use of inline macros in programming is not inherently discouraged, but there are considerations and trade-offs that developers need to be aware of. Inline macros can have both advantages and disadvantages, and their appropriateness depends on the context and the specific requirements of the codebase. Here are some reasons why inline macros may not be recommended in certain situations:

Code Readability:

Inline macros can make the code harder to read and understand, especially if they are complex or involve multiple expressions. This can impact code maintainability and the ease with which other developers can comprehend and modify the code.
Debugging and Profiling:

Debugging and profiling tools may have difficulty handling inline macros. When stepping through code or analyzing performance, macros can introduce challenges, as they are expanded at compile-time and may not be as straightforward to inspect during debugging.
Namespace Pollution:

Macros are expanded directly in the code, which can lead to namespace pollution. If macro names clash with variable or function names elsewhere in the codebase, it may result in unexpected behavior.
Type Safety:

Macros do not respect type safety, as they operate purely on text substitution. This lack of type checking can lead to subtle bugs that are challenging to identify and debug.
Maintenance Challenges:

Changes to inline macros can have a cascading effect on the entire codebase. If a macro is modified or removed, it may require updates across multiple locations in the code, making maintenance more error-prone.
Compiler Optimizations:

Modern compilers are sophisticated and often perform inline optimizations automatically. Manually inlining code through macros might not provide significant performance benefits and can even hinder the compiler's ability to optimize the code effectively.
Portability:

Macros might rely on compiler-specific features or assumptions about the underlying platform, limiting code portability across different compilers or architectures.
While there are cases where inline macros can be useful, such as for performance-critical sections of code or when used judiciously for code generation, it's essential for developers to carefully consider the implications and weigh the benefits against the drawbacks. In many situations, alternative approaches, such as inline functions or template functions in languages like C++ or Rust, may offer a more readable and maintainable solution without sacrificing performance.

[jj2007]

Macros do not respect type safety, as they operate purely on text substitution. This lack of type checking can lead to subtle bugs that are challenging to identify and debug.

Not true, dear ChatGPT; I have plenty of such sequences in my code:

Code Select Expand

if destType eq MbReal4
fstp REAL4 ptr [edx]
elseif destType eq MbReal8
fstp REAL8 ptr [edx]
elseif destType eq MbReal10
fstp REAL10 ptr [edx]
endif
C/C++ fans are proud of their type safety, but can they do this?

Code Select Expand

include \masm32\MasmBasic\MasmBasic.inc
somebyte db 123
someword SWORD 33333
somedword dd 123456789
  Init
  fldpi
  movd xmm1, somedword
  movd ecx, xmm1
  Print Str$("ecx:\t%i\n", ecx)
  Print Str$("xmm1:\t%i\n", xmm1)
  Print Str$("ST(0):\t%i\n", ST(0))
  Print Str$("byte:\t%i\n", somebyte)
  Print Str$("word:\t%i\n", someword)
  Print Str$("dword:\t%i\n", somedword)
EndOfCode

In my opinion, inline macros are great tools supported by Masm and compatible assemblers.