flat assembler
Message board for the users of flat assembler.

Index > Main > Macros Pros and Cons

Author
Thread Post new topic Reply to topic
iic2



Joined: 26 Jun 2008
Posts: 123
iic2
....
http://www.codeproject.com/KB/cpp/Macros_vs_Inlines.aspx
Quote:
Function-like macros when used always expand at the point of usage. The function-like macros are pre-processed at compile time, and as a result, there is really no macro existing at runtime. This is why there is an increase in the size of the binary files.

Yet another major setback of the function-like macros is the lack of type checking leading to a high level of type insecurity. The arguments passed on to a macro are never preprocessed. Looks totally harmless, doesn’t it?


Function-like macros and any other type:
The only reason I don't like to use marcos is I thought it will expand your code size at assembler time. But that don't seem to be the case. If a macro is called 10 times to build your windows and furctions and don't add nothing extra, I have no problem with that. but is there more it than that... would 10 expand to 1x,2x 3x,20x, 40x at comply time or is it like un-initialized data which only expand at runtime and use more
memory? If so, I can live with that.

As long as it don't increase the size of the the final file at comply time by much other than the amount expected () I might as well use them.

By saying **expand at the point of usage** This is a difference. Do they mean for each call to a marco do this mean merory continue to grow with each call? Do 100 calls mean 100 extra copies. If so, can we clean up that extra memory and use it for something else. Smile

Anyway, If this is right I can live with that because it's only memory and memory is getting bigger and cheaper these days.
Quote:
Consider the example below which depicts the disadvantage of the lack of type checking. In this example, the result is always the value passed in as the second argument.

I care less of type checking because I'll spend forever on a block of code until I manually check ALL conditions and some... Am Im right to think this way... to not have any need for it.

If a program had 1000 marcos all well written to be safe and fast I see no reason not to use them, finally. If macros only expand in memory that's a bonus to me.

Am I on the right track. The whole world is talking about C++, JAVA etc, I'm talking assembler. It gave me a lot to think about. I want to end my fear of using them. I can get a better understanding from the assembler codes point of view.
Post 18 Aug 2008, 07:17
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
fasm macros are compile-time only. There are no function-like macros in fasm, AFAIK. The article you've quoted is about C-specific differences between inline functions and function-like #define macros.
iic2 wrote:
Quote:
The function-like macros are pre-processed at compile time, and as a result, there is really no macro existing at runtime. This is why there is an increase in the size of the binary files.
...

The only reason I don't like to use marcos is I thought it will expand your code size at assembler time. But that don't seem to be the case. If a macro is called 10 times to build your windows and furctions and don't add nothing extra, I have no problem with that. but is there more it than that... would 10 expand to 1x,2x 3x,20x, 40x at comply time or is it like un-initialized data which only expand at runtime and use more
memory? If so, I can live with that.

As long as it don't increase the size of the the final file at comply time by much other than the amount expected () I might as well use them.

Simply put, macros are convenient feature of compiler to make source more compact and understandable, just as instructions' mnemonics, labels, symbolic constants, expressions and formatter directives are.

Of course, you can go bare-bone and even db the entire output -- fasm allows that (in fact, I often use fasm to rebuild binary files, bitmap fonts for example). Macros allows to make some building blocks for repetitive tasks (structures, API calling conventions, export/import support, resources, etc.)

About code/data size increase: each time you use macroinstruction in your source, it will be replaced with it's contents (that is the part between {} braces) at the preprocessing stage. Tomasz even made stand-alone preprocessor fasmpre from one of the builds (invaluable tool to check for errors in macros), so you can see the source after preprocessing stage but before assembling. Therefore each macroinstruction expands to some source fragment which in turn usually assembles to some bytes in the output file. But, as I wrote above, macros are just a convenient feature, for example, to write
Code:
invoke  MessageBox, [hWnd], szMessage, szCaption, MB_OK    
instead of
Code:
push    MB_OK
push    szCaption
push    szMessage
push    [hWnd]
call    [MessageBoxA]    
However, macroinstruction can do much more than simple substitution (see INCLUDE\MACRO subfolder in your fasm folder for some complex macros).

In short:
1. Macroinstruction is a compile-time feature.
2. Each time you use macroinstruction it will be replaced with some source fragment (albeit probably different each time).
3. Type checking has nothing to do with macroinstruction.
4. Are you on the right track? That depends. Programming with assembler will give you most specific knowledge on how programs works. There is a good joke about programming (how to shoot yourself in the foot in different languages):
Quote:
Assembler:
You try to shoot yourself in the foot, only to discover you must first invent the gun, the bullet, the trigger, and your foot.
Post 07 Sep 2008, 00:48
View user's profile Send private message Reply with quote
FrozenKnight



Joined: 24 Jun 2005
Posts: 128
FrozenKnight
The only Macros is use are the struct macros. I actually enjoy inventing the Gun, bullet, foot and trigger along with all the physics to project the bullet.
Post 07 Sep 2008, 09:17
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
FrozenKnight,
Macros add some automation for repetitive/tedious tasks. They also combine some simple instructions in macroinstructions, which are, given the proper name and comment, very useful to make sources much more readable. Periodically I review my old programs' sources to inject newly found tricks/concepts, and well chosen macro name as well as comments helps me greatly to understand once again those bithacks I'd developed Wink.
For me,
Code:
crctab  CRC32_TABLE_LE 0xEDB88320    
is almost self-explanatory, contrary to 256 dds.
Post 07 Sep 2008, 13:58
View user's profile Send private message Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
baldr wrote:
FrozenKnight,
Macros add some automation for repetitive/tedious tasks. They also combine some simple instructions in macroinstructions, which are, given the proper name and comment, very useful to make sources much more readable. Periodically I review my old programs' sources to inject newly found tricks/concepts, and well chosen macro name as well as comments helps me greatly to understand once again those bithacks I'd developed Wink.
For me,
Code:
crctab  CRC32_TABLE_LE 0xEDB88320    
is almost self-explanatory, contrary to 256 dds.


I agree with what you say, Especially with fasmw macro's where you can have a high level feel and organization without the usual high level language bloat. However, It would be good for beginning programmers to refrain from using most macros and program more in the raw. This would allow you to get a good knowledge of the intel instruction set (how different addressing modes works especially), use the mmx/sse1&2&3 instructions, make improvments to the macros themselves, and finally to be able to read crash dump disassemblies.

_________________
Gimme a sledge hammer! I'LL FIX IT!
Post 07 Sep 2008, 16:47
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
madmatt

I agree with you too. It's important to know what each used macroinstruction does, but it's much more important to know how macroinstruction does that. For example, I almost immediately replaced
Code:
    lea edx,[..address]
    push edx    
in pushd macro (WIN*X*.INC) with
Code:
    push edx
    lea edx,[..address]
    xchg edx,[esp]    
just to be sure that I occasionally will not trip over this wire...

Nevertheless some macros are of great utility, like library/import sweet twins. Bare core programming is a great effort in discipline and attention to details, so every bit of help counts, especially for novice.
Post 10 Sep 2008, 23:41
View user's profile Send private message Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt
Good Example. That's something I need to do, I need to pactice my preaching and study the macro library and commands much more in-depth. (by the way, this "fix" should probably be in the next update to fasm. Smile )

_________________
Gimme a sledge hammer! I'LL FIX IT!
Post 11 Sep 2008, 11:11
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.