RE: [sv-bc] void casting on void function call

We also have

for_step_assignment ::=
    operator_assignment
  | inc_or_dec_expression
  | function_subroutine_call 

But for_step_assignment is also a statement.
So I guess only functions calls of void functions are allowed there?

Shalom


> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gordon Vreugdenhil
> Sent: Thursday, August 30, 2007 10:44 PM
> To: Brad Pierce
> Cc: sv-bc
> Subject: Re: [sv-bc] void casting on void function call
> 
> Brad, this  is I think one of those "semantic" prefixes in 
> the grammar (otherwise why not just use "subroutine_call").
> Similar to all the ..._identifier variations.  That is why I 
> responded with the interpretation that I did.
> 
> If you think that all variations of "subroutine_call" are 
> legal, then you believe that task_call is also Ok?  If that 
> is Ok, then let's just change "function_subroutine_call"
> to "subroutine_call" in this context and be done.  I'm Ok with that.
> 
> Gord
> 
> 
> 
> Brad Pierce wrote:
> >> "function_subroutine_call" isn't a system_tf_call
> > 
> > According to A.8.2 --
> > 
> >    function_subroutine_call --> subroutine_call --> system_tf_call
> > 
> > -- Brad
> > 
> > -----Original Message-----
> > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of 
> > Gordon Vreugdenhil
> > Sent: Thursday, August 30, 2007 8:28 AM
> > To: Surya Pratik Saha
> > Cc: sv-bc@eda-stds.org
> > Subject: Re: [sv-bc] void casting on void function call
> > 
> > 
> > The question is whether the intent of "function_subroutine_call"
> > is restricted to "function's that are expressions".  There 
> is no real 
> > reason to make that restriction; C for example allows void casts of 
> > void functions as well.
> > 
> > If you want to argue this too narrowly, you'll argue 
> yourself into a 
> > bigger problem -- grammatically "function_subroutine_call"
> > is any call (including a task).  The semantic intent is in the 
> > "function" prefix.  But "function_subroutine_call" isn't a 
> > system_tf_call so one could argue that void'($bits(x)) 
> would be illegal.
> > Clearly that isn't the intent once you consider all the 
> systf file I/O 
> > cases where one wants to through away return codes.
> > 
> > I don't see any reason to not interpret this in the most permissive 
> > way possible.  I'd even support allowing (at least) systf 
> task calls 
> > since that would be a great way for real user code to insulate 
> > themselves against possible variations in vendor implementations 
> > and/or LRM versions.  A great example of that is with "$system" for 
> > which there is variation in implementation.  Allowing a 
> systask call 
> > in a void cast would allow user code to have:
> >      void'($system("..."));
> > as completely portable code even among different vendors.
> > 
> > Gord
> > 
> > Surya Pratik Saha wrote:
> >> Hi,
> >> As per LRM-BNF, void casted statment is:
> >>
> >> *Subroutine_call_statement ::= subroutine_call;
> >> | void'(function_subroutine_call);*
> >>
> >> And for void function, LRM mentions following text (page 
> no. 156 of 
> >> IEEE 1800).
> >>
> >> *Function calls are expressions unless of type void, which are
> > statements:
> >> a = b + myfunc1(c, d); //call myfunc1 (defined above) as an 
> >> expression
> > 
> >> myprint(a); //call myprint (defined below) as a statement function 
> >> void myprint (int a); ...
> >> endfunction
> >>
> >> *Can **function_subroutine_call **contain void function 
> call? I don't 
> >> think so, as void function call is a statement. But some 
> simulators 
> >> don't think like that and passes the following case:
> >>
> >> module top;
> >>     initial begin
> >>         void'(f());
> >>     end
> >>     function void f;
> >>         return ;
> >>     endfunction
> >> endmodule
> >>
> >> Any expert comment?
> >>
> >> --
> >> Regards
> >> Surya
> >>
> >>
> >> --
> >> This message has been scanned for viruses and dangerous content by
> >> *MailScanner* <http://www.mailscanner.info/>, and is 
> believed to be 
> >> clean.
> > 
> > --
> > --------------------------------------------------------------------
> > Gordon Vreugdenhil                                503-685-0808
> > Model Technology (Mentor Graphics)                gordonv@model.com
> > 
> > 
> 
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
> 
> -- 
> 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.