Subject: Re: [sv-ec] Comments on remainder of Chapter 3
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Tue Jan 07 2003 - 11:56:52 PST
Mac,
You raise two important issues. Your concern that $cast performing an assignment
may not be obvious to Verilog users is a valid one. I don't have a better answer than
it will have to be part of the learning curve, in very much the same way as $fscanf
(albeit the C legacy).
The issue of making $cast a system task was discussed at the meeting and I believe
the consensus is that it must be a built-in operator (for much the same reasons that you
point out). One option would be to add the keyword "cast" and promote this to operator
status. Another is to designate a check and not a system task in very much the same
way as the timing checks ($setup, $hold, etc...), thus retaining the $ notation to avoid
adding a new keyword in user space.
I don't agree that $cast introduces a new way to do assignments. This type of assignment
already exists in Verilog via output parameters, and now via passing by reference.
An additional can_cast or can_assign function similar to the one you propose may be a
valuable addition, but the combination of type-check and assignment provided by $cast
is valuable and necessary. It is necessary is because the assignment "find_a_fido = m;"
is currently not a valid assignment and requires some specialized operator. It is valuable
because the assignment (if it were allowed) will have to perform a type check a second
time.
Arturo
----- Original Message -----
From: "Michael McNamara" <mac@verisity.com>
To: "Arturo Salz" <Arturo.Salz@synopsys.COM>
Cc: "Jay Lawrence" <lawrence@cadence.com>; <sv-ec@eda.org>
Sent: Monday, January 06, 2003 1:38 PM
Subject: Re: [sv-ec] Comments on remainder of Chapter 3
Arturo Salz writes:
> > 3.14 Dynamic casting
> > --------------------
> >
> > Verilog uses have enough problems with static casting, this whole
> > section seems unnecessary. I've seen this sort of programming construct
> > in environments like GUI's where a user may have typed garbage in a
> > field and you are trying to dynamically idiot proof the validation of
> > the form, but I don't see why it is needed in Verilog.
> >
> > Where are dynamic casts needed?
>
> Here's the relevant section of the message I previously sent.
> Arturo
> ----------------------------------------------------------------------
>
> 4. Why is $cast_assign required for assigning a superclass instance
> to a derived class instance - why is this not inherent in
> assignment?
>
> A derived-class can be assigned directly to any of its
> super-classes. However, a super-class can only be assigned to
> a derived class if and only if the sub-class is actually of
> that type. In general, this can only be resolved at run-time,
> thus the need for a dynamic cast. For example:
> class Animal { ... }
> class Mammal extends Animal { ... }
> class Dog extends Mammal { ... }
> class Cat extends Mammal { ... }
>
> Mammal m = new;
> Animal a = m; // correct, mammal is an animal
> Dog d = m; // error: m is not a dog
> Cat c = d; // error: d is a dog not a cat
> $cast_assign( d, m ); // allowed: triggers a run-time error
> if( ! $cast_assign( d, m ) ) begin // user can check at run-time
> d = new;
> end
So this example makes it seem like $cast_assign is analogous to c's
int isalpha(int c) family of routines (see isalpha(2)); the
$cast_assign doesn't do the cast, but instead it returns a value
indicating whether an assign would be legal. Or does executing
$cast_assign(d,m) destroy the current value of d?
I guess what makes sense to me is to follow C's lead and provide a
routine like isalpha, which is purely of an inqury basis, and have the
user then do actual the assignment in the 'normal' way, protected by
the inquiry code. Specifically, is the following the desired coding
style:
Mammal m;
Dog d;
...
m = x; // x is some sort of mammal, arriving from elsewhere.
...
d = find_a_fido(m); // Get a dog, using m if suitable
...
function Dog find_a_fido( m ) begin
// check for dog reuse opportunity
if( can_assign( find_a_fido, m ) ) begin
find_a_fido = m;
else
find_a_fido = new;
end
endfunction //
Justifications:
1) It is my understanding that in the proposal the statement 'm = x';
is still legal; hence introducing this other way to do assigments
(via '$cast_assign(m,x);') which is redundant.
2) it will be non obvious to Verilog users that $cast_assign(d,m) is an
assigment.
3) Orthagonal to whether $cast_assign does the assign, or merely
returns true or false depnding on whether the assign would be legal
is the issue that making this a system task (instead of a builtin
operator) requires us to allow users to provide their own
implementation for $cast_assign, which likely will not do what we
expect.
-mac
This archive was generated by hypermail 2b28 : Tue Jan 07 2003 - 11:57:28 PST