News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

How can I use @ProcName ?

Started by mineiro, February 19, 2023, 10:35:28 PM

Previous topic - Next topic

jj2007

Quote from: dannycoh on January 27, 2024, 08:40:55 AMfind some other assembler

Good luck finding a better one. Most of the other assemblers can't even return something from a macro, as in
.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?
Assembly language programming should be fun. That's why I do it.

jj2007

Quote from: NoCforMe on January 27, 2024, 11:18:17 AMAny 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?
Assembly language programming should be fun. That's why I do it.

jj2007

Quote from: NoCforMe on January 27, 2024, 01:30:48 PMSlower? 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 :cool:

NoCforMe

Omigod, you have my sincerest sympathy. I mean, how can you stand the inconvenience?
Assembly language programming should be fun. That's why I do it.

jj2007

Quote from: NoCforMe on January 28, 2024, 09:27:11 AMhow 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.)
Assembly language programming should be fun. That's why I do it.

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.
Equations in Assembly: SmplMath

jj2007


Vortex

#41
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 :

QuoteFree TASM clone with support for new CPU instructions

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

jj2007

Quote from: jj2007 on January 28, 2024, 10:45:06 AMRe 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:
QuoteNo, 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:
QuoteBut 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 :thumbsup:

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 :

QuoteWhy inline macros are not recommended?

QuoteThe 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

Quote from: Vortex on January 28, 2024, 09:08:53 PMMacros 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:
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?
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

QuoteIn my opinion, inline macros are great tools supported by Masm and compatible assemblers.
:thumbsup: