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