Subject: Minutes - 11/7 SV-CC Face-to-Face Meeting
From: Ghassan Khoory (Ghassan.Khoory@synopsys.com)
Date: Mon Nov 11 2002 - 13:40:56 PST
Thanks, Kevin for the minutes.
I have added Michael since he was there for all the morning session.
If there is anyone else we did not catch on the conf. call, let us know.
/gjk
-----Original Message-----
From: Kevin Cameron x3251 [mailto:Kevin.Cameron@nsc.com]
Sent: Friday, November 08, 2002 12:01 PM
To: Ghassan.Khoory@synopsys.COM
Subject: RE: Minutes
Here's a slightly better copy.
Regards
Kev.
-------
Minutes:
Started 9:20 (Agenda posted)
(* Action items)
Ghassan, Andrzej/Synopsys , Joe Daniels, Emerald/Ment, Doug Warmke, Kev,
John A., Duane, Dave Rich,
Bassam/Novas,Joao,
Phone: Francoise, Mike Mac., John Stickley, Michael
Item1: Debate on target foreign languages from SV
Andrzej: Ignore foreign language semantics
Duane: Semantics like garbage collection should be considered (Java?)
Item 2: Time delays in XFs
Andrzej: Restrict XF to 0-time.
Duane: Suggested special return values for handling time control.
(generally agreed)
Item 3: Use SV syntax for XFs
Kev: No statement of how to declare XFs
?: Reference LRM
Item 4: Limit callee access to arguments
Fran.: Precludes PLI?
Andrzej: Yes - allows optimization.
Bassam: $root access included?
Andrzej: $root may be OK.
Duane: Call-by-value vs. call-by-ref
Joao: Agree with item, split from ACC/PLI
Doug: Item unacceptable
Kev: Not consistent with C/C++ (no guarantee of purity)
Bassam: Too general - needs restatement
Kaz: Split into more issues.
Joao: Base optimization on compile options - assume pure if PLI/ACC not
enabled
... proposed passed handles should be considered volatile
Kev: Put restrictions on SV data declarations instead
No resolution.
Joe: Suggested go for restrictive in interim.
Item 5: XF Declaration
Kev: Applies to SV too?
Andrzej: Probably.
Joao : Remove "optional" (generally agreed)
Item 6: Scope
Kev: Declaration should be repeatable anywhere (in modules too),
resolving
to same XF.
Item 7: No overloading for XF (within SV only)
Duane: Any rules for equivalence in SV?
Generally agreed.
Item 8: XF Syntax
General agreement.
Item 9: Argument passing
Duane: requested rephrasing.
Will discuss coersion later - kill item (agreed)/or restate.
Pass to basic.
Kev: Do XF declarations preclude in-lining and defer selection to
linker?
Andrzej: XF declaration precludes SV implementation.
[Stuart Swann arrived]
Discussion continued at length, general agreement on item.
Item 10:
Kev: SV is currently all pass-by-value anyway?
": Should match SV semantics for plug-and-play.
Duane: Dangerous?
Kev: Delay discussion until pass-by-ref discussed.
General agreement - XF call should be indistinguishable from SV call.
Item 11:
Kev: Copy-by-value allows on-the-fly conversion in implementation.
Duane: Need vectors.
Fran: Missing char?
Kev: Change "pointer" to "handle"?
Kev: Strike "logic" (4-state)
Agree to remove logic.
Item 12:
Kev: Implement as 64-bit sized object (long long/double) for
generality - casting is
user responsibility.
Others: Compiler dependent.
Duane/Andrzej:
No pointers in packed structs.
Duane: Defer "string" discussion.
Kev: Change "string" to "cstring" if thats what it is doing.
Duane: Limit "string" to XF.
Duane: Split issues. (generally agreed?)
General change "pointer" to something else.
Item 13:
Andrzej: SV should follow C for unpacked struct layout (Item 11 types).
Michael: (2) Should only access by name.
Kev: (2) Only relevent for pass by reference.
Duane: Continue discussion later with C interface details for 1 & 3.
Joao: Optimization issues with fixed data-layout.
General agreement on point 2. 1 & 3 deferred.
[Lunch]
Item 14:
[Duane departed]
Kev: Maybe want n-dimensional unpacked arrays to let definions match.
Agreement on n-dim. unpacked, and add structs.
Item 15: Array passing (to C?).
Joao: Objected to normalization. Missing bounds info.
Kev: Translation should match SV struct/union rules.
Stuart: Use object oriented access.
Kev: Pass array descriptors instead of data pointers.
Defered.
Item 16: Unsized array access
Kev: Missing mechanism to get sizes.
Joao/Dave:
Offered alternative syntax.
Item 17: Return types
Kev: Missing double, logic is 4-state (drop?).
General agreement to do complete enumeration of types.
-----
SV->C,C->SV Function Call proposal from Joao & John.
SvccBindSVCaller:
Joao: Over defined.
Kev: Binding can be done on first call.
Andrzej: Objects to having to bind by path.
Requirement restated:
Called C functions need to maintain their own context in parallel
to SV instance. Same C context for all calls to the same function
from the same instance, each function has its own context.
task == void function (wrt to XF)
SvccBindSVCallee:
Stuart: Prototypes for tasks for type coersion?
Kev: Need a single prototype for external access. (kernel adapts)
Example:
Stuart: Issues with binding scheme (too much user code).
-
Kev: Use PLI handle as context.
Discussion to continue on e-mail.
C++ Virtual Function Discussion
Doug: Asked for example.
Joao: Is it necessary?
Joao: Need C compatible operation.
Prefix Vote:
All agread on svc_<function>
Cmodule vs External Tasks
Requirements unclear -
Joao: Leave implementation defined?
* Doug: Will offer trial syntax for external module.
Doug: Proposed removing cmodule (delayed to next phone conference).
Wrap-up
* Kevin to do C++ examples
* Joao & John will work on PLI contexts
* John & Duane look at call binding
Discussion on non-zero delayed calls and threads to be delayed to SV 3.2
This archive was generated by hypermail 2b28 : Mon Nov 11 2002 - 13:41:33 PST