Subject: Re: issue 1.4: No clear relationship to other APIs
From: Michael Rohleder (Michael.Rohleder@motorola.com)
Date: Thu Nov 07 2002 - 08:46:05 PST
Thanks Mac, this is very good input.
a) For sure there are some functions that do not require this env table (e.g. io_printf, mcd_... to get plusargs ...)
b) My personal preference is 1) even as a user and programmer. This does not add any performance drawback, and IFF you want to do
dirty PLI/VPI tricks having the need to call a function sv_stabilize() or sthg similar is a minor problem compared with the huge
amount of thing you have to keep in mind in PLI...
c) The only (hidden) requirement I have is that the simulator provides some useful feedback (probably through) a dummy table when I
forget this. But this is surely in the discretion (and interest of the simulator vendor).
Regards,
-Michael
Michael McNamara wrote:
> Michael Rohleder writes:
> > * I want not to prohibit PLI/VPI calls in DirectC functions.
>
> -> This demands that the DirectC function calling a PLI function must
> set up (or arrange to be set up) the complete call environment
> expected by a PLI or VPI function.
>
> (FYI, a PLI function is only passed a minimal set of information
> about its calling environment, and can (must) make a set of
> subsequent calls to determine how many arguments were passed to it,
> what hierarchical path it was called from, et cetera. These calls
> are satisfied by the simulators's examining a table of information
> (let us call it the Environment Table) the simulator sets up before
> it calls any user function.)
>
> I see three ways of doing this:
>
> 1) require simulators to provide a routine that a DirectC programmer
> can call that will set up this Environment Table.
>
> 2) define the Environment Table's format in the standard, and require
> DirectC programmers to update the table directly before calling
> PLI functions.
>
> 3) when passing control to DirectC, the simulator shall set the
> Environment Table to values that result in no core dumps, but
> provide minimal functionality for all possible subsequent PLI
> calls by the DirectC routine that is called.
>
> The first two paths make it difficult for DirectC routines to call
> PLI routines simply and robustly. [Asking programmers to remember to
> do someting is asking for trouble]. The third alternative adds
> weight to all DirectC calls, and makes any such PLI calls from
> DirectC less useful, but perhaps useful enough for your purpose)
>
> -mac
This archive was generated by hypermail 2b28 : Thu Nov 07 2002 - 08:48:49 PST