To put it another way:
Macro processing is a text processing pass. It pays almost no attention
to the fact that the text it is processing happens to be Verilog code.
It does need to know a little about Verilog source tokens so that it
doesn't replace part of a token (e.g. part of a string literal). It
needs to know that parentheses are paired, so it can recognize when it
has the closing parenthesis of the macro invocation. And it needs to
know that commas inside parentheses or curly braces in its argument list
are part of a function call or concatenation, not the separators for
the macro arguments.
That is about it. Aside from that, it doesn't even need to know or care
whether its output is valid Verilog code or not. That is up to later
passes. It doesn't need to care about the meaning of the text it produces.
I expect that existing implementations of macro processing aren't
"deciding" to apply macro substitution based on the scopes where the
macro definitions and invocations appear. They aren't even aware of what
scope a macro definition or invocation appears in. They don't need to be.
They can just process it as text.
This is the normal paradigm for macro processing, and I don't expect it
to change. It is also hard to see how it could be changed in the way
you describe, without creating backward compatibility issues for the
legacy code out there.
Steven Sharp | Architect | Cadence
P: 508.459.1436 M: 774.535.4149 www.cadence.com
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Sep 7 22:20:06 2010
This archive was generated by hypermail 2.1.8 : Tue Sep 07 2010 - 22:22:58 PDT