flat assembler
Message board for the users of flat assembler.
Index
> Macroinstructions > Matching local symbol with dynamically built name |
Author |
|
DimonSoft 13 Aug 2015, 14:45
Following the topic of Pascal-like begin…end syntax I wrote a set of macros for different keywords. Definitions for most of them have the following structure:
Code: macro define_keyword { macro keyword Params& \{ define_keyword match k , keyword_ctx \\{ k Params \\} \} } define_keyword where keyword is a placeholder for the keywords like, say, begin, end, etc. So, I’d like to write a keyword macro to simplify the creation of such keywords in the form: Code: keyword begin keyword end ; ... The macro should generate the definition as shown above. It currently goes something like this: Code: macro keyword Name* { local _def macro _def \{ macro Name Params& \\{ _def match k , Name \\# _ctx \\\{ k Params \\\} \\} \} _def } My problem is that begin_ctx, end_ctx and stuff like that are defined as local symbols in the outside block, so in fact they get replaced with something like begin_ctx?3, end_ctx?5, etc. Due to this reason, the concatenation doesn’t give me the symbol I need, i.e. it produces begin_ctx instead of local’ed version like begin_ctx?3. Is it possible to solve the problem with current FASM preprocessor implementation? |
|||
13 Aug 2015, 14:45 |
|
DimonSoft 13 Aug 2015, 15:21
revolution wrote:
Code goes something like this (unrelated bits removed): Code: match , { local Error,\ uses_ctx, uses_def, uses_stub, uses_program, uses_unit,\ begin_ctx, begin_def, begin_stub, begin_program,\ end._ctx, end._def, end._stub, end._program, end._unit macro Error Message* \{ display Message err \} define uses_ctx uses_stub define begin_ctx begin_stub define end._ctx end._stub ; ==> I’m trying to generate these macros via another macro macro uses_def \{ macro uses Params& \\{ uses_def match u , uses_ctx \\\{ u Params \\\} \\} \} macro begin_def \{ macro begin Params& \\{ begin_def match b , begin_ctx \\\{ b Params \\\} \\} \} macro end._def \{ macro end. Params& \\{ end._def match e , end._ctx \\\{ e Params \\\} \\} \} uses_def begin_def end._def ; Custom implementations of the keywords depending on the context macro uses_stub \{ Error "`uses` clause not allowed here" \} macro uses_program List& \{ ... \} macro uses_unit List& \{ ... \} macro begin_stub \{ Error "`begin` clause not allowed here" \} macro begin_program \{ ... \} macro end._stub \{ Error "`end.` clause not allowed here" \} macro end._program \{ ... \} macro end._unit \{ ... \} ... } uses_ctx, begin_ctx and end._ctx get redefined in several places this way: Code: define uses_ctx uses_program ; May also be uses_unit, etc. I’m trying to make a macro that would simplify the declaration of recursive macros after the ==> comment. |
|||
13 Aug 2015, 15:21 |
|
l_inc 13 Aug 2015, 16:15
DimonSoft
I think, you're over-engineering your macros. E.g., I don't see any need for recursive macros. And the macro-implementations of the keywords aren't gonna be equal, so it doesn't make sense to generate them all with a single macro. Besides, it seems, you're trying to integrate contradictory ideas into your macro architecture: on one hand the keyword macro should generate a standalone independent keyword, on the other hand it should share its context with other keywords. You could try to define the _ctx suffix as a local symbol and generate keywords by concatenating the suffix to the Name, but it seems the architecture is broken anyway, and this might not help. _________________ Faith is a superposition of knowledge and fallacy |
|||
13 Aug 2015, 16:15 |
|
DimonSoft 13 Aug 2015, 17:34
l_inc wrote: DimonSoft Actually, the first idea was to try to make a macro that would simplify recursive definition, something like Code: macro_rec mymacro params { ... } Then I noticed it could also be useful for this part of code. I guess, yes, it's an over-engineering, but having a short means of creating a recursive macro would be a good thing since recursive macros are not that rare from what I see in search results. |
|||
13 Aug 2015, 17:34 |
|
l_inc 13 Aug 2015, 23:12
DimonSoft
Quote: a short means of creating a recursive macro would be a good thing since recursive macros are not that rare They are also not as common. In some cases there's a way to avoid recursion, and it should be done if possible, because recursive macros induce high memory and compile time overhead. Additionally the way a macro recurs differs for different macros, and there's no way to make a universal recursion. _________________ Faith is a superposition of knowledge and fallacy |
|||
13 Aug 2015, 23:12 |
|
DimonSoft 14 Aug 2015, 17:25
l_inc wrote: DimonSoft I'm definitely not a professional in macros, but the only way of making recursive macro I've ever seen at FASM board is the one I tried to use above (with outside "define" macro). I would sincerely appreciate if you or anyone else collected links to the topics or made a review of (a) other means of making recursive macros and (b) common ways to avoid macro recursion with current preprocessor implementation. I guess, it could also be useful for others (since this topic might have other keywords than the topics related to the mentioned questions). P.S. I've read somewhere on the board about FASM 2 being slowly developed. I wonder what is its current state. Does anyone have any insight? |
|||
14 Aug 2015, 17:25 |
|
l_inc 15 Aug 2015, 16:07
DimonSoft
Quote: I've ever seen at FASM board is the one I tried to use above (with outside "define" macro) That is correct. I meant some more subtle differences: you might wanna recur on different conditions and different locations of the macro body, it might happen before or after you purge a previous definition, or maybe you don't purge it at all, or you might be willing to call the def_ macro conditionally, or your def_ macro could be parameterized like this one. So there's not much you could make generic in this case. Quote: (b) common ways to avoid macro recursion with current preprocessor implementation There's no theory behind what I said. It's just a recommendation like "try to solve the problem differently". It's like asking about common ways to reduce algorithm complexity: there's no common way to transform bubble sort into heap sort. I'm sure my above linked macro is made very suboptimal and could be implemented without the surrounding def macro. In some cases it's possible to replace stacks of macros with stacks of symbolic constants. In some cases it's possible to offload the preprocessor code functionality to the assembly stage, but it requires you to take a different look at your problem. In some cases there's just no way to avoid recursion. Quote: I've read somewhere on the board about FASM 2 being slowly developed. Current playground for filtering and stabilizing some ideas for fasm 2 implementation is fasm g. You may try it out and report your findings (aka bugs) and difficulties, and maybe implement new or extend existing ISAs. _________________ Faith is a superposition of knowledge and fallacy |
|||
15 Aug 2015, 16:07 |
|
DimonSoft 19 Aug 2015, 11:14
l_inc
Thanks, got the idea. |
|||
19 Aug 2015, 11:14 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.