Subject: Re: DirectC: C layer - abstract vs direct
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Fri Dec 13 2002 - 17:41:06 PST
> From john_stickley@mentorg.com Fri Dec 13 17:04:44 2002
>
> Kevin,
>
> Kevin Cameron wrote:
> > In my mind an abstract interface is one that uses an opaque handle as a reference to
> > some object and lets you apply methods to it. In C++ fully abstract interfaces are
> > implemented with virtual functions, in C it's ususlly:
> >
> > <ret data> = <method>(<handle>{,<args});
> >
> > - which is more-or-less the approach taken with PLI/VPI. It is not usually necessary
> > to implement all methods for all objects. Calling an unsupported method usually just
> > gets you a bad return value.
> >
> > Andrzej's proposal is not an abstract interface, it is a direct interface - i.e. the SV
> > simulator provides a pointer to it's memory, and the user gets to write into it. Since
> > SV can't perform array bounds checks on that interface it is error prone and is likely
> > to lead to hard-to-debug crashes. Also, since in many cases the SV simulator's internal
> > representation of the data is not likely to match the structure defined for C, the
> > simulator has to create a copy of the data and pass a reference to that - which will
>
> johnS:
> Whether an implementation's internal representation matches C data or
> not is not our concern here. If it does not, the implementation can
> internally perform copy-by-value semantics to properly present the C view to
> a user for example when passing an arg from SV-to-C.
>
> Or they may chose to use identical representation to maximise performance.
> Let's not be the ones to dictate this.
>
> > be virtual copy-in/copy-out, and may be considerably slower than an abstract interface
> > if only small parts of the structure are being accessed. There has been no official
> > agreement that C type structures in SV actually layout the same as for C yet, I don't
> > see there ever being agreement on SV types laying out the same.
>
> johnS:
> Actually I think, in a sense, there was official agreement on this.
> This was issue 13 (a) of the 17 points proposal which had a unanimous 10-0-0
> vote in favor.
>
> Now, bear in mind that this does not mean that the internal SV representation
> of a struct need be the exact C representation. But by guaranteeing
> at least consistent ordering along with clear scalar type mapping as
> agreed to, implementations have the option of making the internal
> representation match the C representation and thus optimizing performance.
>
> Again, let's not prevent that.
>
> -- johnS
That's partly why I added the full copy-in/copy-out to my proposal. If your simulator
stores stuff in the canonical form (probably only VCS) then for inout and output
arguments you can pass a pointer to the data and do stuff directly.
If you want to add a bunch of macros and do something vendor specific, then you
can set a bit in the "capabilities" or "context" to indicate that's the case or add
another attribute to the type string for the dynamic binder (I consider Andrzej's
proposal somewhat vendor specific).
NB: The new (C) data types added to SV have not been implemented by many
simulators yet so we can insist that they follow C layout rules. Net (4-state)
data is already in use and is unlikely to follow any strict layout rules, and is
also likely to be difficult to coerce.
As I said before, the real solution is not to do stuff in C/C++ that fits better in SV,
and if some capability is missing from SV then raise it at the EC. That's why I
keep asking for references with pointer-like behavior and as much C/C++ syntax
as possible.
Kev.
> >
> > Kev.
> >
> > --
> > National Semiconductor, Tel: (408) 721 3251
> > 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
>
> __
> ______ | \
> ______________________/ \__ / \
> \ H Dome ___/ |
> John Stickley E | a __ ___/ / \____
> Principal Engineer l | l | \ /
> Verification Solutions Group | f | \/ ____
> Mentor Graphics Corp. - MED C \ -- / /
> 17 E. Cedar Place a \ __/ / /
> Ramsey, NJ 07446 p | / ___/
> | / /
> mailto:John_Stickley@mentor.com \ /
> Phone: (201)818-2585 \ /
> ---------
>
>
>
>
>
This archive was generated by hypermail 2b28 : Fri Dec 13 2002 - 17:41:35 PST