RE: [sv-cc] 1456 (context behavior): context follow-up

From: Duncan, Ralph <ralph_duncan_at_.....>
Date: Tue May 23 2006 - 08:33:56 PDT
Hi, Francoise,

 

I've got a tentative, two-paragraph text that might be added to 26.4.3.
It would define "import 

context call chains" and their basic behavior.  (I haven't put it in a
Mantis item yet because it 

seems like I'm hammering people with a great deal of material).

 

The definition of a DPI context call chain (in 26.4.3) should be
independent of any particular 
language, esp. since it seems likely that DPI-SystemC and others are on
the way.  Thus, the 

language in this section should never talk about sequences of C calls,
etc.

 

Annex F, however, deals entirely with DPI-C, so it seems fair that its
pronouncements always 

stick to C.  Perhaps I should go ahead and make the Mantis item that
aspires to specifying context 

basics in a language-independent way.

 

Meanwhile, the best answers I can manage are embedded below. Hope they
are helpful.

 

Ralph

 

________________________________

From: Francoise Martinolle [mailto:fm@cadence.com] 
Sent: Tuesday, May 23, 2006 4:30 AM
To: Duncan, Ralph; sv-cc@eda.org
Subject: RE: [sv-cc] 1456 (context behavior): modified proposal

 

 

Ralph,

 

I read the proposal on 1456 and I have a couple of comments.

 

The definition of a DPI-C call chain seems to imply that it has to do
only with a DPI-C import context function.

You do not mention DPI import context functions, is this because they
are not standard? (This is DPI-C versus DPI strings)

> I'm just trying to keep 26.4.3 (DPI in general) distinct from DPI-C
(topic of Annex F). 

 

We need to cover all variations. What about if you have the following
call chain:

DPI-C context import function_1 calls DPI-C context function_2 which
calls a C function

Does the later C function inherits the context of DPI-C context
function_2?

The context in effect is the one from context_ import_function_1;
context is only set by moving across the SV/C boundary
to a context function or via the DPI utility that forces a specific
scope to be in effect. 

 

DPI-C context import function_1calls DPI SV export function_1 which
calls DPI SV export function_2 which calls DPI-Cimport function_2 which
call C function

What is the context of DPI SV export function_2?

>Whatever context was in effect when SV export_function_1 was called,
unless it is reaching export function_2 via an hierarchical
>reference and export_function_2 'lives' in a different context.
Context is only set when crossing language boundaries or forcing it via
utilities.

What is the context of the last C fcuntion call (not it is not called by
a context import function)?

>Since DPI-C import function_2 apparent isn't declared as 'context" the
last C fn would not be associated with a context.

>If import function_2 were to be declared context, the last C fn would
inherit context from it.

 

Instead of defining the term of DPI-C call chain, I would have define
this in terms of setting and inheriting the

context:

The context of a call to a DPI import context function is set with the
DPI import declaration instantiated scope 

unless set explicitly otherwise by a svSetScope call inside the DPI
import function body.

A systemVerilog export function or C function always inherits the
context of the calling DPI or C function.

It is erroneous if the context of a systemVerilog export function is
unknown.

>Your rules 1 & 3 are certainly correct.  I'd tweak rule 2 because it is
possible for a C fn to not have a 

>context and yet be legal.  The context 'chain' concept becomes useful
when you look at unwinding behavior in complex call 

>patterns (i.e., the end of the 'chain' is important for seeing that
context can be adequately managed with a simple stack). 

 

Francoise

       '

 

	
________________________________


	From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf
Of Duncan, Ralph
	Sent: Monday, May 22, 2006 1:50 PM
	To: sv-cc@eda.org
	Subject: [sv-cc] 1456 (context behavior): modified proposal

	Mantis item 1456 has a new proposal; the changes are

	 

	. Affirm that calling exported tasks and functions from
non-context call 

	  chains results in undefined behavior (just as calling the DPI
context 

	  manipulation utilities does).

	 

	. Distinguish "DPI context call chains," which exhibit general
rules from 

	  "DPI-C" context call chains, which describe the behavior of C
call chains.

	            .. The general DPI discussion (in 26.4.3) should be
in terms of 

	               "DPI call chains."

	            .. Descriptions of C call chains in Annex F now uses
"DPI context call chain"

	           for the general case but "DPI-C call chain" when
describing call sequences 

	           in C vs. those in SystemVerilog.  (After all, Annex F
is devoted to C).

	 

	 

	We also talked about how context and call-chains worked in a
general way.

	A reasonable action would be to take 5/11's email about
call-chains and add relevant

	material to 26.4.3 to address the general, not-C-specific case.

	 

	Please share any comments you have on the 5/11 email.

	 

	Ralph

	 

	Ralph Duncan

	Mentor Graphics 

	San Jose, CA

	 
Received on Tue May 23 08:33:49 2006

This archive was generated by hypermail 2.1.8 : Tue May 23 2006 - 08:34:00 PDT