Re: [sv-bc] Possible SV macro expansion algorithm

From: Coffin, Eric <eric_coffin_at_.....>
Date: Tue Nov 20 2007 - 16:26:33 PST

Embedded comments start with [ecoffin:]

Greg Jaxon wrote:

Hi Eric,

Coffin, Eric wrote:
  

... the ASCII representation of [macro] expansion is less important
than the fact that it is merely [a sequence of] tokens.
    

The ASCII representation is only significant due to the `" feature that
captures macro argument text as the data of a string literal.
  

[ecoffin:]  The ASCII/non-ASCII representation has greater significance then just the `" feature.  The ongoing dialog about white space (what is it, when to trim it, what function it has) comes into play.  For example, the LRM states (1800/D4 section 5.6.1) that for an escaped identifiers the trailing white space is not a part of the identifier itself.  Knowing how to treat white space and how to represent an escaped identifier in a macro expansion are important.  Consider the following trio of macros and their usage.  What are reasonable expansions?

`define escapedIdent \Tuesday
`define variant_A `"Tuesday`"
`define variant_B `"`escapedIdent`"
string S1 = `variant_A;
string S2 = `variant_B;

Most likely SV users would agree that S1's initializer is "Tuesday", but what about S2's initializer?  Should it be "Tuesday", "\Tuesday ", "\Tuesday", or a macro expansion error?  The answer depends upon if you treat the macro bodies as ASCII, and thus maintain the escaped identifier's leading slash and trailing whitespace, or if you treat the macro bodies as lists of tokens.

C++ treats macro expansion as a text-to-token transformation.
    

Is your proposal (below) different from C++ pre-processing in
any major respect?
  

[ecoffin:] I tried to follow C++'s treatment of macro expansion as closely as I could.

In the "... looking for identifiers matching formal argument names"
activity, there is an implied tokenization of the unexpanded body.
We need to specify the rules for that tokenization, in particular
whether escaped identifiers are to be recognized.

On first review, though, this looks a lot better than the existing
section (23.2 of 1800-2005)!

Greg


  

*********************************************************************

Here is a rough outline of a possible way to expand macros that might
give some
consistency to the various SV implementations out there.

Order of actions to expand a macro:

 - After the macro use has been identified in the SV source text,
   gather the use's actual arguments.

 - Independently expand all actual arguments, but do not substitute
   them into the macro body.  If the macro use did not specify an
   actual and a default value was specified then expand the default
   text.  Some SV implementations first expand and then substitute,
   while others do not.  Note that all arguments should be expanded
   even if they are not used within the macro body.

 - Walk through the macro body looking for identifiers matching
   formal argument names.  Replace any macro formal argument with its
   expanded actual text, unless the macro formal is adjacent to a
   tick-tick ('').  If the formal arg is next to a tick-tick, then
   literally substitute the (unexpanded) actual text for the formal arg.

 - do {
     - Perform token-pasting upon the expansion's body.  Token
       pasting should have no effect upon the `" and the `\`" macro
       operators.  Furthermore, token pasting ignores any white space,
       and will not paste comments, nor paste across comments.
     - Rescan the resulting body for any more macros to expand.
       Expand them.  Do not expand `" or `\`".
     } while the expansion body changes

 - Expand the special macro-operators, tick-quote `" and
tick-slash-tick-quote `\`"

-Eric






    

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Tue Nov 20 16:26:51 2007