Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#175 %deftok extension: parameters to specify which tokens to get

open
nobody
5
2010-09-07
2010-09-07
C. Masloch
No

%deftok currently accepts a macro name for the target as well as a string to convert. I would like it to accept more parameters to specify which tokens should be used, similar to the parameters to %substr. %deftok with only two parameters would work like the current %deftok then. This should include a directive like %strlen to %substr named, for example, %toknum, that assigns the number of tokens in the input string to a single-line macro.

Discussion

  • H. Peter Anvin
    H. Peter Anvin
    2010-09-09

    I think we'd need much more of an idea about the use case.

     
  • C. Masloch
    C. Masloch
    2010-09-09

    The specific case that I'd want to use it for is this: I have a macro that replaces some of the jump instructions (so that, for example, the instruction "jnz label" would call the macro). I want to display a warning if NASM automatically generated the (non-386) near conditional jump (i.e. the replacement sequence "jz $+5", "jmp near label"). If the user knows that this jump needs to generate the replacement sequence, he should be able to shut the warning up by calling the macro like "jnz near label". Currently, I would use %defstr on %1 to get the string (here "near label") and search for blanks inside the created smac using %strlen, %rep and %substr (and some more smacs). If a blank was found, I would then extract the first "token" with %substr into yet another smac then use %ifidni to check whether it's the "near" keyword. This would be considerably easier if I could use %deftok for tokenization instead of searching through the string myself, but currently that just returns the same string I started with (i.e. "near label" (assuming the current %deftok reversal bug will be fixed) ).

    There are probably other uses for this, and in this specific case maybe I should just drop the macro altogether and implement the warning in the NASM source code which is a lot easier anyway. This was just the case which got me thinking about using NASM's tokenization in macros.