Re: [sv-bc] Re: [sv-ec] $typename issues

Another option is to remove $typename from the LRM.  (Vendors could
still provide it if they wished.)  What was the original requirement
that motivated standardizing $typename?  Is that requirement still
considered a requirement?  If so, is there a better way to satisfy the
requirement?

See also --

    http://www.eda-stds.org/sv-bc/hm/4620.html

An integer type cannot be distinguished from a packed array type with
$dimensions() or with the type() operator, but can be distinguished with
$typename().

-- Brad

-----Original Message-----
From: owner-sv-bc@eda-stds.org [mailto:owner-sv-bc@eda-stds.org] On
Behalf Of Gordon Vreugdenhil
Sent: Thursday, June 22, 2006 10:31 AM
To: Rich, Dave; SV_BC List; SV_EC List
Subject: [sv-bc] Re: [sv-ec] $typename issues


Dave,

In general none of this is all that hard to make decisions about
but I want to make sure we're addressing all the issues in a consistent
manner starting with basic questions of "how well defined does
this need to be".

In particular, there are obvious answers to things like
associative and dynamic arrays as you noted.  I raised those just
to note that the rules given are incomplete, not that all the
issues are hard.

A few specific comments on your responses are below.

Rich, Dave wrote:

 >>    6) Are type parameters named by the type parameter?  Are they
 >> structurally
 >>       expanded?  If I have:
 >>          typedef struct { int a; } T1;
 >>          typedef T1 T2;
 >>       Does $typename(T2) yield "T1" or the struct form of T1?

 > [DR>] The struct form of T1. This is what 22.2 a) says


But look at the example in 22.2.  It includes both the struct
expansion and the name.

   module top;
      typedef struct {node A,B;} AB_t;
      AB_t AB[10]; // "struct{bit A;bit B;}top.AB_t$[0:9]"

Why is "AB_t" part of the name here?

It appears that the example is doing *both* struct
expansion and name representation.

I would have expected either:
     top.AB_t$[0:9]
or
     struct{bit A;bit B;}$[0:9]
but not both.

If I have:
     typedef AB_t AB_t_2;
     AB_t_2 AB[10];
What would I get?

Based on the example, I would expect to get:
     struct{bit A;bit B;}top.AB_t_2$[0:9]
but I don't have a set of rules to base that on.


>>     9) Class types are not addressed.  Are they printed just by name
or
>>        as in an expanded "struct" like form?
> 
> [DR>] I think just by name would be sufficient. In fact, the same
should 
> be sufficient for unpacked structs and enums. There's no need to
include 
> their contents. That would make a lot of this much simpler.

That certainly makes a class inconsistent with struct and raises
issues with aliasing types.  If I have:
    typedef C C1;
    typedef C C2;
or pass "C" through to a type parameter called "C_param" then do I
have three distinct typenames?  If you are supposed to get "C"
in each case then there needs to be special rules for what to
do with classes.

I think that the answer for classes should be that the typename
should be the typename of the actual class type at its definition point.
This still poses some issues for specializations, but those
have some relationship to %m.


>>    10) Self-referential class types are not addressed.  If classes
are
>>  printed
>>        in expanded form, self-referential types have an infinite
print
>>  form.
> 
> [DR>] A good reason for not expanding them

Exactly.  But the obviousness of this answer does open the question to
the issues of naming via typedefs, etc.

This also means that one would need to independently know the
name of members in order to get a "full" representation of the
class.

It may be more useful to have classes expand but that any references
to types in this expansion get replaced by names.  This would, I
think, produce the "best" balance between visibility and not falling
into type reference loops.


>>    11) In terms of specializations, do you get the name of the
location of
>>  the
>>        specialization or a name that is unique to the specialized
type?
>>        example:
>>            C #(1) c_1;
>>            C #(1) c_2;
> 
>>        Is it true/not true that $typename(c_1) == $typename(c_2) ?

You didn't address this part.  My hope/expectation would be that
the names are the same.  My suggestion of using the point of
definition of the type would apply here.  Since each C#(1)
is, in some senses, an alias to *the unique* specialized type,
the name of that specialized type should be the answer here.
I would not want the names for each of these to be different
generated names; the name of the unique specialization would
need to be generated in some manner but each specialization
should not generate a new name.

That means that given:
     typedef C#(1) local_name;
     C #(1) c_1;

It should be the case (in my opinion) that  $typename(local_name)
should be the same as $typename(c_1).


>>    12) Are matching types supposed to have the same string?  I.e. if
two
>>  types
>>        match, is one guaranteed that the $typename form is identical?
> 
> [DR>] The LRM says yes, with the exception of the builtin fixed sized
types.


No it doesn't say this.  It says:

   This process is similar to the way that type matching (see 6.9.1) is
computed,
   except that simple bit vectors types with predefined widths are
distinguished
   from those with user-defined widths. Thus $typename can be used in
string comparisons
   for stricter type comparison of arrays than with type references.

The implications of various parts of this are that you can get
different strings for matching types.  For example:

   package p1;
      bit[3:0] a;
   endpackage

   package p2;
      bit[3:0] a;
      typedef
   endpackage

   $typename(p1::a) == p1::bit[3:0]
   $typename(p2::a) == p2::bit[3:0]

The types clearly match but the type names do not.

I agree that if the type is equivalent to a predefined name
that you'll be ok, but not for other types.

It is clear that $typename is supposed to be stronger than
equivalence.  If it is also supposed to be stronger than
matching (as this example demonstrates) then that should
be clarified.



There are numerous other holes in all of this that are related to EC
related
language features.  Again, likely not at that hard to give answers
about but the given spec is far from sufficient.

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