[sv-cc] DPI-OO comments

As I noted in an earlier message, I have posted a new version of the DPI-OO document with comments on the relevant sections. In this message I wanted to summarize the key issues and difficulties I see with the existing proposal.

We believe that the ability to manipulate types and objects across the C++/SV language boundary is a valuable addition to the language. And, if such a feature can be used to provide tighter interfacing between SV and other OO languages that is a good thing, which we wholeheartedly support. These are not all the issues, but the most salient, and, in my opinion, the, most in need of resolution.

- Asymmetry between C++ and SV. Generally, a proxy class is needed in both languages: a C++ proxy that handles method calls from C++ to an export SV object, and an SV proxy to handle method calls from SV to an imported C++ object. In the first case, the actual object is an SV class hence a proxy is needed in the C++ side; in the latter case, the actual object is a C++ class and the proxy is needed in the SV side. The proposal seems to only discuss C++ proxies, which makes the whole proposal very confusing.

- The proposal requires import proxies to be derived from class DPI-OO::ProxyT, and further states that proxies can be tool generated or written by users. Hence, users that wish to import a C++ class must write a proxy and ensure it is derived from DPI::ProxyT. It is confusing to call these proxies (as they are written by users), but the requirement that they must be derived from a common base class adds a level of complexity that become a barrier to integration of C++ classes. We believe that in order for DPI-OO to be practical and useful, it must provide first and foremost a strong and simple mechanism for interfacing existing C++ classes to SV. This proposal is somewhat skewed towards providing an interface between SV and other languages, but it significantly complicates the basic SV/C++ interface.

- Memory management is not well specified. It is not clear from a user's perspective what guarantees the system must provide and what may lead to errors. There appears to be many unspecified behaviors that are not described. Likewise, it is not at all clear how an implementation manages the memory of objects that are distributed across different languages with widely different memory allocation strategies (garbage collection vs. explicit allocation). The proposal seems to imply that ProxyT maintains reference counts on a per-language basis (SV may be one of them). Presumably, the intermediate layer provides some mechanism to manage all the proxies, but it is not at all clear how this mechanism determines when an object is no longer referenced in other languages. The memory management per-language seems to add a degree of complexity that is not warranted - it seems unimportant whether a particular language has or doesn't have a reference to an object, all that matters is that no references to an import/export object remain. It is also unclear how a language that implements garbage collection can notify the intermediate layer that an object is no longer alive (it's garbage). All this is further complicated by the requirement of equivalence between objects and handles - it seems that to guarantee such equivalence some objects can never be deleted from the system. IMO, this is the most underspecified part of the proposal. Very late in Annex H, the proposal lists some methods in the ProxyT class, but how /when such methods are called by either side is a complete mystery to me - and to any user that would want to import their C++ class to SV.

- The cross-language inheritance is seems to be a very ill-conceived feature. The motivation behind it seems unclear - especially since they lead to two distinct objects in the different languages and a containment strategy would provide the same functionality - and is much easier implement. The dpi_initialize() scheme is an ugly hack for what seems to be a poorly-motivated feature and difficult for C++ users to implement.

- The use of a common base class ProxyT seems overly intrusive and restrictive implementation. We believe this will be a big barrier to implementation by both users and implementors. All the functionality proposed for the ProxyT can be provided in a non-intrusive way via associative maps that contain the mapping between handles and pointers in all the intervening languages. The tables can be updated whenever an object crosses the language boundary - likewise the callbacks to notify the death of an object does not need to be a method but a call to the object manager. The use of associative tables is a common and effective technique to extend objects. We believe that any performance loss due to the lookup is more than offset by the ease of use provided by the separation of the two concerns: the actual class implementation and the inter-language object management and registration scheme.

- The scheme for parameterized and template classes lacks scalability - requiring a post-elaboration scan of the entire SV design - and the specialization checking and error generation is not well defined. Some of the error conditions (such as missing specializations) in the C++ are generally detected by the linker or at run-time. It is not clear what are the responsibilities of a complaint SV tool.

- Copy classes can be useful but only if they are limited to the simplest types (packet or payload type of objects). The current proposal is generic and allows for copying of arbitrary data-structures, which requires detection of cycles, and may lead to high memory overhead and run-time degradation. It is also unclear whether inout copy classes are allowed, and, if they are, it is ambiguous regarding pointer/handle equivalences. Also we have a fundamental objection to copy classes being part of DPI-OO when they are in fact not an object-oriented solution - this is because it is not possible to define methods for a copy class.

- Inconsistent use of the "import class" and "export class" terminology that makes the text confusing to understand. It is unclear whether "importing class" is referring to a class that is imported into SV (as the term "import" is consistently used in DPI-C), or whether it is using the generic term to refer to a class that may imported into C++. Sometimes the intent can be gleaned from the text, but often it is hard to discern.

- There are many examples and text showing export classes (i.e., classes exported from SV to C++), but hardly any examples and descriptive text explaining import classes. Often, the normative text that applies to import classes is incomplete or just wrong.

    Arturo

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.