Subject: Re: [sv-cc] LRM edits for "the gnarly thread"
From: Stickley, John (john_stickley@mentorg.com)
Date: Mon Mar 10 2003 - 12:01:56 PST
Doug,
I've not yet seen the .zip file.
One comment embedded prefixed with johnS:
-- johnS
Warmke, Doug wrote:
> 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".
johnS:
I really like this ! This way we introduce nothing to the language
that is DPI specific, yet we address Michael's concerns quite
nicely.
<EOM>
>
> 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
-- johnS
__
______ | \
______________________/ \__ / \
\ 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 : Mon Mar 10 2003 - 12:07:19 PST