Re: [sv-bc] Where can $typeof() be used? Issues 224 and 277)

Brad,

The only thing that I don't really like about all this is
that an implementation is pretty much forced to treat
$typeof as a reserved "word" -- $typeof needs to be treated
in the same manner as a type identifier in terms of
lex/parse issues.  This is a bit odd in that $typeof appears
to be a system function.  This is not much worse than
constant system functions that can be used in a constant
expression (which an implementation also couldn't allow pli
to override) but in retrospect, it might have been better
to have different syntax for all of this.

Gord.


Brad Pierce wrote:

> I believe it's legal (and should be legal) to use $typeof() in a cast.
> For example, the BNF allows one to say
> 
>         $typeof(v)'(a+b)
> 
> instead
> 
>      of
> 
>         localparam type P = $typeof(v);
> 
>            P'(a+b)
> 
> Why wouldn't it be semantically legal, too?
> 
> Also, is a structure member, s.mem, considered a hierarchical reference
> here, and disallowed in $typeof()?  I don't think it should be.  Can't
> we find a term that means exactly XMR, and doesn't mean also struct
> accesss, generated names, etc.?
> 
> Finally, the BNF currently seems to disallow referring to the member
> of a struct type. It should be legal to say
> 
>            $typeof(T::mem)'(a+b)
> 
> for a struct type just as one would with a classes, instead of
> forcing circumlocutions like
> 
>         var T dummy;
>         localparam type P = $typeof(dummy.mem);
> 
>            P'(a+b)
> 
> -- Brad
> 
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of Brad
> Pierce
> Sent: Wednesday, April 13, 2005 2:51 PM
> To: sv-bc@eda.org
> Subject: [sv-bc] Where can $typeof() be used? Issues 224 and 277)
> 
> 
> An important remaining ballot issue (224 and 277) is to clarify
> where $typeof() can be used.
> 
> The Mantis issue is 619
> 
>    http://www.eda.org/svdb/bug_view_page.php?bug_id=619
> 
> Here's its text description, and attached are the two partial proposals
> from the spreadsheet --
> 
> As reported in P1800 ballot item 277, section 24.2 is unclear on where
> $typeof() can be used. I think you should be able to use it anywhere. And,
> according to the LRM
> 
>     "In all contexts, $typeof together with its argument
>     can be used in any place an elaboration constant is
>     required."
> 
> (It's not clear from this that it can be used at run-time.)
> 
> Yet I've heard it said that the LRM "calls out" the specific places where
> $typeof can be used, namely,
> 
>      "The $typeof system function returns a type derived
>       from its argument. The data type returned by the
>       $typeof system function may be used to assign or
>       override a type parameter, or in a comparison with
>       another $typeof, evaluated during elaboration."
> 
> (Again, not clear if it can be used at run-time.)
> 
> I think that sentence should be read as "For example, the data type returned
> ...", not as an exhaustive list. Otherwise, the two quoted sentences are
> inconsistent.
> 
> And interpreting that sentence as exhaustive leads to unnatural
> restrictions, too.
> 
> As reported in P1800 ballot item 224, a $typeof should be useable anywhere a
> datatype is useable. $typeof is currently limited to the following places:
> to assign or override a type parameter, or in a comparison with another
> $typeof, evaluated during elaboration.
> 
> As a result, today you can only use $typeof by copying its value into a
> parameter type such as:
> 
>    parameter type out_type = $typeof(out);
> 
> and then you can do things like
> 
>    out = out_type'( out_packed );
> 
> Examples of requested capability:
> 
>    out = $typeof(foo)’(out_packed)
> 
> and
> 
>    typedef $typeof(foo) my_type
> 
> Additional example, today we are forced to do:
> 
>    parameter type foo = $typeof(bar);
>    foo barbar;
>    assign barbar = bar;
> 
> This is inconvenient. Why not simply allow:
> 
>    $typeof(bar) barbar;
> 
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil,  Staff Engineer               503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com