[sv-cc] Type conversion for open arrays

Arnab, I again appear to have a different point of view. Rather than having the intermediate form representation figure out how to connect to each language, I see the real language implementations having to figure out how to connect to the intermediate form. I'm not trying to be funny in saying that. It's a real distinction. The intermediate form representation needs to stand on its own - and you're probably tired of hearing me say this - independently of the form, existence, or presence of any of the communicating languages.

Vitaly and I wrestled with the terminology about the "intermediate layer" for a month or so earlier this year, and my understanding is that the "intermediate layer" itself consists of several cooperating parts. There is the language-independent layer - the export and import declarations, as well as the implementation of any shared definitions such as DPI_OO::LanguageT and DPI_OO::ProxyT - and now perhaps DPI_OO::OpenArray<T>. Then for each language, there is an internal layer that maps between the objects of that language and the objects of the language-independent layer. It gets tricky here. For example, although the function f1 gets declared in the language-independent layer, its implementation in terms of the exporting language's "f1" is handled by the exporting language's language-specific intermediate layer. On the importing language side (SystemVerilog, for example), there's another language-specific intermediate layer that maps the SystemVerilog call to its imported "f1" to a call to the "f1" declared in the language-independent part of the intermediate layer. The connection to the exporting language's implementation of the f1 as declared by the language-independent layer happens when, say, the shared object libraries are loaded.

So we have not tried to specify how that mapping occurs. But in order to allow for a single common interface among multiple languages, we have specifically tried to put a language-independent interface in the middle. And if we support DPI_OO::OpenArray<T>, we would like its implementation also to be part of the language-independent part of the intermediate layer.

Regards,
Jim Vellenga

From: Saha, Arnab [mailto:arnab_saha@mentor.com]
Sent: Saturday, 24 Sep 2011 5:24 PM
To: Jim Vellenga
Cc: sv-cc@eda.org
Subject: RE: Container class for open arrays

Hi Jim,

<snip>
Thanks
Arnab

________________________________
From: Jim Vellenga [mailto:vellenga@cadence.com]
Sent: Fri 9/23/2011 8:26 AM
To: Saha, Arnab
Cc: sv-cc@eda.org
Subject: RE: Container class for open arrays
Arnab,

<snip>

-- The examples do not distinguish between the C++ intermediate layer and C++ as another language. I'll admit that, since the foreign language is responsible for implementing the subroutines and methods that SystemVerilog imports, this would be a possible implementation when C++ is the foreign language. But we also need to provide explicitly for the case where the other language is using its own native types for arrays. For example, a C++ application might be exporting a function that uses STL vectors as arguments instead of openArrays. Or a SystemC application may want to export a function with an argument declared as "sc_in<sc_uint<2> > a[4]". The C++ intermediate layer function should then be responsible for obtaining a vector made up of contents of the foreign language array and then passing the address of the pointer back to the importing language -- in this example, SystemVerilog.

ARNAB: Whatever we choose at the interface, the same issue needs to be solved. I think this is orthogonal to what we choose to represent open arrays as long as it can be converted to one of the other supported forms. For example, if open arrays are represented as std::vector<>, it still needs to handle the SystemC type sc_in<sc_uint<2> > a[4]. Also, how would the intermediate layer know what the representation is in the foreign language ? Will that be done by some kind of pragma. I didn't see anything in the proposal regarding that.
<snip>

Regards,
Jim Vellenga

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