RE: [sv-cc] Re: [sv-bc] Mantis 3087 Uses of comment pragmas instead of attributes

From: Vitaly Yankelevich <vitaly@cadence.com>
Date: Sun Aug 07 2011 - 02:08:46 PDT

Just in case if the proposal below is to replace the export/import DPI-OO declarations with attributes completely:

I think that the basic declarations' syntax should be stronger than attributes because the class properties of being export/import class directly influence compilation of the classes and objects. In particular:

- an allocation of an import class object should be implemented differently than a native class
- garbage collection of an export/import classes should be implemented differently
- arguments of DPI-OO subroutines need to be checked by the compiler to be export/import DPI-OO classes
- DPI-OO copy classes are required to support deep copying.

Given the above, I think that the attributes can replace the comment-based pragmas but they cannot substitute the explicit export/import class declarations completely.

Vitaly

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Maidment, Matthew R
Sent: Thursday, August 04, 2011 8:02 PM
To: Jim Vellenga; brad_pierce@acm.org; Rich, Dave
Cc: SystemVerilog CC DWG (sv-cc@eda.org); sv-bc@eda.org
Subject: RE: [sv-cc] Re: [sv-bc] Mantis 3087 Uses of comment pragmas instead of attributes

Here's some idea of what attributes might look like

(*DPIOO, export, exclude="f2", language="SystemC" foreign="P::Packet"*)
class packet;
extern function int f1();
extern function void f2();
endclass

class packet;
  (*DPIOO, export, foreign="GetByte" *)
 function byte get_byte(int j);
  ...
  endfunction
// pragma DPI-OO export function get_byte foreign=GetByte
endclass

The benefits of attributes include clearer semantics as to which syntax elements they apply as to where they apply and that they can be interrogated by VPI.

I'd like to see attributes given more consideration given that strings can store most everything and there is no ambiguity regarding placement.

Matt

--
Matt Maidment
mmaidmen@ichips.intel.com
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Jim Vellenga
Sent: Wednesday, August 03, 2011 8:55 AM
To: brad_pierce@acm.org; Rich, Dave
Cc: SystemVerilog CC DWG (sv-cc@eda.org); sv-bc@eda.org
Subject: RE: [sv-cc] Re: [sv-bc] Mantis 3087 Uses of comment pragmas instead of attributes
Syntax 22-8 comes a lot closer to what's in the proposal.  Using Syntax 22-8, the complex values supported by the proposal could be represented as strings.  So that would work out OK.
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Brad Pierce
Sent: Tuesday, 2 Aug 2011 3:22 PM
To: Rich, Dave
Cc: SystemVerilog CC DWG (sv-cc@eda.org); sv-bc@eda.org
Subject: [sv-cc] Re: [sv-bc] Mantis 3087 Uses of comment pragmas instead of attributes
Can the impoverished attribute syntax of Syntax 5-3 really carry the weight? Why not use/extend the `pragma directive of Syntax 22-8?
On Tue, Aug 2, 2011 at 8:02 AM, Rich, Dave <Dave_Rich@mentor.com<mailto:Dave_Rich@mentor.com>> wrote:
Why does this proposal continue to promote the use comment pragmas instead of attributes? I thought the use of attributes is to be encouraged because you can't construct macros to deal with comments. Or are we giving up on attributes?
Dave Rich
Verification Technologist
Mentor Graphics Corporation
[cid:image001.png@01CC54F9.EF45CA20]<http://www.twitter.com/dave_59>[cid:image002.png@01CC54F9.EF45CA20]<http://go.mentor.com/drich>
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


image001.png
image002.png
Received on Sun Aug 7 02:10:40 2011

This archive was generated by hypermail 2.1.8 : Sun Aug 07 2011 - 02:11:04 PDT