Subject: Re: DirectC: C layer
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Dec 10 2002 - 15:13:27 PST
Michael Rohleder wrote:
>
> Some very initial comments, more details will follow
> b) I don't like the include file names.
> Instead I would suggest "svc_binlevel.h" and svc_srclevel.h".
What about "svc_bin.h" and svc_src.h"?
> But this is of course just a minor problem.
Agree.
> c) We need to say something about memory handling; at least for strings.
> Who is owning the memory for a string parameter and how this has to be
> modified in case of modifications.
> [Assume you have an inout string, initialized by SV to "Andrzej", and
> I want to overwrite it with "Swapnajit", how do I handle the additional two
> characters needed for the newer string ??? Or in case I have an output string,
> who is responsible for allocating the memory ??? Or in case of an input
> parameter what is the lifetime of the corresponding data ???]
It seems to me that there is no issue of memory handling, unless the basic
committee adds some functionality for the new primitive type 'string'.
Please recall ("17 items", 12) that we don't propose any string manipulation
other than a simple passing of already existing strings.
So, in SV you may only switch between strings that already exist,
either being string literals (i.e. "text"), or created on the C side.
New strings may be created only in C.
SV type 'string' corresponds to C type 'char*'.
Therefore, while input argument will be of type 'char*' in C, the output
and inout arguments shall be of type 'char**'.
So, if an inout string, initialized by SV to "Andrzej" is overwritten with
"Swapnajit", both strings will remain intact in memory and all that changes
is the contents of a pointer.
In the case of output string, it's the C side who allocates the memory
for string.
In the case of an input parameter the lifetime of the corresponding data
is the whole program, if the actual argument is a string literal or
it will depend on the C code if that string was created in C.
Sv side will simply keep the pointer to some memory location assumed
to contain a string. Whoever allocated that piece of memory, is responsible
for it.
Sv will do just pointer joggling, nothing more.
> d) I would like to see the const being part of the mapping described for
> input parameters ... And, again, is is part of
> the linking, at least for some compilers ...
SV compiler may add 'const' for input args in the generated function headers.
Elsewhere it is user's resposibility.
I don't think a linker will be involved here, but don't let us get started
again :-)
> e) Since arrays are always starting at 0, it might be possible to map a
> function with a parameter logic [15:8] and a second function with a parameter
> logic [7:0] to a single C function
> (althought the extern definitions on the SV side are _intentionally_ different
> here). Do we want to have this, is this O.K., and what would be the
> implications ?
The syntax that we agreed upon allows for aliasing. We haven't specified
that two different external functions must not use the same C function name.
So, at the same time, we may map two formally different functions on the same
C function where it makes sense, and allow for user's mistakes.
Example:
extern "foo_8" void foo_15_8(logic [15:8]); // ok
extern "foo_8" void foo_7_0(logic [7:0]); // ok
extern "foo" void f1(int,int,int); // undetected conflict!!!
extern "foo" void f2(real,string); // undetected conflict!!!
That kind of scenarios guided me when I was proposing to normalize
the ranges; in my original proposal (as well as in VCS DirectC)
only the width mattered, not the absolute range.
So if extern function were declared as 'extern void foo_8(logic [7:0]);',
it could be called with any vector of width 8.
> At least one is that there is a need to have a function to retrieve
> the _actual_ range of an array ...
It will be possible only for open arrays, which will be passed by a handle.
> f) You need to define whether an array starts at the msb or at bit 0, if you
> are settling upon the syntax in your proposal
> (so what is the mapping between the first element on the SV side
> and the element 0 on the C side. Think about
> cases like logic [7:0] and logic [0:7])
This is really confusing.
Consider 'signed bit [7:0]' and 'signed bit [0:7]'. Which is the sign bit?
Perhaps we could resort to the old semantics of PLI avalue/bvalue?
I suppose it had to deal somehow with the ordering problem.
> g) I would like to have a function that is able to _directly_ manipulate
> a single bit of a Vector (having size > 32 bit).
> When I just want to modify a single or a few bits, I don't want to fiddle
> around with all this stuff.
Agree.
This has been adressed in the addendum ("support for bit and part selects")
that I already sent.
Andrzej
This archive was generated by hypermail 2b28 : Tue Dec 10 2002 - 15:13:58 PST