Subject: Re: More on ISSUE 1.7: direct access is a must
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Fri Nov 22 2002 - 14:21:57 PST
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 : Fri Nov 22 2002 - 14:23:53 PST