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

Gord,

The "function_" prefix was absolutely intended as a semantic constraint.

But there was never an intent to say that a system function is not a
kind of function.  That seems like a far-fetched interpretation to me,
like saying house boats are not a kind of boat.

But, if you think it necessary, we could clarify this with a footnote on
function_subroutine_call.

-- Brad

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Thursday, August 30, 2007 12: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.