Steven J. Dovich wrote:
>>>There have been implementations of C++ that did not use vtables,
>>>and so this particular strategy is insufficiently robust for solving
>>>the DPI data interchange problem for the universe of all possible
>>>SystemVerilog/C compiler combinations. Dealing with the universe
>>>of possible implementations is the essential business of standards
>>>work, and one of the reasons why the "de jure" standards documents
>>>are the best platform for specifying the behavior of DPI.
>>>
>>compatibility with some C++ implementations is a plus, not necessarily a
>>goal. A virtual-function (vtable) interface can be defined entirely in C
>>and would be compatible across all possible SystemVerilog/C compiler
>>combinations for a given platform.
>>
>>
>
>Then let us leave the C++ issue completely out of the discussion. Since
>you cannot presume the implementation mechanism for C++ virtual
>functions, any reference to them is mis-leading with respect to
>the point you are trying communicate.
>
>
The GNU compiler appears to be well documented, and I consider g++
compatibility a considerable plus since it would make DPI code much
easier to debug.
I'm also sure all the SystemC fans out there would like C++ compatbility.
>>My basic points are:
>>
>> Virtual functions can be used for accessing vendor specific data.
>> Virtual functions (C++ methodolgy) can be more efficient than
>> regular PLI/VPI like access for equal portability.
>> You can define how it all works in C, but if you pick a mechanism
>> that is already well defined (e.g. g++'s) you will also be able to
>> write much cleaner DPI code in C++ with at least one (freely
>> available) compiler.
>>
>>
>
>Any synergy with a particular compiler is out of scope for the
>standard, it is the perogative of the SystemVerilog implementor.
>If we describe a general mechanism that uses a virtual function
>table that can be crafted entirely in portable C code, then each
>implementor can decide how and when to make accomodations for an
>alternate language binding for C++.
>
Maybe, but I see no reason not to design a mechanism that is actually
compatible with one or more existing compilers rather than none. The
attached files work on Solaris with the GNU and Sun compilers, the
virtual functions are set up so that you can mix the object files from
the different compilers and it still works.
gcc -c vtableC.c
g++ -o vtablex vtableCC.cpp vtableC.o # substitute CC for Sun
>>If anyone has more concrete data on how vtables are used by various
>>compilers it would help me in coming up with a more broadly compatible
>>scheme.
>>
>>
>
>Please do not go down this path, I can assure you that it has never
>been acknowledged by anyone with any authority on the subject to
>be a mechanism that anyone could rely on for any portable purpose.
>You cannot base universal compatibility on a foundation that disclaims
>any notion of universality.
>
>/sjd
>
>
Maybe I'd agree if you presented some examples, but the compilers I have
at my disposal seem to be behaving in very similar ways.
BTW, do you at Cadence have any proposals for SystemC/SystemVerilog
integration?
Kev.
-- Altera Corp, 101 Innovation Drv, San Jose, CA 95134. T# (408) 544 7126
#include <stdio.h>
class test {
#ifndef __SUNPRO_CC
virtual int pad_a() {return -1;};
virtual int pad_b() {return -1;};
#endif
public:
virtual int fn_a();
virtual int fn_b();
};
int test::fn_a() {return 23;}
int test::fn_b() {return 42;}
class test2 :test { // derived class with different implementation of fn_a/b
virtual int fn_a();
virtual int fn_b();
int n;
public:
test2() {n = -42;}
};
int test2::fn_a() {return -23;}
int test2::fn_b() {return n;}
extern "C" {
void DPI(void *);
void test_DPI()
{
DPI(new test);
DPI(new test2);
}
}
#include <stdio.h>
int offset = 2;
// C Macros
typedef int (*IFN)(void *,...);
#define FN_A(h) (*((IFN *)*(void **)h)[offset+0])(h)
#define FN_B(h) (*((IFN *)*(void **)h)[offset+1])(h)
void DPI(void *h)
{
printf ("%d\n",FN_A(h));
printf ("%d\n",FN_B(h));
}
void test_DPI();
int main(int argc,char **argv)
{
test_DPI();
}
Received on Fri Oct 8 10:07:37 2004
This archive was generated by hypermail 2.1.8 : Fri Oct 08 2004 - 10:07:56 PDT