Subject: [sv-cc] LRM edits for "the gnarly thread"
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Mon Mar 10 2003 - 10:42:36 PST
Team,
I sent this out yesterday, but apparently the server.eda.org
reflector swallowed it due to large attachment size.
Here is the text part of my mail; I will send the .pdf files
in a .zip in a separate attachment (in case it disappears again).
**** Start of Doug's Sunday mail ****
Team,
I have edited revisions of the LRM documents that reflect
our discussions on context functions. I have carefully reviewed
everyone's emails and comments, and I hope all concerns have been
addressed satisfactorily.
It would be excellent if you guys could read the "v2" versions
of the documents in time for our Tuesday meeting, then we could
continue our discussions and go over the next set of issues.
Certain concerns couldn't be addressed in the LRM (yet).
Here are my thoughts on the aggregated open issues:
1) Michael/Andrzej's concerns about not being able to declare
export functions in $root (or arbitrary?) scopes.
Here the concern is one of user convenience. Michael wishes
to be able to export a function without necessarily invading
the code containing the function declaration. This is a valid
point.
In SV-AC, they have a proposal to add a keyword called "extends".
The idea is to address exactly Michael's concern, i.e. when a
programmer doesn't have permission to modify original source,
but would like to modify/extend the functionality. I think that
we can make use of that mechanism to address Michael's concern.
I prefer the "extends" mechanism since it is quite general and
addresses a large issue at the same time as Michael's issue.
The proposal to introduce a new C++-like scoping operator "::"
would work, but it is a new language construct and the use of
this mechanism for export is pretty limited compared to "extends".
2) Concerns by several folks about disallowing multiple extern
declarations at root scope.
This goes back to what exactly an external function represents.
The proposal to allow multiple extern declarations at root scope
is more in line with the way C works than the way SV works.
In this proposal, external function declarations are analogous
to C function prototypes. Such functions could never have
context associated with them, other than the context of their
call sites. This proposal is not unreasonable; however, it is
less powerful than what we eventually ended up with after the
"gnarly thread".
Now, what an external function represents is a kind of "proxy"
that stands in for a native SV function. As such, it makes sense
that external function declarations be situated in exactly the same
code scopes as native function declarations. Further, our desire
to treat external and native SV functions identically as much as
possible is well met by this "proxy" concept.
The idea of "DPI context" relies heavily on the proxy concept.
If we don't give DPI external function context (aka scope) the
same treatment given to native SV function context, the system
is inconsistent and less powerful. The kind of work demoonstrated
in John's examples would not be possible. Further, the "gnarly"
design fulfill's Michael's desire to have identical call chain
context behavior, regardless of SV or C language for some functions
in the chain. (i.e. chains "process code -> f() -> g()" and
"process code -> f'() -> g()" behave identically, where f() and g()
are native SV functions and f'() is a C external context function.
Please refer to the LRM, in particular the new Section 8 in Annex A,
for a more thorough treatment of "DPI context".
3) Michael's request for additional DPI utility functions.
These would be useful for error reporting:
- A function to determine the scope of an external function's call site
- A function to determine the scope of an external function's declaration
I would propose:
/* Returns fully qualified name of call site's surrounding scope */
const char* svGetCallSite(svHandle scope);
/* Returns fully qualified name of the function itself (including
function) */
const char* svGetDeclarationScope(svHandle scope);
I didn't put these in the LRM yet, since I think we need to discuss them
first and make sure everyone agrees with Michael's proposal.
4) Francoise's desire for parallel treatment of DPI and VPI functions
I thought about this a lot, and I think I've gone as far as I can go.
I added a section to Annex A about the relationship of DPI and VPI.
Here, DPI and VPI context are compared and contrasted. Further, some
stipulations about interactions between the two interfaces are given.
Please read it and see if it makes sense. (Don't really wan to
repeat all that typing here :) )
5) Andrzej's notes on items remaining to be done in the LRM drafts:
> Specifically, the following have to be rewritten, added or eliminated:
>
> - extern declarations allowed in any scope
> - optional cnames
> JohnS proposed a wording for cname, for your convenience his
> email is attached
> - no multiple declarations
> - restrictions on global C symbols and on re-naming
> - export declarations at the scope of the definition
> - explanation of cnames, again JohnS's proposal may be used
> - context info for 'context' function that are expected to call SV
functions
> - context info for exported SV functions called from C
> - revised examples:
> - the new syntax for extern, export
> - new examples for exported functions
> - examples of context-sensitive calls on both sides
> - new functions in C layer for retrieving or setting the context
All of the above have been taken care of.
Some of the wording may need to be improved, and some more examples
might be useful. Others, please feel free to jump in. After this
weekend I have a good appreciation for how hard Andrzej's job has
been as editor/caretaker of these documents (!)
Andrzej,
Regarding the process of editing the LRM docs:
I propose that when we release a document, we release it with
the NEW additions in blue, and the DELETE's from the previous
version struck through in pink.
When we receive a version and want to start editing it,
we will clear (and re-enable) all Change Bars, and we will
"normalize" the text. This means turning all the NEW blue
text into DefaultFont black text, and permanently deleting
the struck through pink text. If we don't do that, the
aggregate of all changes ever made will build up, and it
will be impossible to figure out what is what.
For this draft, I did clear Change Bars when I started working,
but I didn't normalize your blue and pink text. I did "pink"
and "blue" my deletions and additions, but they are aggregated
with your stuff, and of course it is getting more and more
confusing. (That's why I thought of this policy proposal
I am making here).
With this email, I am attaching only .pdf versions that don't
have all the pink and blue text bits. I will send you the
FrameMaker source separately. There are two editions: one
with all the pink and blue, the other that is all normalized
with cleared change bars (for your convenience when you start
editing again).
Thanks and regards,
Doug
This archive was generated by hypermail 2b28 : Mon Mar 10 2003 - 10:43:17 PST