Subject: Re: DirectC: C layer - abstract vs direct
From: Stickley, John (john_stickley@mentorg.com)
Date: Fri Dec 13 2002 - 17:03:49 PST
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
>
> 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:07:27 PST