Subject: $sv-ec Re: action items from Tuesday meeting
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Tue Sep 24 2002 - 12:12:46 PDT
The answers to Erich's questions are interspersed below.
-------------------------------------------------------
1. Is $cast_assign bi-directional? (I.e, can it convert either from enum to int, or vice versa)?
If not, why not?
This is a good point. $cast_assign is and should be bi-directional; it converts from integer
to enum and vice-versa.
2. Why is the casting (apparently) done only on assignment? It should be possible to convert an
enum to an integer in a subexpression, use the integer in a computation, and convert the result back
to an enum value before any assignment occurs. It should also be possible to convert in an
expression being passed as a parameter, not just in assignments.
Enum values are auto-casted into integral types so no casting is needed for this type of conversion.
A cast is only needed when assigning an arbitrary expression to an enumerated type, which is what
the $cast_assign function enables.
To allow in-line expression casting, one might think about extending SystemVerilog's cast operator
to include enums and classes. But, doing so might obscure the fact that the cast is a dynamic cast
operation that is not guaranteed to succeed (i.e., cause a run-time violation). Even if one were to
provide such a cast operator, it is still valuable to have a cast function that can check if the cast will
succeed (see the example below in question 4).
When creating $cast_assign, the language designers followed the following guidelines:
1) It's important to make a distinction between static and dynamic casts
2) The CHECK variant of the cast function is necessary
3) There should be only one way to perform a dynamic cast
3. Is pass-by-reference or pass-by-value always controlled by the user? Or is the tool free to
select one or the other (e.g., depending upon the characteristics of the data type)? Whatever the
answer is, what is the rationale for the decision?
Pass-by-reference or pass-by-value is under user control.
The rationale for this is straightforward: users get the parameter passing semantics they want,
allowing them to make their own algorithmic choices, and space-time tradeoffs.
However, the language does not disallow compiler optimizations that change the passing mode,
provided that the semantics are unchanged. For example, the compiler might note that an array
passed by value is only being read by the function and thus choose to pass the array by reference.
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, CHECK ) ) begin // user can check at run-time
d = new;
end
5. Are mailboxes - i.e., FIFOs - accessible strictly in-order? If so, is that generally
sufficient?
Mailboxes are accessed strictly in FIFO order. FIFO access is sufficient for queues, which are
the most common type of message passing object. However, users may combine Mailboxes,
Lists, Arrays, and Objects (all of these are part of the donation) to create any arbitrary access
form that their problem requires: LIFO, random, etc..
This archive was generated by hypermail 2b28 : Tue Sep 24 2002 - 12:09:22 PDT