Subject: Re: DirectC: C layer
From: Francoise Martinolle (fm@cadence.com)
Date: Wed Dec 11 2002 - 08:38:54 PST
At 06:13 PM 12/10/2002 -0500, Andrzej Litwiniuk wrote:
>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 :-)
I have read this conversation about the const type qualifier and I want to
state what I know about it. Hopefully this will clear any confusion...
The const qualifier tells the compiler that the value is only readable and
cannot
be changed. The compiler will generate specific code accordingly.
If proper prototypes are provided containing the const keyword, the compiler
will diagnose the linkage errors. I found this information in my C book.
It says in there explicitly that the language rules for const can be
bypassed for example
by passing the address of a constant object to an external function without
a prototype.
C compiler implementations may allocated static objects of const qualifier
types
in readonly storage, so that if someone attempts to update the const object,
that could cause runtime errors.
> > 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!!!
Andrzej,
we could have the SV compiler checks all the externs and warn/error about
these conflicts
>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.
>
I agree with this, let's not invent something different.
> > 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 : Wed Dec 11 2002 - 08:39:42 PST