Subject: Re: [sv-cc] RE: Version 2 of DPI LRM
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Thu Mar 13 2003 - 14:02:48 PST
Hello Andrzej,
thanks a lot for your response. Comments interspersed.
Andrzej Litwiniuk wrote:
> > MICHAEL wrote:
> > There are three handle types that we need to distinguish:
> > a) the generic, opaque handle defined on the SV side
> > b) the handle provided when having an open array as param
> > c) the handle provided for the context
> > all three are in my eyes different and I think we need to reflect this by providing three different handle types.
>
> Yes, they are different. And they come from two different worlds.
>
> On SV side there is only primitive type 'handle', which corresponds to 'void*'
> in C. It ain't that different from SV 'string' reflected in C as 'char*'.
> A notion of any handle to an open array or to a context is simply nonexistent
> in SV.
>
> On C side they are two different and unrelated types of handles (which may
> or may not be implemented as pointers): a handle to an open array and a handle to a context/scope/instance.
This is exactly the reason why I would not derive those handles from a single type.
E.g. Win32 uses integers for its resource handles, not pointers. On the other side, different data types might destroy needlessly the
binary compatibility.
> [BTW, isn't it so, that a term 'scope' refers to a source code, while 'instance'
> refers to an execution? Besides, blcoks with local declarations also define
> 'scopes', while they do not create instances.]
>
> > IM(very H)O there are two good ways here:
> > A) have a base type; e.g. 'svHandle'
> > . derive three types from it; e.g.
> > svOpaqueHandle
> > svOpenArrayHandle
> > svContextHandle
>
> svOpaqueHandle is not needed at all, remaining two types of handles are
> unrelated, most likely implemented differently and used in absolutely different
> a context of use (in non-instance/scope sense).
Basically I agree. It is always possible to immediately pass void*. On the other side it would not hurt to have a one to one relation
between Chandle (or whatever the selection of sv-ec is) and svHandle. To be honest, I am not very religious here ...
> > B) just have three handle types
> > svHandle
> > svOpenArrayHandle
> > svContextHandle
> >
> > I am more for the second one, which gives also my name preferences; although I really don't care here. I as many other user's will
> > do Cut&Paste and as such the lenght of a type name does not really count ...
>
> Oh, well. I heavily use Copy&Paste, too. So the lenght is not an issue, right?
> Thus I opt for:
>
> svOpenArrayHandle
> svScopeHandle (Scope or Context or Instance?)
Fine with me.
> Regards,
> Andrzej
>
> PS. Since we are already polling (yet informally), may we revive the poll
> on include files names?
>
> 1) svc.h + svc_src.h
> 2) dpi.h + dpi_src.h
> 3) svdpi.h + svdpi_src.h
> 4) sv_dpi.h + sv_dpi_src.h
> 5) sv_dpi_c.h + sv_dpi_c_src.h
>
> I opt for 5) because: SV + DPI + C; layers for other languages are
> conceivable for DPI, similarly like other interfaces are conceivable for SV
> (and they even do exist, e.g. VPI).
I like 4) more - basically I doubt that there will be ever other header files. And when, then they will very likely provide some mapping
from the C function call semantics to the other foreign language. But all others are O.K. as well. Pick one.
> > > Team, quick poll from Andrzej and me for renaming svHandle:
> > > svArrayHandle
> > > svOpenArrayHandle
> > > svArrHandle
> > > <your suggestion here>
> > >
> > > Thanks and regards,
> > > Doug
--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 : Thu Mar 13 2003 - 14:15:39 PST