f0dder wrote:

Ie, instead of the rept and match trick above, you would either use irp or a forward block to do ".count equ .count + 4" (gathering up the symbolic string above). Then, you'd do...
extrn '__imp__'#func'A@'#§.count as func:dword (assuming § is used for evalute-equate-and-replace). Wouldn't that be a lot nicer syntax and effort-wise?

Sure, looks fine except that I don't have a "§" key on my keyboard

f0dder wrote:

... are the nesting-slashes necessary inside the match block? Or are you adding them just for good measures?

The only slashes you can eliminate are the ones preceding the open curly brackets ({), I put those for good measure to remind me how deep we are in the rabbit hole. Notice that `func has no leading backslash but `p does. That is important. The func must be replaced by the outer macro and the p must be replaced by the inner match. The #'s must not concatenate too early so you need the backslashes there also.

macro dodisplay name, [arg]
{
common
   local .count
        display name,":", 13, 10
      .count equ '0'        ; will obviously only work for 0-9
forward
       display 9, .count, '{'
       irp iter, arg \{ display '<',iter,'>' \}
      display '}', 13, 10
  .count equ .count+1
}
define str_a1 'one'
define str_a2 'string'
define str_a3 'for'
define str_a4 'nations'
list_b equ str_a1, str_a2, str_a3, str_a4
dodisplay " equated", list_b
dodisplay "`equated", `list_b
dodisplay "#equated", #list_b
    

Do you (or even better, Tomasz ) suppose such an evaluate-operator could be implemented in FASM-1.x? And can anybody think of any gotchas, possible inconsistencies, etc?

OK, let me see if I understand this correctly, then... without the inner nesting-slashes, would the preprocessor first expand "extrn '__imp__'\#`func\#'A@'\#\`p as func:dword" to "extrn '__imp__FooBarA@'`p as func:dword', before entering the match block? (Not sure how it'd expand `p when not being in the match block).

I suppose this leads to a question on how the preprocessor works (I didn't grok the explanation in the fasm docs fully, but I guess reading it at 4am didn't help ). Does it work in multiple passes, until it has done a pass that didn't lead to any expansions? In my mind it would be doing... recursive descent(?) every time a macro call is done.

Btw, a "stringify" operator could be very helpful when debugging macros - this might sound similar to the `-operator, but not exactly. Consider the following example:

Code:

macro dodisplay name, [arg]
{
common
     local .count
        display name,":", 13, 10
      .count equ '0'        ; will obviously only work for 0-9
forward
       display 9, .count, '{'
       irp iter, arg \{ display '<',iter,'>' \}
      display '}', 13, 10
  .count equ .count+1
}
define str_a1 'one'
define str_a2 'string'
define str_a3 'for'
define str_a4 'nations'
list_b equ str_a1, str_a2, str_a3, str_a4
dodisplay " equated", list_b
dodisplay "`equated", `list_b
dodisplay "#equated", #list_b
    

For the first dodisplay invocation, the preprocessor inserts the EQU text and then calls the macro, and the second simply gives me "list_b" as a name. I'd like to get the "contents" of the equ dumped in string form... #-operator doesn't do the trick either, since it expands the contents first. How is list_b stored in the equate, anyway? Upon seeing the equ, are the str_ax expanded and concatenated, or are symbolic references kept? Is it stored internally as {"onestringfornations"}, {"one" "string" "for" "nations"} or {str_a1 str_a2 str_a3 str_a4}? It doesn't seem to make a difference whether I add ',' or not in the equate.

Also, is there a way to keep '<'brackets'>' in an equate? With my dodisplay macro, I can do dodisplay <str_a1, str_a2>, <str_a3, str_a4> giving the macro two args, each with two IRP'able elements... is it possible to do this symbolically with an equate?

Thanks for bearing over with my questions - I'm pretty sure there'll be more

macro DI [instr] {
    common
      local string,last
   last equ ','
      irps symbol,instr \{
          string equ
          match =+,symbol \\{string equ '+'\\}
                match =-,symbol \\{string equ '-'\\}
                match =*,symbol \\{string equ '*'\\}
                match =/,symbol \\{string equ '/'\\}
                match ==,symbol \\{string equ '='\\}
                match =<,symbol \\{string equ '<'\\}
          match =>,symbol \\{string equ '>'\\}
          match =(,symbol \\{string equ '('\\}
                match =),symbol \\{string equ ')'\\}
                match =[,symbol \\{string equ '['\\}
                match =],symbol \\{string equ ']'\\}
                match =:,symbol \\{string equ ':'\\}
                match =,,symbol \\{string equ ','\\}
                match =|,symbol \\{string equ '|'\\}
                match =&,symbol \\{string equ '&'\\}
                match =~,symbol \\{string equ '~'\\}
                match =RVA,symbol \\{string equ 'RVA'\\}
            match =rva,symbol \\{string equ 'rva'\\}
            ;match ={,symbol \\{string equ '{'\\}
             ;match =},symbol \\{string equ '}'\\}
             ;match =#,symbol \\{string equ '#'\\}
               ;match =`,symbol \\{string equ '`'\\}
               ;match =',symbol \\{string equ "'"\\}
             ;match =",symbol \\{string equ '"'\\}
             match ,string last \\{display ' '\\}
                last equ string
             match any,string \\{display string\\}
         match ,string \\{
                    if symbol eqtype ''
                               display "'"\#\`symbol\#"'"
                 else
                                display \`symbol
                   end if
              \\}
  \}
}    

macro ShowEquContents var{match x,var\{DI x\}}    

No. The outer macro will do all ` and # things it sees (in this case just the `func) and strip one layer of backslashes and then pass on to the next layer in turn. So you get "extrn '__imp__'#'Function0'#'A@'#`p as Function0:dword" and then the match will see the #'s and the `p and do those.

It is single pass. Just expand and generate code into a buffer. Once expanded, process the buffer and generate more code as each layer of macrodom is stripped off.

Here is my DI macro I used when learning about all this stuff. I think I have posted it before but here it is again.

Multi pass would mean it re-processes the same data again. But it does not do that. A macro is expanded when instantiated once only. After expansion, the resulting code is then processed as per normal back into the main program loop. If it so happens that there is an embedded macro it will be discovered only after the outer macro has been fully expanded and expansion is finalised.

And yes, any improvement in string handling would be a nice addition.

If I understand you correctly, doesn't this mean that upon seeing a macro instantiation, basically the following happens:
1. notice where macro instantiation is done.
2. expand macro but don't expand inner macro instantiations.
3. continue preprocessing from address saved in #1, not the line after the original invocation.

While this obviously isn't going to re-preprocess the entire source, I still consider it a multi-pass approach, since you're processing much of the same macro code multiple times (of course it's not THE same code being re-processed, since expansions have been done ).

What's Tomasz' position, these days, on accepting code from others into the mainline FASM codebase? Better (as in, any ) string handling would be nice, but Tomasz probably have more important things to work on... I'm not volunteering though, the lack of documentation (or even comments) of the source is pretty daunting - and I didn't get a chance to copy Tomasz' black internals notebook back at the 2007 fasmcom

No, it doesn't reprocess anything. Each thing is processed once only. The expansion will process the things that are not backslashed and not process anything else. Subsequent backslashed things are processed later. So everything is processed only once, but at different times. So it is never reprocessed, just delayed until later.

;<--- step1 starts at beginning of input
foobar:
macro macro_level2 arg2 {
 push arg2
   call foobar
}
macro macro_level1 [arg] {
reverse
 match any, arg \{
             mov eax, any
                macro_level2 any
            mov ebx, eax \}
}
insertion_point:
macro_level1 0x10, 0x20      ; <--- causes instantiation
;***> input below not processed by step 1
after_instantiation:
  ret    

insertion_point:
;<--- step 2, preprocessor continues here.
match any, 0x20 {             ; <--- causes instantiation
      mov eax, any
        macro_level2 any
    mov ebx, eax }
;***> input below not processed by step 2
match any, 0x10 {
       mov eax, any
        macro_level2 any
    mov ebx, eax }
;---> step 1 generated code above this line, and didn't touch/see anything below
after_instantiation:
     ret    

insertion_point:
;<--- step 3, preprocessor continues here
     mov eax, 0x20           ; <--- (re-)processed but doesn't trigger anything
      macro_level2 0x20       ; <--- causes instantiation
;***> input below not processed by step 3
      mov ebx, eax
;---> step 2 generated code above this line, and didn't touch/see anything below
match any, 0x10 {
      mov eax, any
        macro_level2 any
    mov ebx, eax }
after_instantiation:
     ret    

insertion_point:
   mov eax, 0x20
;<--- step 4, preprocessor continues here
       push 0x20
   call foobar
;---> step 3 generated code above this line, and didn't touch/see anything below
 mov ebx, eax    
match any, 0x10 {              ; <--- causes instantiation
      mov eax, any
        macro_level2 any 
   mov ebx, eax }
;***> input below not processed by step 4
after_instantiation:
     ret    

insertion_point:
      mov eax, 0x20
       push 0x20
   call foobar
 mov ebx, eax
;<--- step 5, preprocessor continues here
        mov     eax, 0x10
   macro_level2 0x10       ; <--- causes instantiation
;***> input below not processed by step 5
      mov ebx, eax
;---> step 4 generated code above this line, and didn't touch/see anything below
after_instantiation:
    ret    

insertion_point:
   mov eax, 0x20
       push 0x20
   call foobar
 mov ebx, eax
        mov     eax, 0x10
;<--- step 6, preprocessor continues here
   push 0x10
   call foobar
;---> step 5 generated code above this line, and didn't touch/see anything below
 mov ebx, eax
after_instantiation:
    ret    

Maybe this is just a semantics thing, but I do feel it is an important distinction that does not qualify it for being called multi-pass.

Tomasz likes to implement changes in his own way. Even my while submission was rewritten by Tomasz before he included it into "his" source. Nothing wrong with that but it does show that even if you write a complete solution that Tomasz would likely want to spend time to make it his own before including it.

Microsoft (R) COFF/PE Dumper Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file HAL.DLL

File Type: DLL

  Section contains the following exports for HAL.dll

    00000000 characteristics
    41107628 time date stamp Wed Aug 04 08:37:44 2004
        0.00 version
           1 ordinal base
          92 number of functions
          92 number of names

    ordinal hint RVA      name

          1    0 00002744 ExAcquireFastMutex = @ExAcquireFastMutex@4
          2    1 00002778 ExReleaseFastMutex = @ExReleaseFastMutex@4
          3    2 000027A0 ExTryToAcquireFastMutex = @ExTryToAcquireFastMutex@4
         20    3 000074C6 HalAcquireDisplayOwnership = _HalAcquireDisplayOwnership@4
         21    4 00006B7C HalAdjustResourceList = @HalSystemVectorDispatchEntry@12
         22    5 0001D564 HalAllProcessorsStarted = _HalAllProcessorsStarted@0    

Dump of file hal.lib

File Type: LIBRARY

     Exports

       ordinal    name

                  @ExAcquireFastMutex@4
                  @ExReleaseFastMutex@4
                  @ExTryToAcquireFastMutex@4
                  @HalClearSoftwareInterrupt@4
                  @HalRequestSoftwareInterrupt@4
                  @HalSystemVectorDispatchEntry@12
                  @KeAcquireInStackQueuedSpinLock@8    

f0dder: Your description above is really good. And best of all I think it is correct also.

You are now the forum's resident expert on macros.

With unused extrns
20:32:58,98 20:32:59,34 36 
20:32:59,34 20:32:59,70 36 
20:32:59,71 20:33:00,06 35 
20:33:00,07 20:33:00,42 35 
20:33:00,43 20:33:00,79 36 
20:33:00,81 20:33:01,15 34 
20:33:01,17 20:33:01,51 34 
20:33:01,53 20:33:01,93 40 
20:33:01,95 20:33:02,29 34 
20:33:02,31 20:33:02,65 34 
Only used extrns
20:33:02,70 20:33:02,75 5 
20:33:02,75 20:33:02,78 3 
20:33:02,79 20:33:02,82 3 
20:33:02,84 20:33:02,87 3 
20:33:02,89 20:33:02,92 3 
20:33:02,93 20:33:02,96 3 
20:33:02,98 20:33:03,01 3 
20:33:03,03 20:33:03,06 3 
20:33:03,06 20:33:03,10 4 
20:33:03,10 20:33:03,14 4     

It's just a rule of thumb: eliminate unnecessary things early, you don't know how they will affect later.

; only the first use causes EXTRN definition
macro __imp_ n {
       match =n,n \{
         display '__imp_' # `n,13,10
               extrn __imp_\#n :QWORD
         n equ __imp_\#n
    \}
    call [n]
}