flat assembler
Message board for the users of flat assembler.

Index > Macroinstructions > Matching local symbol with dynamically built name

Author
Thread Post new topic Reply to topic
DimonSoft



Joined: 03 Mar 2010
Posts: 834
Location: Belarus
DimonSoft
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?
Post 13 Aug 2015, 14:45
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17714
Location: In your JS exploiting you and your system
revolution
DimonSoft wrote:
... begin_ctx, end_ctx and stuff like that are defined as local symbols in the outside block ...
I don't see that in the code you posted. Can you please post all the relevant bits so we can see what you have done.
Post 13 Aug 2015, 14:59
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 834
Location: Belarus
DimonSoft
revolution wrote:
DimonSoft wrote:
... begin_ctx, end_ctx and stuff like that are defined as local symbols in the outside block ...
I don't see that in the code you posted. Can you please post all the relevant bits so we can see what you have done.


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.
Post 13 Aug 2015, 15:21
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
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
Post 13 Aug 2015, 16:15
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 834
Location: Belarus
DimonSoft
l_inc wrote:
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.


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.
Post 13 Aug 2015, 17:34
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
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
Post 13 Aug 2015, 23:12
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 834
Location: Belarus
DimonSoft
l_inc wrote:
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.

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?
Post 14 Aug 2015, 17:25
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
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
Post 15 Aug 2015, 16:07
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 834
Location: Belarus
DimonSoft
l_inc

Thanks, got the idea.
Post 19 Aug 2015, 11:14
View user's profile Send private message Visit poster's website 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 GitHub, YouTube, Twitter.

Website powered by rwasa.