Subject: Re: [sv-cc] SV-CC LRM - array of strings
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Wed Apr 16 2003 - 14:06:21 PDT
Francoise,
My point was that the implementation of array of strings passed as an argument
is inherently inefficient and would likely lead to memory leaks.
> I reread the string section and I don't think of it like a class.
Are SV strings allowed in structures or arrays?
> The only which makes it look
> like a class is that they have methods to get the string length, its value
> etc...
> Vera may have implemented it as a class, but there is nothing in the
> specification that suggest that all implementations do it this way.
>
> I think we are still okay in supporting string types and array of strings.
> It may be
> very inefficient in the current Vera/SV implementation if you
> have to do string copies to pass it to C but I don't think there is
> anything in the standard which would prevent DPI from supporting the string
> SV type.
> The only differences I see is that a C string will be null terminated while
> a SV string is not
> and SV strings are dynamically allocated as needed.
>
> Francoise
Forget all existing implementations of Vera/SV. Let's stick to the sheer
language definition.
SV strings have to be represented differently than C strings.
Therefore a representation change is needed when passing a string in either
direction, and it will involve a dynamic memory allocation.
This is exactly what I want to avoid. Although this is tolerable for a single
value, it will be much more expensive for an array (allocate array, allocate and
copy all strings, transfer control, deallocate all strings, deallocate array).
I think that from the interface point of view, the original solution with
an opaque string pointer (i.e. a dedicated type 'string' or 'cstring',
whatever) was better. This is very similar to arrays of generic pointers
('handle'); such an array can be efficiently passed by reference with no
overhead.
Somehow none of us has looked closer at passing strings in their current
SV meaning. We cannot define a mapping between the two representations.
For 'cstring' it would be simple: cstring <--> char*.
What is the mapping for SV string in C?
If strings are not allowed in structs or arrays, the mapping is irrelevant
and char* could be used. If they are permitted in structs/arrays, then we have
a problem.
Therefore, even if we accept the overhead of the representation change,
can we support SV strings for exported functions?
If a code for a function call is generated by SV compiler, then, of course,
the compiler knows the representation of SV strings. But what about calls
from C?
Consider the following SV snippet:
export "DPI" function foo;
function void foo(input string in_str[5], output string out_str[5]) ...
What would be the C header for this function? Possibly a wrapper function
could provide a conversion ...
Andrzej
'
> At 02:01 PM 4/15/2003 -0400, Andrzej Litwiniuk wrote:
> >Team,
> >
> >
> >We have another problem, I'm afraid, resulting from the changes in SV 3.0 made
> >by other committees. Do we want to permit arrays of strings?
> >
> >I was asked the following question by a person doing the review of the
> >document
> >for SV-CC:
> >
> > > one comment I have is how I would interface from SV, to a C function whose
> > > prototype was
> > > int f (char *argc[], int argv);
> > >
> > > as far as I could see in the document, a string (in SV) would become a
> > > char* (in C)
> > > but how would I get to *char[], it is almost like an array of strings
> > in SV.
> >
> >A natural answer seemed to be "an open array of strings", i.e. something like
> >this (in SV): import "DPI" function int f (string argc[], int argv);
> >
> >Then I realized that the current semantics of 'string' differs from the
> >semantics assumed both in DirectC donation and in "17 items proposal".
> >The type 'string' was originally intended to be very similar to a generic
> >opaque pointer, with the sole difference that string literals, like "a text",
> >would be interpreted as C-style char* pointers rather than as ASCII-based
> >encoding of bit vectors.
> >
> >Now, after all additions to SV 3.0, string is a class rather than a C -style
> >pointer. As a consequence, passing 'string' type argument requires that
> >additional conversion will be performed; either a pointer must be extracted
> >from a class object (and perhaps the actual string copied), or a new class
> >instance be created with a copy of a string. Although this may be tolerable
> >for individual values of type string crossing the interface, it defies
> >the assumption that there will be no intrinsic overhead.
> >
> >Consider now an array of strings. Passing such an array would require
> >pretty expensive translation.
> >An array of strings will have different representations on both sides
> >of an interface, hence it takes a translation: for the whole array and for
> >each of its elements.
> >A new array would have to be allocated and filled
> >with pointers to newly allocated objects, be they class instances or copies of
> >C strings.
> >Situation is even worse, because memory will have to be dynamically allocated
> >and hence memory leaks will be very likely.
> >All those issues were absent with the original proposal (all strings would
> >have
> >been allocated statically by a compiler).
> >
> >IMO the solution is to keep a special flavour of a generic pointer ment
> >for strings as a separate basic type. So there would be two variants of opaque
> >pointers: 'handle' and 'cstring' (the actual name doesn't matter.)
> >Actually, what I'm proposing here is a reversion to the original solution.
> >You see, language definition is not a random collection of constructs, that
> >could be mixed and matched at will :-)
> >
> >Note that classes are not supported in DPI, hence 'string' would not be
> >permitted either. However, a conversion between a single object of class
> >string
> >and a single value of type 'cstring' would be supported.
> >Therefore it would be possible to use an actual argument of type string (for
> >all directions) for the formal argument of type 'cstring'.
> >An array of 'string' would not match, however, an array of 'cstring'.
> >
> >
> >Thanks,
> >Andrzej
>
This archive was generated by hypermail 2b28 : Wed Apr 16 2003 - 14:07:34 PDT