Re: [sv-ec] Alternate Class Proposal Version 1.1

Subject: Re: [sv-ec] Alternate Class Proposal Version 1.1
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Fri Mar 14 2003 - 12:11:23 PST



Arturo Salz wrote:
Attached is an analysis and critique of the alternate class proposal.

Contrary to Jay's comments, the alternate proposal does create
explicit and arbitrary unsafe pointers. This, I'm sure, was not an
attempt to mislead but an honest oversight.

    Arturo

.....
Proposal Review
What the alternate proposal essentially entails is that users will have two schemes for class instance creation:
1. Static object, like top-level instances in C++.
2. Dynamic objects accessed though a reference.
In the proposal, static objects are the default, and dynamic objects are made more cumbersome by the requirement of an additional keyword: ref. We contend that the dynamic case is more common and should thus be given more importance.

You could use the same syntax as C/C++ i.e. '*' instead of 'ref' if you don't like typing, but since almost
every typing shortcut I have suggested has been shot down I'll assume people really don't object that much
to typing more. In C/C++ programming I use static struct and class declarations sufficiently frequently
that there is no benefit in making that the default syntax.

The proposal talks about references but in reality, it introduces explicit pointers (this is precisely what the proposals references are), with an explicit distinction between pointer and object access (as evidenced by the waiton- reference example). This choice introduces additional complexity and possibly confusion, since users need to make the distinction between a pointer-to-object and an object when declaring tasks and functions. Since the most common use is pass by reference then an additional keyword per parameter is necessary, or an additional typedef to declare the pointer type (as in the code examples).

It doesn't introduce explicit pointers, all it does is make you declare the references you currently have as
references not some psuedo-static object.

In the current language (and in Vera), the pointer is implicit, and there is no explicit distinction between reference and object. It is Synopsys’ view that this leads to more focus on algorithms and less emphasis on details, since users are not concerned with thinking about explicit pointers or objects.

The alternate proposal provides for the equivalent of C/C++’s address-of operator, but it does not provide a dereference operator, (C/C++s *). This leads to confusion and ambiguity when more than one level of indirection is needed, and the confusion led to the scrapping of an earlier proposal that allowed arbitrary levels of indirection. However, if a dereference operator is provided the syntax will become so much more compex.

In C++ the '&' reference mechanism doesn't require a special derefence operator, this is much the same. If
you feel it's confusing maybe you can give an example of how?
...

Although we have already discussed why unification of struct and class is neither desirable nor warranted, we take strong issue with the assertion that the language needs to unify not just struct and class, but union as well. If this is allowed to happen, then the strongly typed class system, which has been carefully crafted as to avoid the most common memory pitfalls that befall C/C++, will be utterly destroyed. Users will be able to (perhaps unwittingly) cast one pointer to another and either get bogus results or crash with some memory violation, and, the tool will be unable to provide any assistance.

There isn't any difference between a struct and a class in C++ other than the class has methods, there is no
reason why that shouldn't be true for SV. The casting mechanisms in SV are not the same as C so your
suggestion that anything will be "utterly destroyed" is specious.
Conclusion
The addition of classes is a powerful addition to SystemVerilog 3.1. The default dynamic nature of class declarations optimizes the most common use model and leads to a simpler and easier to use language. The type system regularity espoused by the alternate proposal comes at the expense of a much more verbose and complex language. Some of the extensions contemplated by the proposal are either ill-advised or down right impossible (at least not possible with 21st century technology). The introduction of an explicit distinction between pointers and objects creates much confusion and complexity that we believe is not worthwhile in order to achieve the blending of class objects with existing static data types. The unification is achieved, but the downside is that the most common usage becomes much more complex and hard to use.
I have no problem with the addition of classes and the object-oriented semantics, however claiming the current
syntax/semantics is optimal is a stretch.
We have also shown that the current language provides for the same semantics as static classes, but using a simpler, more general mechanism that also allows class instances to be parameterized. We also show that the existing language is at least as powerful as the alternate proposal, but with less confusion and complexity.Finally, as mentioned at the start, the alternate proposal does not attempt to solve a semantic deficiency in the language, nor does it state a problem that cannot be solved with the current class mechanism. It merely attempts to unify several constructs that we feel are best as they are, otherwise ease-of use, performance, and robustness will all be adversely affected.

The semantic deficiency is that it is particularly hard to analyize the code and determine that a class instance
is a permanent object - that will make it particularly hard to synthesize. Compilers can definitely do a better
job on optimizing static objects too since you lose a level of indirection.  The alternate proposal offers semantics
more in line with C++ which users are more likely to be familiar with since it is a pre-existing language which is
taught to many students.

Opinion:

As Jay says sticking with the current syntax will preclude a number of useful extensions and makes some
usage extremely difficult. However, those deficiencies can be circumvented by extending module syntax/semantics
to do the same as classes wrt inheritance etc., so I suspect in the long term the current class syntax/semantic will be depracated in favor of an extended module syntax/semantic -  it'll just take a lot more work to get there.

Kev.
-- 
National Semiconductor, Tel: (408) 721 3251
2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090

This archive was generated by hypermail 2b28 : Fri Mar 14 2003 - 12:13:05 PST