I've read somewhere here that Tomasz Grysztar doesn't like the idea of inline macros. But why? Maybe because it can add some ambiguity or it seems not easy to implement? Or it has some drawbacks?

Maybe you will like this idea of syntax which will fit FASMG well IMHO. And it will not be required to rewrite much things. The main idea is to use <? ... ?> construction in place where it is possible to put a variable name. Like:

These makeinlinestr, i32tohex and similar macros (which will be usable inline) can be just struc macros which emit nothing at this place and just set a value to a variable. If it emits something, it will be emitted exactly before an actual instruction.

I've read somewhere here that Tomasz Grysztar doesn't like the idea of inline macros. But why? Maybe because it can add some ambiguity or it seems not easy to implement? Or it has some drawbacks?

It is not that I don't like them, it is just that my design of fasm was based on some assumptions about the syntax of assembly languages, including one that this is a line-based language where the individual commands reside in separate lines. These assumptions are embedded deeply in the design of fasm and fasmg parsers and symbol structures and it is not possible to implement anything resembling inline macros without altering the basic building blocks of these engines.

Of course it is possible to emulate inline macros by pre-processing all lines with "macro ?". I don't know whether this is viable - it would be slow, of course, bo so are many other macro-based solutions in fasmg. And the syntax you proposed would be quite easy to detect and pre-process with MATCH in the "macro ?" handler.

Just because I simply cannot resist writing some interesting macros for fasmg, I implemented the pre-processor using "macro ?" that I mentioned above. It uses the syntax with "<?" and "?>" markers that you suggested:

I've tested how it affects time of assembly. In my situation it is +33% of time (4 seconds instead of 3). It seems that I can live with it. Thank you very much.

It is really a must have feature for me. IMHO, 1 line = 1 macroinstruction is good for instructions which actually emit some bytes to output. But if some instruction just makes some work with variables, like conversion from int to string or just merging some strings into one variable, and doesn't emit anything, and this data will be used just as an argument of the next instruction which will emit some code, it looks not good and actually makes the code more cluttered.

Also I think I'll add some kind of prefix for these inline macro, just to avoid possible intersection with general macros. I'll add the "imacro" macros which will define such kind of inline macros with names like "imacro.usermacroname", and I'll add to the <? ?> handler automatic addition of the "imacro.", so it still will be possible to write <? usermacroname ?>, and it will not prevent a programmer from creation and using a normal (not inline) macro with the same name if it will be required.

It seems that I completely misunderstand FASMG macros I thought that it will be the easiest one, but it doesn't work. It has to work line a normal macro, but with adding of the _imacro postfix for an inline macro name. (I've decided to use postfix because in this case it will take into account namespaces).

First, it uses the "begin" proxy macro to start the new macro only after closing the MATCH block. Second, the "end?.imacro" needs to be unconditional (hence the "!" modifier) to be unrolled while a macro definition is in process (otherwise it is consumed into a macro body).

But the "macro ?" is supposed to not affect any code without <? ?>. Is this fix ok for such purpose?

I've just read why unconditional macros could be required (and it is understandable). But it seems that the FASMG Manual says nothing about unconditional ESC (and LOCAL). Or you're talking about stuff from this topic?

But the "macro ?" is supposed to not affect any code without <? ?>. Is this fix ok for such purpose?

It should be OK, but it is better to skip unnecessary processing of "macro ?" where possible.

VEG wrote:

I've just read why unconditional macros could be required (and it is understandable). But it seems that the FASMG Manual says nothing about unconditional ESC (and LOCAL). Or you're talking about stuff from this topic?

Yes, the manual currently does not define a complete "catalog" of unconditional directives other that control directives (these are unambiguously defined as unconditional in section 11). The details of what other instructions are unconditional are still being worked out, as shown on the example of LOCAL. I may update the documentation with a precise information in the future.

But it doesn't work because local result#resultn always generates "resultresultn", not "result0" and etc. How to attach a number from a variable to another variable name?

I've changed the code a bit. Now the result variable isn't a global variable, it is a local variable which is passed as the first argument for an imacro, and the imacro sets a value to this variable. Also I'm using just "result" as a name of the result variable, like it is in good old Pascal/Delphi

An idea. Maybe it will be very convenient to allow another variant of label which will generate a new local variable every time when this instruction is executed. Like when "newlocal temp" will be used inside a loop, this "temp" variable will be new every iteration of this loop. It will make such code much simpler. It will be possible to use just "local result", and every iteration this "result" will be a new local variable.

It outputs 0x1234 twice. I think that it is because this macro uses one result variable for all results, so previous results are overwritten to the latest one.

You're right, I made the macro that originally relied on $result being symbolic. In sample I used "=" because it seemed to work (though I still noted that it can be symbolic) but now you found the problems with it.

So the only good way to use that original macro is in fact to define $result symbolically:

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum