Subject: Re: DirectC: C layer
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Wed Dec 11 2002 - 02:47:41 PST
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"?
Fine with me. Background: Although I honor the heritage of this interface, the above names would be much more descriptive.
> > 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'.
Mostly yes ...
> 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.
a) we should clearly say this in the LRM for the C side as well, otherwise many people will try to do string manipulations
b) When I want to pass a string from the C side, I still need to now about memory (do I need to create it on the heap, and what is
the lifetime and who is responsible for freeing it -- the C side can hardly do this ...)
> 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.
Yes, when "Swapnajit" comes also from the SV side. When I have to create this in C, how this needs to be done ??? You can hardly
request that the C side also just has const strings here (I might want to build my string in the C side). And who is then
responsible for the string I am passing to SV.
> In the case of output string, it's the C side who allocates the memory
> for string.
I assume on the heap? If yes, please indicate this clearly.
> 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.
Yes. This is my fear ... The devil lays in the details, as always. a) I think the lifetime of the corresponding data is dependent on
the SV simulator, and is not neccessarily the whole program. b) When I receive a string created on the SV side, can I assume that
the string for which I received a pointer lives longer than the actual function call (so can I store it and use it by another C
function called by SV)? Or _might_ this string be destroyed? Yes the pointer might be still there but what happens with the string
itself?
> 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.
Yes. But all our examples should show this and we should clearly indicate that this is the recommended style...
> I don't think a linker will be involved here, but don't let us get started
> again :-)
Mostly agreed.
> > 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.
Agreed until here ... Although I would like to see the clearly spelled out, probably in an example ...
> > 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.
That is really not good!!! I want also to know about the "real" bit index on the SV side when I do some manipulations here. This is
absolutely required for error messages or similar things. Otherwise I need to create a C function instance for every possible call
of the C function, which is clearly not acceptable ...
> > 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?
I think I did not properly communicate my issues here. Which bit on the SV side is mapped to which bit on the C side?
> Perhaps we could resort to the old semantics of PLI avalue/bvalue?
> I suppose it had to deal somehow with the ordering problem.
It had. But please don't use this as a role model ... :-(
> > 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.
Great. Will have a look at it.
Thanks for the fast response.
-Michael
--NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, System Design | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( )
*** This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. Thank you! ***
This archive was generated by hypermail 2b28 : Wed Dec 11 2002 - 02:48:15 PST