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

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Thu Aug 30 2007 - 12:44:20 PDT
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.
Received on Thu Aug 30 12:44:59 2007

This archive was generated by hypermail 2.1.8 : Thu Aug 30 2007 - 12:45:20 PDT