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

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Thu Aug 30 2007 - 20:28:05 PDT
It looks like you could not use there a function casted to void.
That is an observation, not a complaint.

Shalom 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce
> Sent: Thursday, August 30, 2007 11:40 PM
> To: sv-bc
> Subject: RE: [sv-bc] void casting on void function call
> 
> Yes, typically a method call, such as to next() of H.5.1.
> 
> -- Brad 
> 
> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> Sent: Thursday, August 30, 2007 1:28 PM
> To: Gordon Vreugdenhil; Brad Pierce
> Cc: sv-bc
> Subject: 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.
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Aug 30 20:28:29 2007

This archive was generated by hypermail 2.1.8 : Thu Aug 30 2007 - 20:28:58 PDT