Re: [sv-bc] Trimming whitespace from macro actuals

Unfortunately, 1364-2005 added escaped identifiers to the set of 
permissible macro names. Thus:

   `define \anything  foo
   `define M2(anything) uwire `\anything = 1'b1;
   `M2(@@@)


could arguably yield:

   uwire foo= 1'b1;


Blech! We need to better define order of expansion if we have any hope 
of allowing the complex macros that user's want to use and have such 
code be portable.

Interestingly, the backslash in this example is probably redundant in 
either or both uses since Verilog would normally treat backslash 
followed by the word, anything, as the same identifier as the bare word, 
anything, without a leading backslash. Of course, there exists examples 
where the backslash is needed.

-randy.

Brad Pierce wrote:
> The LRM says that `\`" in a macro body yields \" after unrolling.  It
> stands to reason that `\ would yield \.  If so, I would expect
>
>    `M2(@@@)
>
> to yield
>
>     uwire \@@@ = 1'b1;
>
> -- Brad 
>
> -----Original Message-----
> From: Greg Jaxon [mailto:Jaxon@synopsys.COM] 
> Sent: Monday, October 29, 2007 11:02 AM
> To: Brad Pierce
> Cc: sv-bc@eda-stds.org
> Subject: Re: [sv-bc] Trimming whitespace from macro actuals
>
> Brad Pierce wrote:
>   
>> Is the following legal?
>>
>>    `define M(anything) uwire `\anything = 1'b1;
>>    `M2(@@@)
>>     
>
> Obviously, your `define lines are properly formed, so the question is
> how to write the expansion of your macro calll, and whether the result
> has any use in a SystemVerilog statement.
>
> Here the escaped identifier and the macro formal are nominally
> identical.
> We've claimed that they are interchangeable for most purposes.  That
> either applies in this case, or it doesn't - and the two expansions that
> we might see are therefore:
>
>    (macros of SV token stream)      `@@@= 1'b1;
>    (macros of  C token stream)      `\@@@ = 1'b1;
>
> Have I missed something that makes the leading "`" significant in the
> macro definition?
>
>   
>> How about the following?
>>
>>    `define M2(anything) uwire `\anything= 1'b1;
>>    `M2(@@@ )
>>     
>
> I just realized that I want my windows manager to have a GUI for "mark
> and diff" ;-)
>
> Here you've botched the SV token stream so it no longer refers to the
> formal, there are still two candidate expansions:
>
>    (macros of SV tokens)      `\anything= 1'b1;
>    (macros of  C tokens)      `\@@@ = 1'b1;
>
> -----------------------------------------------------
>
> SV's preprocessor departed from the C conventions so long ago, there's
> no point in mimicking it /hic et nunc/.
>
> The philosophy that we must "define" every iota of the SV preprocessor
> is a burdensome, and rather new idea.
> So far, the LRM has stated vague claims that are generally true, and
> written vanilla examples that do not test the boundaries too well.  In
> short it has "documented" what common grounds can be found, not
> prescribed a universal solution.  Is that a wise course?  I think it
> leads to teaching only the most tame uses of this feature, and not
> leaning on macros as a route to custom lexical trickery.
>
> If the committee fails to specify a swiss army preprocessor for SV, will
> the preprocessing marketplace diverge any more than if we try weakly
> playing catch up with C preprocessing
> features?   Or is HDL becoming a back-end language for far
> more advanced applications that can easily roll their own text-expansion
> conventions to suit the application's natural needs?  Shalom is studying
> Perl, he says.  There are SO MANY excellent text manipulation systems -
> is it IEEE-1800's job to add to that variety?
>
> Greg
>
>   
>>  
>> -- Brad
>>
>> -----Original Message-----
>> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of 
>> Bresticker, Shalom
>> Sent: Sunday, October 28, 2007 2:33 AM
>> To: Steven Sharp; sv-bc@eda-stds.org
>> Subject: RE: [sv-bc] Trimming whitespace from macro actuals
>>
>> Hi,
>>
>>     
>>> So we should be careful that we don't define something until we are 
>>> sure what we ultimately want to define.
>>>       
>> So far, I have not heard anyone claim that the general rules I 
>> proposed are wrong, i.e.,
>>
>> 1. Normal actual arguments have leading and trailing white space 
>> stripped off.
>> 2. Exception: an escaped identifier at the end of an actual argument 
>> should keep a white space.
>>
>> That takes care of the simple case of escaped identifiers, not 
>> involving ``.
>> Example:
>>
>> `define D(a,b) a+b
>>
>> `D(\coco , puffs)
>>
>> should give you
>>
>> \coco +puffs
>>
>> and not
>>
>> \coco+puffs
>>
>> There is a special case involving escaped identifiers around ``. That 
>> could be added subsequently as a special case which is really a 
>> question of how `` works. I don't see that it makes the general rules
>>     
> wrong.
>   
>> While it may be clear to everyone that white space is stripped off 
>> normal arguments, the behavior regarding escaped identifiers has not 
>> been universal, and therefore even the simple example I wrote above 
>> does not work in all tools (so I understood).
>>
>> If we will manage to specify a desirable behavior for the special 
>> cases before the deadline, great. That can be addition or a revision 
>> of the general rules. But let's at least the general rules passed, so 
>> that at least the simple cases will be guaranteed to work consistently
>>     
>
>   
>> in all tools.
>>
>> Shalom
>> ---------------------------------------------------------------------
>> Intel Israel (74) Limited
>>
>> This e-mail and any attachments may contain confidential material for 
>> the sole use of the intended recipient(s). Any review or distribution 
>> by others is strictly prohibited. If you are not the intended 
>> recipient, please contact the sender and delete all copies.
>>
>> --
>> This message has been scanned for viruses and dangerous content by 
>> MailScanner, and is believed to be clean.
>>
>>
>>
>>     
>
>
>   

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.