Hello there!

I just got back to fiddling with assembly and I hit a snag.

If I have a macro that uses some external methods or needs its own data section, how do I go about packaging it with the macro itself?

Let's say there's a macro that calls printf and uses a variable that it should have in .data. Do I just declare another .data section above the macro? Secondly, can I somehow include an '.idata' section with the macro to ensure that the user doesn't have to hunt down the referenced methods?

Thanks a lot

I even thought about dispensing with the .data section and doing a bunch of pushes and label them as my temporary variables at the start of the macro, but I'm not so certain it's a good idea. Or is it?

Declaring global data or local data is also related to the output format you use. If you are using a linkable output (e.g. COFF) then you can declare a global section and place your variable there. If you use a direct executable output then declaring global data in a new section can be problematic. But there are methods available to do section combing at compile time.

In either output format you can use local variables that use the stack. This is perhaps preferred unless you are using some large data structures.

BTW: Using global variables makes using threads inconvenient. Just saying.

Damn, my macro-fu is really weak. I'm going to read up on that and try to decipher it.

Thanks for the pointer

"Section combing" sounds like a cool term, I've been using it for ages though.

The idea is to simply append to a list in FASM's preprocessor (define/equ, I recommend define though) of names or other things which you "use" later when declaring the data.

Don't forget to restore when updating the preprocessor variable. For example, this is how you increase a counter: This increases c by 1.

restore is important because, by default, FASM pushes definitions on top of each other. So c's previous value is still defined, wasting memory for no reason. restore "pops" one definition off the stack, and since it's the only one, we pop and then push a new one with the +1 value (rept sets x to c+1).

Let's say c is 6 before we increase it. If we didn't restore, we'd have something like this on c's internal stack: 0 1 2 3 4 5 6 -- here we'd append 7 to that list (c's current value), which is a waste of memory.

If we pop it goes like this: c = 6, set x to c+1 = 7, restore c (which is only 6), c is now empty/not defined, set c to x (7), c is now just 7.

You append to this list in the macro, but i don't know what kind of data do you need, so I can't give specific help.

When done, you later use the list in the data section (wherever you declare the data section), this works even without a linker if you use "raw" binary output. This would define the list there.

You can also do operations on the list at the data section, once you got all the information about it, like sorting it, or optimizing it, etc.

I tested some time ago and found that for restore vs not-restore it was worse to use restore. The reason for that is because fasm doesn't actually return memory to a pool when using restore; thus you save nothing, and it takes more program code to put in the restore directive. So unless something has changed in that part of fasm's code then I suggest that if you want to save compiler runtime memory then don't use restore when it isn't needed.

Thanks for the counter explanation! Very helpful to see hands-on examples like this.

You might be right in that it could be worse, I never tested it, and never used large lists.

However, it's more future-proof or well, since it's open source, we can always just make it release the restored memory, if really needed... Maybe one day.

Complications abound. You make it sound simple, but down in the code things are very different.

I didn't say it's simple, but if the need arises, it's definitely possible. Well I didn't say it's hard either, I didn't look much into Fasm sources personally.