Re: [sv-bc] $typename follow-up

if ($typename(foo) == $typename(type(integer)))
   // do something
else
   // do something else

Maybe the rules for type matching should distinguish between integers
and packed arrays that just look like integers?

-- Brad

-----Michael Burns writes-----
Sent: Thursday, June 22, 2006 2:37 PM

Hi Gordon,

Yeah, exact portability is a dream. Isn't it a nice one, though?

Anyways, the case I was concerned about was the one Brad raised, where 
useing $typename was the only way to distinguish between a packed array 
and an integer. I'm thinking about code like this:

if ($typename(foo) == "integer")
   // do something
else if ($typename(foo) == "packed array")
   // do something else

What I'm now having trouble doing is thinking of what foo might be; 
could it refer to a type parameter of a class:

class Foo #(type T = int);
  T foo;
...
  if ($typename(foo) == "integer")
   // do something

Kind of a hacky way to write a template, but people write nutty code 
somtimes... in any event, such code would not behave as expected if the 
typename string were different between implementations.

--Mike

Gordon Vreugdenhil wrote:
> 
> 
> Mike, thanks for the feedback.
> 
> If your goal is "100% portability", that is unlikely to ever
> be achieved since that would require a defined algorithm for
> randomization constraint solutions (which is unlikely to ever
> happen).  There are also, of course, well known places in
> the scheduling algs where there are implementation dependent
> behaviors.
> 
> It is definitely worthwhile to determine where "exact"
> compatibility is necessary.
> 
> I definitely agree that the conditions under which
> $typename(t1) == $typename(t2) holds are crucial and should
> be part of the LRM.  Do you anticipate having situations in which
> a $display (or similar) of a $typename would be compared between
> vendors?
> 
> Gord.
> 
> 
> Michael Burns wrote:
> 
>>
>> A big reason Freescale is moving to SystemVerilog is portability - we

>> want our code to work across different implementations. Perhaps 100% 
>> exact portability is not likely to be achieved in the near future,
but 
>> it should be the goal.
>>
>> There are some areas where it's not there (no standard attributes, no

>> standard coverage database format); however, this looks like one that

>> could affect simulation semantics if people are checking the type
name.
>>
>> --Mike Burns
>>
>> Gordon Vreugdenhil wrote:
>>
>>>
>>> In terms of $typename, what are the user expectations?  Do users
>>> intend/expect to have $typename produce identical strings
>>> across implementations?  If not, that might make the specification
>>> somewhat easier since only the semantic decisions need to be
>>> addressed.  If users expect $typename to yield identical strings
>>> on every implementation, the bar is considerably higher since
>>> format decisions would also need to be made precise.
>>>
>>> User feedback on this would be very helpful.  I've cc'd this
>>> to EC as well (EC only people - see the issues raised in
>>> Mantis 1511 to see the context for this question).
>>>
>>>
>>> Gord.
> 
>