Subject: Re: More on ISSUE 1.7: direct access is a must
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Mon Nov 25 2002 - 03:11:47 PST
Andrzej,
I am really concerned about the mindset in this email. Although it is always possible that a vendor 'enhances' a standard with a
proprietary extension, this is the very first step of torpedoing it. Micro$oft is a very good example how this works (see HTML,
Javascript, C++, ...) and my hope is that no company in the EDA business is going the same route. The whole point behind an API
definition is to clearly define an interface between _two_ sides.
What you describes sounds like "the foreign language (C) side might look different for every vendor". BEWARE!!!
-Michael
Andrzej Litwiniuk wrote:
> Hi all,
>
> > There are actually a few approaches available to us.
> > Before digging in and fleshing out details, I think
> > the group needs to vote on the general philosophy
> > to be followed. Once that is done, we can spend
> > time on detailed specification. If we don't agree
> > on this early, we will waste time on email and
> > in meetings.
>
> Absolutely agree.
>
> Please consider the following two observations:
>
> 1) if standard C functions are to be directly callable from SV
> (cf. the requirements!) then some form of direct access is a must.
> At least some primitive types (int, pointer, string, ...) should
> be supported with direct access mode.
>
> 2) once the standard is defined, vendors may come up with their
> open or proprietary versions of libraries for the abstract access
> mode.
>
> Node that the C layer of the interface is transparent to SV.
> --------------------------------------------------
>
> Hence the vendors will have the freedom and flexibility of defining
> their own versions of the C layer, or their own implementation of
> the collection of functions agreed upon as a part of the interface.
> Different implementations of the same function (with respect to
> arguments and result) may actually differ in performance, safety,
> performed checks, etc.
>
> Actually, even if we decide to completely reject abstract access,
> vendors still will be able to provide it! It's just a matter of
> modifying the SV compiler; other tools nor SV programmers won't
> even notice it! (If they don't use the alternative version, of course.)
>
> My point here is that it's not that important, how we define the C
> layer now.
> Anyway, the C layer of DirectC interface is likely going to be
> a separate document, an appendix to the core SV definition.
> This also buys us some time.
>
> The only thing that has to be defined =now= and may not be postponed
> is the syntactical support for different access modes, if we decide
> to use a mixed model.
> I mean here things like 'extern' or 'extern "C"' or 'extern "A"'
> or whatever syntactical means may be used to specify the access mode.
> (The problem can be avoided by all-or-none approach, where
> the access mode is specified by compiler's flags, but this approach
> seems less convenient that the one usde in VCS DirectC.)
>
> Andrzej
>
> > Here are the possible approaches I can see:
> >
> >
> > 1) Use system currently in place in DirectC.
> > i.e. both abstract and direct are redundant
> > with each other. Both are available to user,
> > the user decides which to use.
> >
> >
> > 2) Use abstract mode all the time.
> > All access is done through API functions.
> > Different #define or -D could be used to
> > specify an optimization level.
> >
> > 3) Use combination of direct and abstract modes,
> > but with no redundancy. In this approach,
> > almost all access is done in Direct mode.
> > There are some items which must be done using
> > abstract programming interface calls:
> > 1) Determining # of array dimensions
> > 2) Determining bounds of each dimension
> > 3) Equating enum ordinals to ASCII strings (optional)
> > 4) Maybe more that I can't think of right now
This archive was generated by hypermail 2b28 : Mon Nov 25 2002 - 03:13:10 PST